Бесплатный фрагмент - Механика проектного управления

Предисловие редакторов

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

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

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

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

При создании этого документа были использованы лучшие российские и международные наработки — в частности, национальные стандарты РФ, межгосударственные и международные стандарты, в том числе ИСО семейства 9000.

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

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

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

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

Издание содержит бизнес-кейс, доступно объясняющий, как сокращать (секвестировать) бюджет инвестиционной программы.

По сложившейся традиции мы не могли не сопроводить наше издание историческими очерками — срезом программно-целевого управления в России и мире, обзором крупномасштабного дореволюционного проекта электрификации всей страны, вылившегося в знаменитый план ГОЭЛРО, а также программно-целевых практик Госплана СССР и Кремниевой Долины (США).

                                                                    Эльдар Джураев,

                           Председатель Наблюдательного совета

                                                                              НИИ КПУ,

                                                           IoD Certificate Director

                                                                      Наталья Персод,

                                               Заместитель Председателя

                                   Наблюдательного совета НИИ КПУ,

                                                                                      к.э.н.

1. Общие положения

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

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

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

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

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

1. Управление содержанием проекта.

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

3. Управление человеческими ресурсами в проекте.

4. Управление интеграцией проекта.

5. Управление коммуникациями в проекте.

6. Управление стоимостью проекта.

7. Управление рисками и проблемными ситуациями проекта.

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

9. Управление закупками и контрактами проекта.

10. Управление заинтересованными лицами проекта.

Процесс управления проектом выполняется на протяжении всего жизненного цикла проекта и состоит из следующих временных периодов (фаз управления проектом):

1. Фаза инициирования.

2. Фаза планирования и организации.

3. Фаза выполнения и контроля.

4. Фаза завершения.

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

Таблица 1.1. Возможные варианты изменения состояний проекта

Модель жизненного цикла проекта представлена на рис. 1.1.

Различают следующие состояния проекта:

1. Инициируется. Выполняются операции фазы инициирования проекта.

2. Планируется. Выполняются операции фазы планирования и организации проекта.

3. Выполняется. Выполняются операции фазы выполнения и контроля проекта.

4. Завершается. Цель проекта достигнута. Выполняются операции фазы завершения проекта.

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

6. Отменен. Принято решение об отмене проекта (об отказе от реализации проекта). Выполняются операции фазы завершения проекта.

7. Завершен. Конечное состояние проекта после окончания фазы завершения.

2. Система управления проектом

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

Для реализации и управления проектом создается временная организационная структура (организационная структура проекта), которая включает:

1) уполномоченных представителей от всех заинтересованных лиц (заинтересованных сторон) проекта (вместе образуют круг заинтересованных лиц проекта);

2) команду проекта (проектную команду);

3) проектный офис (офис проекта).

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

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

1) Инвестор (Спонсор) — лицо, предоставляющее собственные, заемные или иные привлеченные финансовые средства для управления и реализации проекта;

2) Заказчик — лицо, уполномоченное Инвестором для реализации проекта;

3) Функциональный заказчик — лицо, являющееся потребителем (пользователем) результатов проекта и предъявляющее требования к планируемым результатам проекта;

4) Надзорный (контролирующий, регулирующий) орган — лицо, осуществляющее контроль и надзор за соблюдением требований к результатам проекта в определенной функциональной области (сфере);

5) Эксплуатирующая организация (Оператор) — лицо, осуществляющее эксплуатацию, поддержку и сопровождение результатов проекта;

6) Исполнитель (Генеральный проектировщик/подрядчик) — лицо, реализующее проект.

7) Эксперт/консультант/аудитор — лицо, оказывающее определенные консалтинговые услуги в интересах достижения цели проекта.

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

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

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

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

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

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

Модель типовой организационно-ролевой структуры проекта представлена на офис проекта.

Ролевая модель проекта включает следующие проектные роли:

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

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

5. Ответственный исполнитель (Исполнитель). Отвечает за решение поставленных ему в рамках проекта задач в требуемые сроки и с требуемым уровнем качества.

Все проектные роли должны быть описаны в Уставе (Паспорте) проекта (см. Приложения 11—12) и Матрице ответственностей проекта (см. Приложение 7.) Описание проектной роли должно содержать: функции, обязанности, полномочия и ответственности.

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

3. Процесс управления проектом

3.1. Управление содержанием проекта

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

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

Описание основных операций группы управления содержанием проекта (сгруппированные по фазам управления) приводится в Табл. 3.2.

Таблица 3.2. Операции группы управления содержанием проекта

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

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

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

В соответствии с действующей процедурой проведения комплексного план-факт анализа (см. п. 4.) осуществляется регулярный мониторинг и контроль сроков реализации проекта.

Описание основных операций группы управления сроками проекта (сгруппированные по фазам управления) приводится в Табл. 3.3.

Табл. 3.3. Операции группы управления сроками проекта

3.3. Управление человеческими ресурсами в проекте

Целью операций группы управления человеческими ресурсами в проекте является обеспечение проекта человеческими ресурсами (персоналом) требуемой квалификации и в необходимом количестве. Требования к квалификации персонала определяются в первую очередь объемом проекта, а количество привлекаемого персонала — требуемыми сроками реализации проекта.

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

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

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

В соответствии с действующей процедурой проведения комплексного план-факт анализа (см. п. 4.) осуществляется регулярный мониторинг и контроль ресурсной обеспеченности проекта.

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

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

Описание основных операций группы управления человеческими ресурсами в проекте (сгруппированные по фазам управления) приводится в Табл. 3.4.

Таблица 3.4. Операции группы управления человеческими ресурсами в проекте

3.4. Управление интеграцией проекта

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

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

Управление изменениями проекта должно включать следующие операции:

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

2) Рассмотрение запроса на изменение. Руководитель проекта организовывает и проводит рассмотрение, согласование и утверждение (отклонение) Запроса на изменение в соответствии с установленными в проекте правилами коммуникаций (см. п. 5.).

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

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

3) Актуализация Реестра изменений проекта. Информация по существу Запроса на изменение вносится Руководителем проекта в Реестр изменений проекта. Реестр изменений — это проектный документ, в котором ведется перечень (реестр) всех изменений проекта. Каждая запись реестра содержит следующую информацию об изменении: название и краткое описание, Ф.И.О. инициатора, текущий статус (внесено, принято, отклонено, реализовано), дата изменения статуса, оказываемое влияние на проект, Ф.И.О. ответственного за реализацию и перечень реализуемых мероприятий (см. Приложение 5.).

На основе информации из укрупненных Календарного графика проекта и Ресурсного плана проекта в соответствии с установленными в проекте правилами коммуникаций (см. п. 5.) разрабатывается, согласоваться и утверждается укрупненный План-график проекта. План-график проекта — это проектный документ, содержащий в структурированном по фазам, этапам и задачам (пакетам работ) виде перечень всех работ и вех (планируемых результатов и контрольных событий) проекта с зависимостями, длительностями (оценивается по аналогам, по нормативам или экспертным путем), привязкой к календарным датам их начала и завершения и необходимыми (доступными) для их выполнения ресурсами (укрупненными — должностями или компетенциями; детальными — фамилиями участников проекта). Стандартной формой для представления Плана-графика проекта является Диаграмма Ганта (см. Приложение 8.).

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

Длительность = (оптимистичная оценка + (4 * наиболее вероятная оценка) + пессимистичная оценка) / 6

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

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

Описание основных операций группы управления интеграцией проекта (сгруппированные по фазам управления) приводится в Табл. 3.5.

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

Еженедельно на основе актуальной информации из Устава проекта, Плана-графика проекта, карт рисков, проблемных ситуаций и изменений проекта, а также документов Репозитария проекта Руководитель проекта готовит Еженедельный отчет о статусе проекта (см. Приложение 4.). Еженедельный отчет о статусе проекта — это проектный документ, содержащий сводную информацию о степени завершенности проекта на момент его составления. В состав Отчета должна быть включена следующая информация: Общие сведения о проекте (название, данные об основных заинтересованных лицах и команде управления проектом, информация об отчетном периоде); плановые сроки реализации; состояние реализации текущих фаз, этапов и задач (% выполнения; фактические/прогнозные сроки; выявленные отклонения, причины их возникновения, прогнозируемые риски и перечень предупреждающих/корректирующих мероприятий); статус разработки проектной документации (наименование, плановые/прогнозные/фактические сроки завершения разработки, состояние разработки, причины задержки с разработкой и предложения по их устранению); основные достигнутые результаты за отчетный период и планируемые результаты на следующий отчетный период; перечень основных проблемных ситуаций (название и краткое описание, перечень действий по устранению; перечень реализовавшихся рисков, которые привели к проблеме; ответственный за устранение); перечень актуальных рисков проекта (название и краткое описание, уровень, стратегия реагирования, перечень действий до/после возникновения, ответственный за выявление, ответственный за реагирование). Согласование и утверждение Отчета осуществляется в соответствии с установленными в проекте правилами коммуникаций (см. п. 3.5.). Как правило, Отчет готовится Руководителем проекта к еженедельным статусным совещаниям проекта.

По факту завершения работ по проекту (фазы или этапа проекта) осуществляется передача Заказчику полученных результатов проекта. Перечень передаваемых результатов и порядок их передачи определяется установленными в проекте правилами коммуникаций (см. п. 3.5.) и положениями соответствующих контрактов. После передачи Заказчику результатов проекта установленным порядком формуется архив проекта. Архив проекта — это хранилище комплекта проектной документации в электронном виде. Архив проекта должен в обязательном порядке содержать электронные версии юридически значимых документов проекта с печатями и подписями, как правило, в формате Adobe PDF.

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

3.5. Управление коммуникациями в проекте

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

Порядок взаимодействия (коммуникации) участников проекта описывается в виде соответствующего регламента, который включается в Устав проекта.

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

— ведения электронной переписки;

— подготовки и проведения заседаний Управляющего совета и Оперативного совета;

— организации совместных работ представителями различных заинтересованных лиц и рабочих групп проекта; —

— разработки, согласования, утверждения, актуализации и уточнения проектных документов (в т. ч. Устава проекта, Плана-графика проекта и Бюджета проекта);

— формирования, согласования, утверждения и реализации Запросов на изменение;

— подготовки, согласования и представления различных видов отчетности участниками проекта;

— формирования информационных и прочих запросов и предоставления информации.

Описание основных операций группы управления коммуникациями в проекте (сгруппированные по фазам управления) приводится в Табл. 3.6.

Таблица 3.6. Операции группы управления коммуникациями в проекте

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

Передача знаний производится:

— от Руководителя проекта Кураторам проекта;

— от членов рабочих (проектных) групп со стороны Исполнителя членам рабочих групп со стороны Заказчика и Функционального заказчика.

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

По завершению работ по проекту Руководитель проекта проводит итоговое совещание по проекту, на котором рассматривается Отчет о завершении проекта (см. Приложение 13.) и Итоговый отчёт об исполнении Бюджета проекта (см. Приложение 9.).

3.6. Управление стоимостью проекта

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

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

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

В соответствии с действующей процедурой проведения план-факт анализа (см. п. 4.) осуществляется регулярный мониторинг и контроль финансовых показателей и ресурсов проекта.

Описание основных операций группы управления стоимостью проекта (сгруппированные по фазам управления) приводится в Табл. 3.7.

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

3.7. Управление рисками и проблемными ситуациями проекта

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

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

В регламенте управления рисками проекта должны быть описаны следующие операции:

— выявление и анализ рисков;

— планирование реагирования на риски;

— мониторинг и администрирование рисков.

Типовой процесс управления рисками проекта описывается в пп. 3.7.1.

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

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

В регламенте управления проблемными ситуациями проекта должны быть описаны следующие операции:

— выявление и анализ проблемных ситуаций;

— принятие решений по проблемным ситуациям;

— исполнение принятых решений по разрешению проблемных ситуаций.

Типовой процесс управления проблемными ситуациями проекта описывается в пп. 3.7.2. Для учета проблемных ситуаций проекта используется Карта проблем проекта (Приложение 3.). Карта проблем проекта — проектный документ, в котором ведется перечень (реестр) проблем проекта. Каждая запись реестра содержит следующую информацию о проблеме: название и ее краткое описание, перечень действий по устранению; перечень реализовавшихся рисков, которые привели к проблеме; ответственный за устранение.

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

Таблица 3.8. Операции группы управления рисками и проблемными ситуациями проекта

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

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

— выявление и анализ рисков;

— планирование реагирования на риски;

— мониторинг и администрирование рисков.

Выявление рисков

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

Источниками информации для выявления рисков проекта являются:

1) Договорные документы;

2) Проектные (технические) решения;

3) Ресурсы;

4) План-график проекта;

5) Подрядчики.

Выявление рисков может выполняться путем:

• анализа документации проекта (планов, допущений, архивов предыдущих проектов и других документов) на предмет их соответствия предъявляемым требованиям;

• сбора информации (используются различные методы: мозговой штурм, метод Дельфи, проведение опросов, SWOT-анализ и др.);

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

• анализа допущений проекта;

• формирования диаграмм (например, причинно-следственных связей (диаграмма Ишикавы), зависимостей процесса, диаграмма влияния и др.).

По каждому выявленному риску Руководитель проекта совместно с Руководителями проектных групп и Кураторами проекта формируют соответствующую запись в Карту рисков проекта.

Анализ рисков

Анализ рисков проводится в разрезе качественных и количественных показателей рисков.

Качественный анализ рисков включает в себя расстановку приоритетов для каждого выявленного риска. Расстановка приоритетов проводится на основании анализа следующих факторов рисков:

• вероятности возникновения риска;

• степени влияния (воздействия) риска на достижение целей проекта (в случае реализации риска);

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

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

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

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

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

Планирование реагирования на риски

План реагирования на риски проекта разрабатывается Руководителем проекта совместно с Руководителями проектных групп и Кураторами проекта и предполагает последовательное выполнение следующих действий:

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

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

3) для каждой выбранной стратегии разрабатываются конкретные действия (мероприятия) по ее реализации — предупреждающие и/или корректирующие.

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

Основными стратегиями реагирования на риски являются:

1. Стратегии реагирования на негативные риски (угрозы):

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

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

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

2. Стратегии реагирования на позитивные риски (благоприятные возможности):

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

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

2.3. Усиление. Стратегия направлена на повышение вероятности возникновения и/или положительного воздействия благоприятной возможности. Повышение вероятности может достигаться, например, путем целенаправленного усиления условий появления благоприятной возможности.

3. Общая стратегия реагирования на угрозы и благоприятные возможности:

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

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

4. Стратегия реагирования на непредвиденные обстоятельства:

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

Результаты, полученных в ходе планирования реагирования на риски проекта вносятся Руководителем проекта в Карту рисков проекта.

Мониторинг и администрирование рисков

Операции мониторинга и администрирования рисков являются непрерывными и выполняются на протяжении всего жизненного цикла проекта в рамках процедуры комплексного план-факт анализа.

В рамках данной операции выполняются следующие действия:

1) пересмотр рисков (выявление новых рисков, отслеживание уже возникших рисков, а также тех рисков, которые уже выявлены и находятся под постоянным наблюдением);

2) анализ отклонений и резервов;

3) аудит рисков (проверка и выполнение операций реагирования на риски, а также оценка их эффективности);

4) совещания по текущему состоянию (статусу) проекта.

1. Пересмотр рисков

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

2. Анализ отклонений и резервов

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

Анализ резервов проводится с целью определения адекватности соответствия резервов проекта оставшимся рискам по состоянию на текущий момент времени.

3. Аудит рисков

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

4. Совещания по текущему состоянию (статусу) проекта

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

3.1.2. Управление проблемными ситуациями проекта

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

— выявление и анализ проблемных ситуаций;

— принятие решений по проблемным ситуациям;

— исполнение принятых решений по разрешению проблемных ситуаций.

Выявление и анализ проблемных ситуаций

Проблемная ситуация может быть выявлена следующими основными способами:

• непосредственно участниками проектной команды в ходе реализации проекта;

• из обращения (жалобы) заказчиков/подрядчиков/партнеров.

Информация о выявленной проблемной ситуации доводится до Руководителя проекта.

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

Если проблемная ситуация связана с ранее выявленным риском, то вся информация, сформированная при управлении данным риском, используется для анализа проблемной ситуации.

Информация о проблемной ситуации заносится Руководителем проекта в Карту проблемных ситуаций проекта.

1) Принятие решения по проблемной ситуации

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

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

Принятие решения по проблемной ситуации в рамках проектной команды.

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

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

Распространение нерешенных проблемных ситуаций на уровень Куратора проекта.

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

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

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

Принятое решение фиксируется в протоколе заседания ОС.

Распространение нерешенных проблемных ситуаций на уровень Управляющего совета.

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

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

Принятое решение фиксируется в протоколе заседания УС.

2) Исполнение принятого решения

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

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

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

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

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

• проведение регулярных проверок полученных результатов на предмет их соответствия критериям качества;

• оперативное информирование заинтересованных лиц о потенциальных проблемах и рисках, связанных с качеством;

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

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

1. Внешний контроль качества.

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

Контроль качества может осуществляться в следующих формах:

• анализ документации проекта;

• интервью с ключевыми участниками проекта;

• анализ результатов на соответствие их критериям качества;

• непосредственное участие в работе органов управления проектом, участие в заседаниях / совещания / встречах.

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

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

2. Внутренний контроль качества.

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

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

В соответствии с действующей процедурой проведения комплексного план-факт анализа (см. п. 4.) осуществляется регулярный мониторинг и контроль соответствия результатов проекта критериям качества.

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

Описание основных операций группы управления качеством проекта (сгруппированные по фазам управления) приводится в Табл. 3.9.

Таблица 3.9. Операции группы управления качеством проекта

3.9. Управление закупками и контрактами проекта

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

Исходя из требований к результатам проекта, с учетом Плана-графика проекта формируются предварительный перечень контрагентов и предварительный план закупок проекта. План закупок проекта — проектный документ, содержащий перечень товаров и/или услуг, которые должны быть приобретены (закуплены и поставлены) в рамках проекта, а также информация о контрагенте (планируемом контрагенте) и планируемые сроки поставки. Контрагент — сторона, принявшая обязательство по договору и противопоставляемая другой стороне договора. Договор (контракт) — соглашение двух или более лиц (физических и/или юридических) — контрагентов (сторон договора), устанавливающее, изменяющее или прекращающее их права и обязанности. Договор, как правило, состоит из общей и содержательной частей. Договором также именуется документ, в котором это соглашение выражено. Общая часть договора — часть текста договора, включающая следующие разделы: Преамбула (или вводная часть); Предмет договора; Дополнительные условия договора; Прочие условия договора. Содержательная часть договора — часть текста договора, содержащая приложения и дополнительные соглашения к договору, например, Задание (техническое задание) на выполнение работ по договору; Протокол соглашения о договорной цене; Расчёт договорной цены; Календарный график выполнения работ по договору и др. Закупка — приобретение товаров и/или услуг для определенных нужд (целей). Поставка — передача товара во владение покупателя в соответствии с условиями договора; покупатель получает возможность осуществлять полный контроль над товаром. Вручение товаросопроводительных документов рассматривается как передача самого товара. Поставка, как правило, производится за счет продавца. План закупок проекта подлежит регулярному уточнению и детализации в рамках процесса управления интеграцией проекта (см. п. 4.).

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

В соответствии с действующей процедурой проведения комплексного план-факт анализа осуществляется регулярный мониторинг и контроль исполнения контрактов контрагентами.

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

Описание основных операций группы управления закупками и контрактами проекта (сгруппированные по фазам управления) приводится в Табл. 3.10.

Табл. 3.10. Операции группы управления закупками и контрактами проекта

3.10. Управление заинтересованными лицами проекта

Целью операций группы управления заинтересованными лицами (ЗЛ) проекта является обеспечение постоянной вовлеченности в проект (на требуемом уровне) ключевых заинтересованных лиц проекта.

Исходя из описания объема проекта проводится анализ всех заинтересованных сторон, имеющих отношение к проекту, с целью выявить ключевых заинтересованных лиц — группы физических и/или юридических лиц, имеющих безусловный интерес в достижении цели проекта. Путем интервьюирования ключевых заинтересованных лиц проекта выявляется весь круг заинтересованных лиц проекта, который фиксируется в Реестре заинтересованных лиц проекта (см. Приложение 11.). Реестр заинтересованных лиц проекта — проектный документ, в котором ведется перечень (реестр) всех выявленных заинтересованных лиц проекта. Каждая запись реестра содержит следующую информацию о заинтересованном лице: Ф.И.О. заинтересованного лица, его должность, категория, роль в проекте, уровень полномочий, уровень заинтересованности, уровень вовлеченности, базовый сценарий работы с ЗЛ и контактная информация (телефон, адрес эл. почты).

Для каждого заинтересованного лица необходимо определить его ожидания, потребности, интересы, степень влияния и потенциального воздействия на успех проекта. На основе собранной информации проводится качественный анализ и категорирование заинтересованных лиц по следующим критериям: 1) уровень полномочий (степень влияния) в проекте: низкий, средний, высокий; 2) уровень заинтересованности в результатах проекта: низкий, средний, высокий; 3) уровень вовлеченности в проект: «неосведомлённое» (заинтересованное лицо не осведомлено о проекте); «сопротивляющееся» (заинтересованное лицо осведомлено о проекте и сопротивляется вовлечению в проект (незаинтересованно в успехе проекта)); «нейтральное» (заинтересованное лицо осведомлено о проекте, не сопротивляется вовлечению в проект, но безразлично к достижению результатов); «поддерживающее» (заинтересованное лицо вовлечено в проект и поддерживает достижение его результатов); «лидирующее» (заинтересованное лицо активно вовлечено в проект и заинтересованно в его успехе). Исходя из полученных результатов выбирается целевая стратегия работы с заинтересованным лицом (см. Табл. 3.10). Результаты анализа фиксируется в Реестре заинтересованных лиц проекта.

Таблица 3.11. Матрица сценариев работы с заинтересованными лицами

Реестр заинтересованных лиц проекта подлежит регулярному уточнению и детализации в рамках процесса управления интеграцией проекта (см. п. 4.).

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

Описание основных операций группы управления заинтересованными лицами (сгруппированные по фазам управления) приводится в Табл. 3.11.

Таблица 3.12. Операции группы управления заинтересованными лицами проекта

Дополнительные материалы

4. Статья С. С. Арутюнова: «Программно-целевое управление: исторический срез»

Определяя суть

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

Чтобы пояснить сущность ПЦУ на конкретном примере, мысленно представим себе Египет времен Древнего Царства. Итак, 2589—2566 до нашей эры, время Четвертой династии, властитель Египта — фараон Хеопс (Хуфу), желающий, как все египетские фараоны, заслужить наибольшее благоволение богов. Это — цель первостепенная, по сравнению с целями военно-политическими, экономическими и социальными. То4чнее, эти цели выступают средствами достижения основной цели — благоволения богов, а главным инструментом убеждения богов в том, что фараон Хеопс достоин его, выступает строительство самой большой в мире пирамиды (здесь мы допустим, что именно Хеопс построил ее, в чем есть сомнения, но в данном случае это неважно).

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

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

В данной статье мы постараемся осветить наиболее известные случаи применения программно-целевого управления в истории нашей страны.

ПЦУ в Советской России

Первые попытки использовать программно-целевой подход в отечественном территориальном планировании начались в 20—30-е гг. XX века — как будет видно, не без участия иностранных специалистов.

Наиболее проработанными с точки зрения внедрения методов ПЦУ были такие проекты, как план ГОЭЛРО, Урало-Кузнецкий комбинат, освоение Хибин, строительство лесоэкспортного порта Игарка на Енисее и дальневосточного «Города Солнца» Комсомольска-на-Амуре.

Накопленный за семь десятилетий советским программно-целевым управлением опыт, в частности, централизованного стратегического планирования, не раз адаптировался для своих нужд развитыми странами мира, включая США, Японию, Китай и др., однако в 1991 году, когда был ликвидирован Госплан СССР, этот опыт решено было использовать при формировании федеральных целевых программ.

Сегодня в Российской Федерации ПЦУ применяется в государственном и муниципальном управлении социальной сферой.

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

Однако перед тем, как ПЦУ завоевало широкое признание как эффективный инструмент, оно прошло долгий путь апробации на конкретных проектах.

«Первой ласточкой» использования ПЦУ в Советской России стал план ГОЭЛРО. Эффект от реализации Плана превысил самые смелые ожидания экономистов: еще недавно преимущественно аграрная страна с низким уровнем механизации, испытавшая, к тому же, военные тяготы, за полтора десятилетия практически перешла на промышленные рельсы.

Таким образом, с аббревиатурой ГОЭЛРО оказался связан если не старт индустриальной эры, то новая и самая, пожалуй, значимая фаза модернизации советской экономики.

ГОЭЛРО: от программы к реализации

ГОЭЛРО — сокращение от наименования Государственной комиссии по электрификации России — орган, созданный 21 февраля 1920 года для разработки проекта электрификации России. Аббревиатура часто расшифровывается также как Государственный план электрификации России, то есть, продукт деятельности комиссии ГОЭЛРО, ставший первым после революции 1917 года перспективным планом развития экономики.

Цели ГОЭЛРО были предельно ясны с самого начала: создание достаточного для модернизации промышленного и социально-бытового секторов количества генерирующих мощностей. Неслучайно символом плана ГОЭЛРО стала «лампочка Ильича», пришедшая на смену извечной лучине или керосиновой лампе — единственных в подавляющем большинстве крестьянских и городских домовладений источником искусственного освещения. Маломощная, «лампочка Ильича» выполнила еще и идеологическую функцию: электричество, проведенное в российские дома, повысило доверие к советской власти, как ничто иное.

Ленинскую формулу «Социализм есть советская власть плюс электрификация всей страны» многие из нас помнят по школьным учебникам, мало отдавая себе отчет в ее реальном наполнении. В 1920 году, менее чем за один год, ленинское правительство разработало перспективный план электрификации страны, для чего была создана Комиссия по разработке плана электрификации под руководством видного партийного и государственного деятеля, старого члена партии Г. М. Кржижановского. К работе комиссии было привлечено около 200 ученых и инженеров. В рамках проекта было проведено экономическое районирование, выделен транспортно-энергетический каркас территории страны.

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

ГОЭЛРО был планом развития не только энергетики, но и всей экономики: он предусматривал строительство предприятий, привязанное к планам развития территорий. Например, за счет заложенного в 1927 году Сталинградского тракторного завода им. Ф. Э. Дзержинского (СТЗ) развивалась одна из самых значимых не только в народно-хозяйственном, но и оборонном смысле, промышленных зон Юга России, а за счет Кузнецкого угольного бассейна — целый регион.

План ГОЭЛРО, рассчитанный на 10–15 лет, предусматривал строительство 30 районных электрических станций (20 ТЭС и 10 ГЭС) общей мощностью 1,75 млн кВт, среди них — Штеровская, Каширская, Нижегородская, Шатурская, Челябинская ТЭС, а также Нижегородская, Волховская, Днепровская ГЭС, две станции на реке Свирь и мн. др.

План в основном был перевыполнен к 1931 году. Выработка электроэнергии в 1932 году по сравнению с 1913 годом увеличилась не в 4,5 раза, как планировалось, а почти в 7 раз: с 2 до 13,5 млрд кВт·ч.

Электроэнергия стала применяться в сельском хозяйстве: в мельницах, кормовых резцах, зерноочистительных машинах, на лесопилках и т. д.

Урало-Кузнецкий комбинат: русские руки, чикагская сборка

В декабре 1925 года XIV съезд ВКП (б) одобряет проведение сплошной индустриализации. Справедливости ради, индустриализация — идея еще дореволюционная, не реализованная, в первую очередь, из-за Первой Мировой войны и последовавшей за ней революции.

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

В отличие от затянувшегося более чем на десятилетие строительства Бакальского (Челябинского) и Нижнетагильского металлургических комбинатов, КМК и «Магнитка» (Магнитогорский металлургический комбинат) оказались проектами более успешными. Помимо обеспеченности трудовой силой, Урало-Кузнецкий комбинат (так изначально назывался проект создания «Магнитки» и КМК) создавался по иностранному проекту при активном участии крупных компаний и сотен специалистов из США, Франции и Германии, которые побывали с инспекционной поездкой на Урале и в Сибири еще летом 1917 года.

Постановлением Президиума ВСНХ 28 марта 1918 года был создан Уральский горнозаводской комитет, которому поручалось выяснить природные богатства Урала и Кузнецкого бассейна и составить планы их наиболее рационального использования. В июне 1918 года при горно-металлургическом отделе ВСНХ была создана Уральская комиссия, которой было поручено координировать работы по проектированию. Изначально решение проблемы виделось в организации встречных транспортных потоков — уголь из Сибири на Урал, в обратном направлении — руда. Впервые была высказана идея «маятника»: уголь Кузбасса — Уралу, руда Урала — Кузбассу. Однако к 1921 году стало понятно, что необходимо закладывать железорудные предприятия и в самой Сибири.

В конце 1925 года при Совете Труда и Обороны была создана специальная комиссия, на которую была возложили задачу подготовки технико-экономического обоснования Урало-Кузнецкого проекта и выбора оптимальных площадок строительства. В феврале 1926 года ВСНХ утвердил в качестве рудной базы будущего кузнецкого завода Тельбесское месторождение (поэтому изначально проект КМК получил название Тельбесского) в Горной Шории, промышленные запасы железорудных месторождений которой определялись в 15—18 миллионов тонн, что обеспечивало завод на 20—25 лет работы.

К ноябрю 1926 года ВСНХ разработал ориентировочный пятилетний план развития Сибири, согласно которому в Кузбассе предусматривалось строительство завода годовой мощностью в 330 тыс. тонн чугуна. Совет Труда и Обороны предложил ВСНХ СССР не позднее 1928 года приступить к сооружению производственных цехов Тельбесского завода. По решению Президиума ВСНХ от 22 марта 1928 года был создан Тельбесстрой, на который возлагалось сооружение металлургического завода, угольных рудников в Осинниках и Араличевских железных рудников в Горной Шории.

15 января 1929 года Совет по Труду и Обороне принял постановление о строительстве Кузнецкого комбината, мощность которого была уже определена в 820 тыс. тонн чугуна в год. В 1930 году базовая мощность комбината была поднята до 1,2 млн тонн чугуна. Это полностью согласовывалось с первым пятилетним планом, принятым на XVI партийной конференции в 1929 году: согласно ключевым показателям плана, в стране предполагалось увеличить производство чугуна почти в три раза — до 10 млн тонн, а всего было одобрено строительство порядка 20 крупных предприятий черной металлургии (Магнитка, КМК, Криворожсталь, Днепровский комбинат и ряд других).

«Директивами партии и правительства, из которых основной является решение XVI партийного съезда, начат строительством грандиозный Урало-Кузнецкий комбинат (УКК), определяющий на десятки лет развитие огромных пространств, входящих в его состав. Комплексное развитие входящих в него отраслей, тесно увязанных между собой, — такова основная идея комбината. Металл и уголь — таков основной его остов. Грандиозный комбинат может и должен строиться по принципу районных и отраслевых комплексов, подчиненных общей идее комбинирования, объединения их в одно неразрывное целое. При гигантских размерах комбината ясна исключительная роль, с одной стороны, транспортного звена, с другой — передачи электроэнергии на дальние расстояния. Вот почему априорно надо сказать, что крупнейшее железнодорожное строительство, притом рассчитанное на освоение мощных грузопотоков, и сравнительно еще более крупное (ввиду отсутствия ранее существовавшей базы) электростроительство должны опережать темпы развития УКК», — пишет в статье «Электрификация СССР в пределах генерального плана» историк, статистик, экономист, доктор географических наук Николай Яницкий.

Опыта в строительстве и детальном проектировании таких предприятий у советских специалистов практически не было, поэтому было принято единственное возможное решение: привлечь к сотрудничеству зарубежные компании. К августу 1927 года специалисты Гипромеза подготовили технические задания для проектирования будущего КМК и передали их в американскую фирму Freyn Engineering Company (США, Чикаго), которая в том же году подписала с советским правительством рамочный договор на оказание консультационных услуг сталеплавильной промышленности. В 1928 году Freyn подписывает договор на проектирование будущего КМК. По этому предприятию непосредственное проектирование осуществлялось в Чикаго, а рабочие чертежи делались в СССР. Над ними работали смешанные группы советских и американских специалистов. Параллельно с этим одобрение проект получил на высшем политическом уровне: 7 февраля 1928 года Политбюро ЦК ВКП (б) одобрило подготовленные проекты СНК по строительству Магнитогорского, Кузнецкого и Керченского металлургических заводов.

В октябре 1928 года ВСНХ принял решение выделить 3 млн рублей на подготовительные и разведочные работы строительства Тельбесского завода. Еще 2 млн рублей было выделено Госпланом на строительство железной дороги до угольного и железорудного месторождений. После принятия XVI партконференцией первого пятилетнего плана, 20 апреля 1929 года ВСНХ утверждает предварительный проект КМК, в составе которого должны находиться: 4 домны, сталеплавильный, прокатный цеха, электростанция и коксовые батареи.