БЕРЕЖЛИВОЕ УПРАВЛЕНИЕ ПРОГРАММАМИ ПРОЕКТОВ. Часть 1. Введение. Потребность в применении принципов управления программами проектов.

Весной прошлого года в журнале «Управление проектами и программами» Михаил Козодаев, Управляющий партнер ГК «Проектная ПРАКТИКА», рассказал о своем видении бережливого подхода к построению системы управления программами.
Сегодня мы можем поделиться с вами полным текстом этого материала.

Оглавление

Введение
1. Потребность в применении принципов управления программами проектов
2. Определение ключевых элементов системы управления программами
2.1 Организационное оформление программ проектов
2.2 Управление взаимосвязями проектов программы
2.3 Управление общими для проектов программы наиболее важными рисками
2.4 Поддержка системы принятия решений в рамках программы с учетом бизнес-выгод
3. Область применения
Заключение

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

ВВЕДЕНИЕ

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

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

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

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

ПОТРЕБНОСТЬ В ПРИМЕНЕНИИ ПРИНЦИПОВ УПРАВЛЕНИЯ ПРОГРАММАМИ ПРОЕКТОВ

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

Пример №1

Крупная компания реализовывала проект по реконструкции завода. Работа была запланирована на несколько лет. Бюджет проекта составлял несколько миллиардов рублей. В рамках проекта предусматривалась реконструкция нескольких десятков изолированных объектов, а также создавалась общая инфраструктура, объединяющая их. Часть работ выполнялась своими силами (привлекались дочерние структуры), для выполнения большей части работ был привлечен зарубежный подрядчик.

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

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

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

Пример №2

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

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

Пример №3

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

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

Пример №4

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

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

Команда управления выработала новый подход. Он учитывал взаимовлияние решаемых в проекте задач, возможность и невозможность одновременной реализации рисковых событий, подразумевал выполнение командой управления более детального анализа рисков. Теперь риски разделялись на группы: группа 1 — риски, имеющие отношение только к конкретной задаче; группа 2 — риски, так или иначе связанные с реализацией нескольких задач. Данный подход позволил пересмотреть оценки по резервам и существенно снизить объем требуемого финансирования.

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

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

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

Далее речь пойдет в большей степени об управлении программами проектов, поэтому, переходя к основным разделам, можно сформулировать базовое для последующих размышлений утверждение: проработка 20% элементов СУПП может позволить организации получить 80% пользы, которую способна дать такая система. Дело за малым — определить эти элементы СУПП и «вписать» их в контекст СУПД организации.

Продолжение следует…

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