Что такое успешность проектов, программ и портфелей

Успех (success) - достижение поставленных целей в задуманном виде, благоприятное завершение или исход попытки или предприятия.

Успех определяют люди, у которых есть цели. Если у вас нет цели в отношении проекта или системы, то вы не сможете сказать успешен он был или нет.

Тип деятельности	Цель	Успешность
Проект	Конкретный измеримый продукт за определенную стоимость, в определенный срок, с заданной спецификацией	Исполнение утвержденного плана проекта и договора поставки
Программа	Конкретные измеримые бизнес-эффекты, в достаточно широких пределах стоимости, сроков, с постоянно уточняющимися спецификациями множества продуктов, линеек продуктов, продуктовых платформ	Получение линейки продуктов и/или продуктовой платформы и процессов их разработки, производства, продажи и использования, которые дают запланированный бизнес-эффект и реализуют стратегию развития предприятия
Портфель	Эффективное использование ресурсов и возможностей предприятия	Выполнение краткосрочных финансовых  экономических показателей предприятия и положительная динамика этих показателей

Как устроено управление проектами организации?

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

Векторная диаграмма в высоком разрешении ПО ЭТОЙ ССЫЛКЕ

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

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

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

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

Современная матричная структура

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

Нужно понимать, что сейчас предприятия разбивают в двух плоскостях - как структуры подразделений (цех №2, СКТБ-15, корпоративный центр) и как орг.возможности (технологии имитационного и математического моделирования, автоматизированные системы интегрированного брифинга). Когда все необходимые компетенции и ресурсы для реализации орг.возможности совпадают со структурой подразделений, то говорят про функциональную организационную структуру. Все компетенции и ресурсы находятся в подчинении начальника подразделения и он ими распоряжается. В функциональных структурах часто получается так, что некоторые ресурсы недозагружены, и тогда им начинают ставить другие задачи, они становятся частью других орг.возможностей, например, инженеры отдела цифро-натурного моделирования изучают смежную дисциплину и технологии имитационного моделирования и часть времени работают над задачами симуляции и имитации в других проектах. В таких случаях говорят про матричную структуру организации. Орг.возможность является частью цепочки производственной кооперации. Например, программа разработки метеолокаторов может работать с внешними подрядчиками и заказчиками изолированно от всей остальной организации и почти с ней не взаимодействовать.

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

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

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

Деятельность по управлению портфелями, программами и проектами объединяется в системе управления ресурсами предприятия (ERP) и информационной системе управления проектами (ИСУП). В ИСУП поддерживаются текущие иерархические структуры работ (ИСР), расписание программы и дерево всех программ и проектов компании. В ERP осуществляется планирование финансов, материалов и персонала для операционной и проектной деятельности. Все работы программы делятся на пакеты планирования, а все работы проекта делятся на пакеты работ. Пакеты планирования распределяются между проектами программы, а пакеты работ распределяются между рабочими группами и отделами организации. В результате исполнения пакетов работ появляются системные элементы и рабочие продукты, которые сопровождают эти системные элементы - документация, данные измерений, обученный персонал. Системные элементы собираются в техническое решение, которое называется целевой системой. За целевую систему отвечает менеджер продукта.

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

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

На практике в инженерных компаниях численностью до 400 человек роли менеджера продукта и руководителя программы объединяются и один человек отвечает за финансовые, экономические и технические показатели продуктового направления.