БЕРЕЖЛИВОЕ УПРАВЛЕНИЕ ПРОГРАММАМИ ПРОЕКТОВ. Часть 2. Определение ключевых элементов системы управления программами. Организационное оформление программ проектов.

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

Оглавление

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

ОПРЕДЕЛЕНИЕ КЛЮЧЕВЫХ ЭЛЕМЕНТОВ СИСТЕМЫ УПРАВЛЕНИЯ ПРОГРАММАМИ

Выстраивая СУПД, мы всегда стремимся найти оптимальный баланс между затратами на создание и поддержание решений по СУПД и выгодами — положительными эффектами, получаемыми организацией вследствие ее применения. Подходы к управлению программами не являются исключением. С одной стороны, есть обширные знания, накопленные человечеством в области управления программами и изложенные во многих стандартах и методологиях [1, 4–8], с другой стороны — естественное желание не усложнять систему управления и вкладываться в создание только таких решений, которые учитывают потребности организации и позволяют получить выгоды, превосходящие затраты. Данный подход соответствует таким распространяемым в последнее время принципам построения СУПД, как бережливость, адаптивность, результативность и пр. К подобным рассуждениям приводят, например, тезисы, приведенные IPMA [5], о том, что для управления программой требуется целый ряд компетенций и что значимость этих компетенций может различаться в зависимости от типа проекта и отрасли.

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

Интересными примерами, когда предлагается идея подбора управленческих решений в зависимости от особенностей СУПД организации и реализуемых проектов, могут выступать, например, подходы к формированию проектных офисов и применению гибридных жизненных циклов. ГОСТ Р 58305-2018 описывает варианты организации проектных офисов и подход к выбору оптимального за счет увязки профиля проектного офиса и особенностей проектной деятельности. «Agile: практическое руководство» дает не только описание возможных жизненных циклов проектов, но и рекомендации по их комбинированию в зависимости от особенностей реализуемых проектов. Схожие подходы гибкого или бережливого подбора решений могут быть использованы при формировании системы управления программами в контексте конкретных организаций.

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

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

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

2.1. Организационное оформление программ проектов

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

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

Состав и порядок запуска программ

Для программ не предусматривается отдельных процедур подготовки и запуска. Все это остается на уровне отдельных проектов.

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

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

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

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

Программа как объект управления

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

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

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

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

В СУПД должны быть определены следующие правила:

• Может ли программа входить в разные портфели?
• Может ли программа включать другие программы?
• Могут ли проекты программы относиться к разным портфелям?
• Могут ли проекты одновременно входить в разные программы?

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

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

Команда управления

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

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

• уже существующим органом управления на уровне компании или портфеля проектов, если программа входит в некий портфель;
• руководителем программы.

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

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

Нормативное обеспечение

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

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

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

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