Расширение для PMBoK: 5 новых областей знаний

02 Авг 2017

В среде профессионалов проектного управления широкую известность имеют не только Руководство к Своду знаний по управлению проектами PMBoK PMI и стандарты PMI по портфельному и программному управлению. Многие также знакомы с расширениями PMBoK для строительной отрасли, ИТ, государственного сектора, практическими руководствами по построению иерархической структуры работ проекта, составлению расписания, управлению рисками и др. Но не так широко известно, что существует расширение от отрасли, которая является источником многих практик и инструментов проектного управления – оборонной промышленности. Рассмотрим, что ценного появилось в этом расширении.

Расширение Руководства к Своду знаний по управлению проектами от Департамента обороны США (U.S. Department of Defense Extension to A Guide to the Project Management Body of Knowledge) было разработано в 2003 году Колледжем управления оборонными системами Университета оборонных закупок при Департаменте обороны США. Цель создания расширения – описать применение областей знаний проектного управления из PMBoK Guide для оборонных проектов. Результаты ориентированы на участников оборонной отрасли промышленности, при этом подается информация с точки зрения заказчика и конечного пользователя результатов: военнослужащих, гражданских служащих, сухопутных войск, военно-воздушных и военно-морских сил, морской пехоты. Положения расширения также затрагивают и подрядчиков.

Основной элемент новизны в расширении – введение пяти специальных областей знаний:

• управление проектированием систем
• управление закупкой программного обеспечения
• управление логистикой
• управление тестированием и оценкой
• управление производством

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

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

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

Жизненный цикл оборонной программы

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

Жизненный цикл оборонной программы разделен на 5 стадий:

• Уточнение концепции (Concept Refinement);
• Разработка технологии (Technology Development);
• Разработка системы и демонстрация (System Development & Demonstration);
• Производство и развертывание (Production & Deployment);
• Операционное использование и поддержка (Operations & Support).

Переход от завершенной к последующей стадии производится через контрольную точку, прохождение которой должно быть одобрено Уполномоченным на принятие решения о контрольной точке (Milestone Decision Authority, MDA).

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

Проработка альтернатив проводится во время первой стадии  –  «Уточнение концепции». Результатом стадии является Стратегия разработки технологии, СРТ (Technology Development Strategy, TDS).

Утверждение Стратегии разработки технологии означает начало следующей стадии, «Разработка технологии». Назначение этой стадии – снизить технологические риски и определить подходящий набор технологий, который будет адекватно интегрирован в финальный функционал системы.

Стадия «Разработка системы и демонстрация» начинается после утверждения Документации по разработке мощностей, ДРМ (Capability Development Document, CDD). При прохождении контрольной точки Уполномоченный также проверяет, является ли текущая зрелость технологий достаточной для разработки желаемой системы, и одобряет выделение финансирования. В одной стадии программы объединены разработка системы и демонстрация, последняя проводится после критического обзора системы.

После успешной демонстрации системы и утверждения Документации по запуску мощностей, ДЗМ (Capability Production Document, CPD), система может быть выведена на начальную операционную мощность. Критериями успешности демонстрации являются:

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

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

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

Управление проектированием систем

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

Управление закупкой программного обеспечения

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

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

• Используемый процесс и метод разработки;
• Стандарты для продуктов;
• Программное обеспечение повторного использования;
• План управления ключевыми требованиями;
• Размещение аппаратного обеспечения;
• Точки вовлечения заказчика в процесс разработки;
• Видение продукта;
• Тестирование программного обеспечения;
• Календарный план;
• Используемые ресурсы.

Управление логистикой

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

Управление тестированием и оценкой

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

• Представитель разработчика;
• Представитель отдела операционного тестирования;
• Представитель отдела логистического тестирования;
• Представитель отдела тестирования безопасности;
• Руководитель проекта;
• Представитель пользователя;
• Представитель высшего руководства заказчика;

Управление производством

Целью управления производством является создание надежного стандартизированного продукта без дефектов в соответствии с требованиями и с минимально возможными затратами.

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

• затраты на непосредственное производство продукта;
• затраты на работу с дефектами (как выявленными в процессе производства, так и обнаруженные заказчиком при использовании);
• затраты на обеспечение качества.

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

Суть в том, что за счет эффекта обучения, в перспективе организации второго типа будут иметь более низкую себестоимость продукции, чем организации первого типа.

В завершение приведем перечень практик из расширения PMBoK от Департамента обороны США, которые можно использовать в ваших проектах, вне зависимости от предметной области и отрасли:

• Жизненный цикл проекта, основанный на гейтовой модели. Распространенная во многих методологиях практика является универсально применимой для любого типа проектов и позволяет эффективно делегировать полномочия по управлению проектом, оставляя на уровне топ-менеджмента только ключевые решения;
• Инкрементальное приращение функционала продукта в ходе использования позволяет учитывать изменения требований к продукту и извлекать выгоды из использования прототипов, даже когда полнофункциональная версия еще не готова;
• Формирование интегрированных, мультифункциональных команд обеспечивает разносторонний взгляд на задачу, широкий набор компетенций в команде и упрощение интеграции результата проекта в операционную деятельность;
• Использование модульных контрактов позволяет организовать более короткий цикл предоставления результата подрядчиком;
• Планирование затрат с учетом жизненного цикла продукта позволяет учесть затраты, которые приходятся на период операционного использования результатов и могут составлять до 60% суммарных затрат на разработку и использование продукта;
• Оценка стоимости качества для организации позволяет со временем снизить себестоимость продукции за счет затрат на работу с дефектами.

 

 

 

Автор: Мария Белых
Консультант, PME, PRINCE2

 

 

 

 

 

Смотрите также:

• Новость: IT Expert и ПРОЕКТНЫЕ СЕРВИСЫ заключили партнерское соглашение
• Статья: Управляющий комитет – ответственный за успех проекта?
• Статья: Другая причина автоматизации