В соответствии с принципом выделения «ключевых» практик, для групп ключевых процессов приводятся не все начальные условия. В списке условий присутствуют лишь те, которые особенно значимы для внедрения той или иной группы.

Из всех общих признаков «Выполняемые операции» обладают наибольшим структурным разнообразием. Это вызвано тем, что действия по внедрению, относящиеся к этим группам ключевых процессов, варьируются по уровню детализации, организационному фокусу (например, выбор между фокусом на проекте или на организации), а также по потребностям в документации и планировании. Ниже приведены некоторые обобщения в отношении выполняемых операций.

В ключевых практиках описаны два основных типа планов: формальные (например, планы разработки ПО, обеспечения качества ПО и управления конфигурацией ПО) и неформальные (например, планы экспертной оценки, управления рисками и управления технологией).

Неформальные планы обычно документируются либо в качестве составляющих определенного формального плана (например, план экспертной оценки может быть документирован как часть плана разработки ПО), либо в качестве дополнений к нему (например, план экспертной оценки может быть разделом плана разработки ПО). Формальные планы требуют более сложного управления как в отношении их создания, так и с точки зрения отслеживания их выполнения. При заключении контрактов эти планы могут отсылаться заказчику.

В случае формальных планов для операций планирования обычно используются две ключевые практики: практика, требующая создания/ переработки плана в соответствии с документированной процедурой, и практика, требующая согласования операций определенной группы ключевых процессов с планом.

Подпрактики, имеющие отношение к документированной процедуре, обычно описывают исходную информацию для разработки плана, а также меры, которые потребуется предпринять для обеспечения необходимой поддержки плана и принятия обязательств. Кроме того, в этих подпрактиках указываются лица, наделенные полномочиями на ревизию плана, и требуемые уровни менеджмента, на которых происходит его утверждение.

Подпрактики, относящиеся к плану, описывают предполагаемое содержание обсуждаемого плана. В зависимости от типа плана и потребности в организационной гибкости для покрытия необходимых задач, описание содержания плана может проводиться с различными уровнями детализации.

Обычно для описания неформального плана достаточно одной ключевой практики. Подпрактики включают сведения о содержании плана, а также описывают процедуру его создания и переработки.

Документированная процедура обычно нужна для автоматизации повторяющихся задач и действий. Кроме того, использование такой процедуры позволяет сотрудникам с общими представлениями о той или иной группе ключевых процессов быстро научиться аналогичному способу выполнения задачи/операции. Это один из аспектов установления процесса.

Формальность и уровень детализации документированной процедуры может варьировать в значительных пределах (от записанной от руки индивидуальной процедуры до формальной стандартизированной последовательности действий, выполняемых на уровне организации в целом). Формальность и уровень детализации зависят от лица, выполняющего соответствующую задачу или действие (отдельный сотрудник или их группа), частоты выполнения, важности и предполагаемого использования результатов, а также предполагаемых лиц, которым эти результаты будут направлены.

Установленные для ПО системные требования обычно называются в СММ «установленными требованиями». Они представляют собой подгруппу системных требований, которые необходимо реализовать в программных компонентах системы. Установленные требования являются исходными данными для плана разработки ПО. Анализ требований к ПО позволяет уточнить и документировать установленные требования.

Требования заказчика относятся ко всей системе, а не только к ПО. В рамках СММ центральным пунктом обсуждения требований заказчика являются те требования, которые должны быть реализованы в создаваемом ПО. Отнесение системных требований к ПО, аппаратным средствам и т. д., являясь стадией общего проектирования системы, обычно выполняется группой системного проектирования. Установленные требования включают в себя как технические (функциональные возможности, производительность и т. д.), так и прочие требования (сроки поставки, затраты и т. д.).

Заказчик может располагаться как внутри организации, так и вне ее (внутренний и внешний). Примером внутреннего заказчика является группа маркетинга, а примером внешнего, скажем, Министерство обороны. Пользователь может отличаться от заказчика, как это обычно и бывает в случае заключения контрактов с военными ведомствами. Модель СММ выражается в терминах внешнего поставщика, обеспечивающего систему критически важным программным компонентом.

При необходимости границы между группами должны быть истолкованы должным образом, как это указано в СММ. Например, если по контракту требуется поставить только ПО, между разработчиками программы и заказчиком может быть прямая связь (без участия группы системного проектирования). В этом случае требования заказчика, системные и установленные требования могут являться синонимами. При этом сфера ответственности группы системного проектирования делится между заказчиком и группой разработчиков ПО.

В разделе «Отслеживание хода проекта и контроль над ним» на втором уровне многие ключевые практики содержат следующие выражения: «…процесс отслеживается…принимаются корректирующие меры». В разделе «Интегрированное управление разработкой ПО» на третьем уровне, напротив, в большинстве аналогичных практик употребляется слово «управление». Различие между этими терминами отражает отсутствие в проекте законченного производственного процесса на втором уровне. В подобных случаях обычно требуются действия управленческого характера. В то же время на третьем уровне проекта производственный процесс уже полностью определен, четко обозначены отношения между различными программными продуктами, задачами и действиями. Управленческий подход больше подходит для прогнозирования проблем и их профилактики. При необходимости вмешательства его последствия учитываются на уровне всего производственного процесса, что позволяет более эффективно выбирать и вносить изменения.