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

Содержание

В продолжение первой публикации «Как разработать корпоративную методологию управления проектами»- в данном материале мы рассмотрим основной документ выше упомянутой методологии — Положение «О корпоративной системе управления проектами» или Корпоративный стандарт по управлению проектами, а также шаблоны следующих рабочих документов проекта, рекомендованных PMI к разработке при управлении проектом:

Устав проекта (project charter);
Документ, определяющий содержание проекта (project scope statement (preliminary and detailed);
План управления проектом (project management plan).

КОРПОРАТИВНЫЙ СТАНДАРТ ПО УПРАВЛЕНИЮ ПРОЕКТАМИ

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

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

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

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

Подходы, описанные во втором и третьем случае, по нашему мнению, имеют определенные недостатки.

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

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

Разработке корпоративного стандарта может предшествовать создание концепции управления проектами в компании.

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

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

В корпоративный стандарт целесообразно включать следующие разделы:

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

УСТАВ ПРОЕКТА (PROJECT CHARTER)

Устав проекта (рroject charter) — один из самых «мифологизированных» рабочих документов проекта. Краткость описания этого документа в основном стандарте PMI — PMBOK в редакциях 2000 и 1996 года, с лихвой окупается богатством интерпретаций предназначения и содержания данного документа как российскими, так и зарубежными экспертами в области управления проектами.

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

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

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

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

Предназначение документа: Устав проекта предназначен для определения проекта. На фазе инициализации, он включает в себя:

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

Когда разрабатывается документ: после заключения контракта (если заключается контракт с внешним контрагентом)

Кто разрабатывает документ: Устав проекта могут разрабатывать:

менеджер проекта или команда проекта;
инициатор проекта;
спонсор проекта;
представитель внешней стороны, связанной с проектом.

Кто утверждает документ: Устав проекта может утверждать:

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

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

Входы (исходные данные) для разработки документа:

контракт;
документ определения работ (Statement of work);
факторы внешнего окружения и организационной среды;
организационные активы (Organizational process assets).

Содержание документа: Устав проекта непосредственно включает в себя следующие данные или ссылки на соответствующие документы:

Бизнес-потребности или требования к продукту, который будет создан в рамках проекта;
Цель проекта или основание для разработки проекта (justification);
Потребности и ожидания заинтересованных лиц (stakeholders);
Укрупненное расписание контрольных событий;
Влияние заинтересованных лиц на проект;
Распределение функций (functional organizations);
Предположения, связанные с внешним окружением и внутренней организационной средой;
Ограничения, связанные с внешним окружением и внутренней организационной средой;
Бизнес-обоснование проекта, включающее возврат на инвестиции (ROI);
Укрупненный бюджет.

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

ДОКУМЕНТ, ОПРЕДЕЛЯЮЩИЙ СОДЕРЖАНИЕ ПРОЕКТА (PROJECT SCOPE STATEMENT (preliminary and detailed)

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

Предназначение документа: PROJECT SCOPE STATEMENT (preliminary или предварительный) необходим для высокоуровневого определения проекта (что должно быть сделано) и включает в себя:

Характеристики и рамки проекта;
Требования к продуктам и услугам, связанным с проектом.

Когда разрабатывается документ: После утверждения Устава проекта.

Кто разрабатывает документ: PROJECT SCOPE STATEMENT (preliminary) могут разрабатывать:

менеджер проекта или команда проекта;
представители внешней стороны, связанной с проектом, на основе информации, предоставленной инициатором или спонсором проекта.

Кто утверждает документ: PROJECT SCOPE STATEMENT (preliminary) может утверждать:

спонсор проекта;
представитель внешней стороны, связанной с проектом.

Входы (исходные данные) для разработки документа:

Устав проекта;
документ определения работ (Statement of work);
факторы внешнего окружения и организационной среды;
организационные активы (Organizational process assets).

Содержание документа: PROJECT SCOPE STATEMENT (preliminary) включает в себя:

Цели проекта и цели предметной области проекта;
Требования и характеристики продукта или услуги;
Рамки проекта;
Проектные решения (deliverables);
Критерии приемки продукта;
Проектные ограничения;
Проектные предположения;
Организация проекта на начальной стадии;
Идентификация рисков на начальной стадии;
Расписание контрольных событий;
Предварительный расчет стоимости (Order of magnitude cost estimate);
Требования к управлению конфигурацией проекта;
Согласованные требования (Approval requirements).

Порядок изменений документа: Команда проекта осуществляет дальнейшую разработку PROJECT SCOPE STATEMENT (preliminary), на этапе определения содержания проекта прорабатывает данный документ более детально (статус PROJECT SCOPE STATEMENT изменяется с preliminary на detailed), а также осуществляет контроль изменений документа.

ПЛАН УПРАВЛЕНИЯ ПРОЕКТОМ (PROJECT MANAGEMENT PLAN)

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

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

Когда разрабатывается документ: План управления проекта разрабатывается после утверждения Устава проекта и PROJECT SCOPE STATEMENT (preliminary). Если последние два документа не разрабатываются, то после сбора или приобретения соответствующей информации.

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

Кто утверждает документ: План управления проектом может утверждать:

спонсор проекта;
представитель внешней стороны, связанной с проектом.

Входы (исходные данные) для разработки документа:

Устав проекта;
Project Scope Statement (preliminary);
Процессы управления проектом;
Прогнозы
Факторы внешнего окружения и организационной среды;
Организационные активы (Organizational process assets);
Информация о выполнении работ.

Содержание документа: План управления проектом документирует:

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

План управления проектом может суммировать/объединять все отдельные планы проекта или некоторые из них:

План управления содержанием;
План управления расписанием;
План управления стоимостью;
План управления качеством;
План улучшений;
План управления персоналом;
План управления коммуникациями;
План управления рисками;
План управления поставками.

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

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

А.Ю.Сооляттэ, партнер ИП «Finexpert.ru», адрес электронной почты —info@finexpert.ru.

Приложение

ПРИМЕРЫ УСТАВОВ ПРОЕКТОВ КОМПАНИЙ

Пример 1. УСТАВ ПРОЕКТА (международная компания, занимающаяся производством компьтерной техники, разработкой программного обеспечения и проектами в сфере системного интеграции).

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

Данный документ — Устав проекта — уточняется/изменяется и утверждается заново на каждой из стадий: на стадии предложения, на стадии исполнения (после подписания контракта).

СОДЕРЖАНИЕ:
1. Обзор Устава проекта
2. Организация проекта
2.1. Менеджер Проекта по интегрированию систем
2.2. Привлеченная команда по системному интегрированию
2.3. Роли и обязанности
2.4. Полномочный орган по финансированию Проекта
2.5. Комитет спонсоров Проекта
2.6. Комитет директоров Проекта
3. Краткое изложение требований по системному интегрированию
3.1. Обзор системного интегрирования
3.2. Определение потребности в системном интегрировании
3.3. Содержание и цели системного интегрирования
3.4. Факторы и риски, влияющие на системное интегрирование
4. Краткие сведения по Проекту
4.1. Описание
4.2. Процессы Проекта
5. Деятельность по интегрированию системы и поставляемые позиции
5.1.1. Работы Этапа I
5.1.2. Поставляемые позиции Этапа I
5.1.3. Работы Этапа II
5.1.4. Поставляемые позиции Этапа II
5.1.5.Работы этапа III
5.1.6. Поставляемые позиции Этапа III
5.1.7. Работы Этапа IV
5.1.8. Поставляемые позиции Этапа IV
5.1.9. Работы Этапа V
5.1.10. Поставляемые позиции Этапа V
6. Графики хода процессов
7. Документация

Пример 2. УСТАВ ПРОЕКТА (международная компания, занимающаяся разработкой и внедрением информационных систем)

СОДЕРЖАНИЕ:
1 ВВЕДЕНИЕ
1.1 НАЗНАЧЕНИЕ ДАННОГО ДОКУМЕНТА
1.2 ИЗМЕНЕНИЯ ДАННОГО ДОКУМЕНТА
2 ОПРЕДЕЛЕНИЕ ПРОЕКТА
2.1 НАЗНАЧЕНИЕ ПРОЕКТА
2.2 ЦЕЛИ ПРОЕКТА
2.3 НЕОБХОДИМЫЕ УСЛОВИЯ ДЛЯ ДОСТИЖЕНИЯ ПОСТАВЛЕННЫХ ЦЕЛЕЙ
3 РАМКИ ПРОЕКТА
3.1 ЛОГИЧЕСКИЕ РАМКИ ПРОЕКТА НА МОМЕНТ ЕГО НАЧАЛА
3.2 ВРЕМЕННЫЕ РАМКИ ПРОЕКТА
4 ОРГАНИЗАЦИЯ И УПРАВЛЕНИЕ ПРОЕКТОМ
4.1 ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2 РАСПРЕДЕЛЕНИЕ РОЛЕЙ УЧАСТНИКОВ ПРОЕКТА
4.2.1 Спонсор Проекта
4.2.2 Управляющий Совет
4.2.3 Председатель Управляющего Совета
4.2.4 Руководители Проекта
4.2.5 Группа внедрения
4.2.6 Состав группы внедрения
4.3 ДОКУМЕНТООБОРОТ ПРОЕКТА
4.3.1 Общие документы
4.3.2 Отчетные документы
4.3.3 Рабочие документы
4.3.4 Периодичность подготовки отчетной документации
4.4 ПРОЦЕДУРА РЕШЕНИЯ ПРОБЛЕМ
4.5 ПОДХОД К УПРАВЛЕНИЮ ИЗМЕНЕНИЯМИ РАМОК ПРОЕКТА
5 ЗАВЕРШЕНИЕ ПРОЕКТА
ПРИЛОЖЕНИЕ 1 — ДЕКЛАРАЦИЯ ЦЕЛЕЙ ВНЕДРЕНИЯ ИИСУ НА ОАО «ХХХ»
ПРИЛОЖЕНИЕ 2 — СПИСОК ФУНКЦИЙ АВТОМАТИЗИРУЕМЫХ ПОДРАЗДЕЛЕНИЙ.
ПРИЛОЖЕНИЕ 3 — ФОРМА РЕГИСТРАЦИИ ПРОБЛЕМЫ
ПРИЛОЖЕНИЕ 4 — ЖУРНАЛ РЕГИСТРАЦИИ ПРОБЛЕМ
ПРИЛОЖЕНИЕ 5 — ИНДИВИДУАЛЬНЫЙ ОТЧЕТ О ПРОРАБОТАННОМ ВРЕМЕНИ
ПРИЛОЖЕНИЕ 6 — ОТЧЕТ РУКОВОДИТЕЛЯ ПРОЕКТА
ПРИЛОЖЕНИЕ 7 — РЕГУЛЯРНЫЙ ОТЧЕТ О СОСТОЯНИИ ПРОЕКТА
ПРИЛОЖЕНИЕ 8 — ОТЧЕТ О РЕЗУЛЬТАТАХ ЭТАПА.

Пример 3. УСТАВ ПРОЕКТА (Российская компания — системный интегратор)

СОДЕРЖАНИЕ
1. ПРОФИЛЬ КОМПАНИИ
1.1. СФЕРА ДЕЯТЕЛЬНОСТИ
1.2. АДРЕС КОМПАНИИ
1.3. КОНТАКТНЫЕ ЛИЦА
1.4. СОТРУДНИКИ
2. ЦЕЛИ И ОПРЕДЕЛЕНИЕ ПРОЕКТА
3. ПЛАН ПРОЕКТА
4. СТРУКТУРА ПРОЕКТА
4.1. ОРГАНИЗАЦИОННАЯ СТРУКТУРА ПРОЕКТА
4.2. КЛЮЧЕВЫЕ РОЛИ И ОТВЕТСТВЕННОСТЬ
4.3. ПРОЦЕДУРЫ ВСТРЕЧ И ПОДГОТОВКИ ОТЧЕТОВ О СОСТОЯНИИ ПРОЕКТА
5. РИСКИ ПРОЕКТА
6. ПЛАН ОБУЧЕНИЯ ПОЛЬЗОВАТЕЛЕЙ
7. КОНТРОЛЬ ИЗМЕНЕНИЙ И ПРОЦЕДУРЫ ПРИЁМКИ РАБОТ
7.1. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ
7.2. ПРОЦЕДУРЫ ТЕСТИРОВАНИЯ И ПРИЕМКИ РАБОТ
7.3. СТАТУС И СОСТАВ ПРИЕМОЧНОЙ КОМИССИИ
7.4. ПЕРЕДАЧА В ОПЫТНУЮ ЭКСПЛУАТАЦИЮ
8. ЛИСТ СОГЛАСОВАНИЙ
ПРИЛОЖЕНИЯ