будущее проектной методологии

Павел Алферов. Сотрудник автономной некоммерческой организации

БУДУЩЕЕ ПРОЕКТНОЙ МЕТОДОЛОГИИ:

ОТ КЛАССИФИКАЦИИ К ПРОФИЛЯМ

Введение Проектирование стула и океанского лайнера

различается только параметрами, но не методологией

немецкий архитектор и теоретик архитектуры

Вальтер Гропиус

В конце 90-х, когда проектное управление только начало свое робкое шествие по России у

многих участников этого процесса было наивное ощущение найденного «Священного Грааля» -

появился набор инструментов, шагов и ролей, следуя которому можно гарантированно получить

необходимый результат. И правда – на Западе же получается…

Потом был длительный и сложный путь к пониманию того, что Управление проектами на

текущий момент хотя и является зрелой профессиональной сферой, но все-таки пока еще далеко

от науки. Что фактически управление проектами на текущий момент это набор наблюдений,

лучших практик, применение которых, как было кем-то и когда-то замечено, дает положительный

эффект. И что, соответственно, подавляющее большинство существующих стандартов не являются

«истиной в последней инстанции»: это именно сборники идей в помощь проектному менеджеру,

«ящик с инструментами», из которого менеджер должен сам подобрать инструменты,

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

американском стандарте PMBOK (выделение автора):

Основной целью Руководства PMBOK является выделение той части Свода

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

Термин "выделение" предполагает подготовку обобщенного обзора, а не

исчерпывающего описания. "Обычно считается" означает, что описываемые знания и

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

относительно их значения и пользы в целом существует консенсус. "Хорошая

практика" означает, что в целом существует согласие относительно того, что

правильное применение этих навыков, инструментов и методов способно повысить

вероятность успеха для широкого диапазона различных проектов. Хорошая практика

не означает, что описываемые знания должны всегда одинаковым образом

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

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

Это горькое понимание отразилось в используемых корпоративных проектных

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

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

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

можно проигнорировать, будет проигнорировано вне зависимости от общетеоретической и

абстрактно-практической полезности предложенного.

Соответственно корпоративная методология российского предприятия не может

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

исключительно на ответственность проектной команды. Если это сделать, то, скорее всего, в

«большинстве проектов большую часть времени» проектная команда будет использовать только

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

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

проекта, команда и прочие выступающие под лозунгом «Долой бюрократию! Даешь работу!».

Так что национальные традиции требуют, чтобы методология была формальна, конкретна

и легко проверяема. Исходя из этого подхода самые первые появившиеся методологии этапа

«Первоначального накопления проектного капитала» содержали в себе универсальные

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

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

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

Уже первые 1-2 года применения такого подхода показывали, что «теория суха мой друг, а

древо жизни зеленеетi». Конечно, внедрение любой формализованной методологии стандартно

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

можно обобщить крылатой фразой «Вам шашешчки или ехать?», в смысле «Вам чтобы я проект

делал или чтобы дурацкие планы/документы/<подставить по вкусу> заполнял?». Дружеские

беседы и прямые указания руководства обычно позволяют справиться с этой проблемой1. Но

часто оказывается, что и на самом деле жизнь богаче, и включенные в методологию элементы

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

Например, требование вести и еженедельно обновлять бюджет проекта для проекта без

бюджета вообще-то слабо применимо2. Или необходимость создавать Управляющий комитет на

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

тоже не особенно полезно. Конечно, в каждом конкретном случае это решалось, но это

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

Справедливости ради необходимо отметить, что с этой же проблемой столкнулись и на

Западе, см. например статью Аарона Шенара «Один размер не подходит для всех проектов»ii.

Естественным ответом на эту ситуацию стало появления проектных классификаций –

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

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

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

2005 году PMI даже выпустил отдельные рекомендации по данному вопросуiii. Тема

классификации и типологии проектов активно развивается, отдельные исследователи достигли

очень интересных результатовiv. Автономная некоммерческая организация (АНО), в которой я на

настоящий момент работаю (название из политкорректности опущено), вначале пошла по тому же

пути.

1 Правда только в том случае, если само руководство не разделяло подход «Копать! Не думать! Быстрее копать!», что в российской практике встречается к сожалению достаточно часто 2 Да, да, как отлично знают все бухгалтеры, ни одной деловой активности, на самом деле, без финансовой составляющей не бывает. И тем не менее.

Стандартный подход Все счастливые семьи счастливы одинаково,

а каждая несчастная семья несчастна по-своему

Л.Н.Толстой

Внедрение проектного управления в АНО было проведено мощно, масштабно по всем

правилам (с созданием соответствующих организационных подразделений, массовыми

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

специализированной информационной системы, настроенной на подготовленные и внедренные

процессы). Внедрение активно поддерживалось на уровне высшего руководства. Все это в общем

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

Уже на начальном этапе внедрения проектного управления в нашей организации был

подготовлен документ «Временное Положения по проектной деятельности».

Согласно данному документу все проекты классифицировались по (см.рисунок) :

– Масштабу

• Комплексные

• Средние

• Малые

– Организационному охвату

• Функциональные

• Кросс-функциональные

• Общие проекты Организации

По «Крупным» проектам была определена достаточно «тяжелая» методология:

обязательные этапы, необходимые роли, детальные шаблоны документов. По «малым» проектам

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

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

«малым» + рекомендовалось отобрать из арсенала «крупных» то, что необходимо.

К «мероприятиям» (фактически мини-проектам, выполняемым 1-2 сотрудниками) никаких

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

длиться больше 3-х месяцев, содержать бюджет более 1 млн.рублей и иметь трудоемкость выше

3-х человеко-месяцев.

К сожалению, необходимо отметить, что этот подход в нашей реальности не сработал.

Подавляющее большинство проектов незаметно мигрировали в «средние», т.е. «никакие» с точки

зрения управления. Никаких дополнительных инструментов управления проектами проектные

команды предпочитали не использовать.

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

Слишком разные подразделения. В штате организации выделено более

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

начиная от контроля строительства объектов и до подготовки волонтеров и

проведения культурных мероприятий.

Слишком разный опыт Лидеров3 и менеджеров проектов. В организации

работают как сотрудники с профессиональными сертификатами (PMI®, IPMA®,

PME®), так и люди, только что прошедшие здесь же свое первое обучение

проектному управлению и еще до конца не уверенные, что все эти прекрасные

рассказы имеют отношение к реальной жизни.

Слишком много задач. Многие проекты были недостаточно обеспечены

ресурсами, соответственно руководители проектов пытались максимально

уменьшить «непроизводительную» с их точки зрения работу.

Слишком сложно осуществлять контроль. Большое количество проектов и

небольшое количество имеющихся в центральном PMO4 ресурсов не давало

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

В результате при очередном обновлении методологии был применен альтернативный

подход – адаптивная методология, «самоподстраивающаяся» предполагающая зависимость

отдельных элементов применяемой к проекту методологии от конкретных параметров самого

проекта.

Профили и конфигуратор

Поздно вечером приятели начали переговоры с Конфигуратором. Арнольд настойчиво

нашептывал ему о прелестях повторения. Грегор громко рассуждал об эстетическом

наслаждении от многократного производства таких шедевров, как элементы системы

управления. Арнольд все шептал о трепете от бесконечного производства одних и тех же

предметов. Снова и снова — все те же детали, все из того же материала, производимые с

одной и той же скоростью. Экстаз! Грегор философствовал, сколь гармонично это

соответствует облику и способностям Конфигуратора. Он говорил, что повторение гораздо

ближе к энтропии, которая с механической точки зрения само совершенство.

Роберт Шекли. «Необходимая вещь»

Подход построен на нескольких основных предположениях.

3 Ответственных за проект от подразделения. Осуществляет общее оперативное управление проектом.

Несет ответственность за проект в целом и за соответствие результатов проекта требованиям организации. Может делегировать часть своих задач менеджеру проекта, но не может делегировать ответственность за проект. 4 PMO – project management office/Центральный проектный офис

1. Управление проектом может быть построено на использовании определенных

инструментов проектного управления (элементов), которые можно скомпоновать в 5

основных групп:

этапы жизненного цикла проекта;

организационная структура/проектные роли;

документы;

ключевые встречи и совещания;

контрольные точки.

2. Основных элементов, необходимых в реальной жизни не так много – порядка 50-60.

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

3. Для каждого конкретного проекта их гораздо меньше – порядка двух десятков

элементов. Их совокупность для конкретного проекта, составляет Профиль управления

данным проектом. Таким образом, Профиль задает набор и требования к элементам

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

рассматриваемым проектом.

4. Отбор элементов для профиля проектов осуществляется на основе нескольких

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

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

эти параметры определяют важность и полезность элементов для конкретного проекта

(например, наличие в проекте представителей из более чем 3-х различных

подразделений означает обязательное создание матрицы распределения

ответственности, наличие нескольких подрядчиков – необходимость интеграционных

встреч и т.д.).

5. Оценку полезности в зависимости от параметров можно провести с помощью

экспертов заранее и зафиксировать в некоторой матрице, где будет указано, что

наличие такого-то параметра приводит к необходимости (или наоборот– не нужности

или рекомендуемости) некоторого элемента управления проектом (мы назвали его

«Конфигуратором»).

Таким образом, мы создали «Конфигуратор» – инструмент на основе MS Excel®, позволяющий на

основании оценки проекта по критериям классификации получить профиль управления

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

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

образом:

При разработке и внедрении методологии в организации

При запуске отдельного проекта

Определяется "максимальный"

профиль управления проектом

Определяются возможные

наиболее критичные

параметры проекта

Настраивается матрица связей параметров и

элементов ("Конфигуратор")

Существует общий «максимальный профиль», включающий все элементы

Условные обозначения:

Уведомление о проекте

Уточнить границы и содержание

проекта, требования к результатам

Провести анализ вариантов

реализации проекта

Подготовить и провести конкурс по

выбору поставщиков (если

применимо)

Стартовать проработку проекта

Идентифицировать Владельца,

Лидера, Менеджера проекта

Идентифицировать основных

заинтересованных лиц

Согласовать проект внутри блока

Известить о старте проекта

центральный PMO

Провести предварительную

проработку проекта по всем

аспектам (цели, сроки, финансы,

участники)

Оценить выгоды и

целесообразность проекта

Согласовать проект с центральным

PMO, блоком финансов,

владельцами ресурсов

Утвердить проект на ПК

Оформить и заключить контракт

с поставщиками (если

применимо)

Провести детальное

планирование всех аспектов

проекта

Оформить и утвердить Паспорт

проекта

Окончательно сформировать

команду проекта

Выбран оптимальный вариант

(стратегия) реализации проекта

ВыборОценка ЗавершениеВыполнение Предпроектный этап

Официальные документы

проекта

Фазы жизненного

цикла

Ключевые вехи

проекта

Ключевые задачи

фазы

Результаты

проекта приняты

Ключевые

совещания

Определение Постпроектный этап

Проект закрытВсе планы разработаны и

акцептованы

Проект утвержден

на ПК

Проект

инициирован

ПК ОКОИПК блокаКонкурсная

комиссия

ПК блока/ УК

проектаПК ОКОИ

- документы, обязательные для всех проектов (в

базовом варианте)

- документы, которые могут быть обязательны в

зависимости от профиля проекта (в базовом или

детальном варианте)

- совещания уровня ОКОИ

- обязательные совещания уровня проекта

Запрос

на проект

Рабочие документы

проекта

Реестр вопросов и поручений

Календарный план проекта

Финансовый план проекта

Регулярная отчетность по

проекту

Отчет для ПК1 месяц

Отчет о статусе проекта

Итоговый отчет по

проекту

Пакет документов на

закупку

Договор с исполнителем

2 недели или чаще

План

приемки

результатов

Паспорт проекта

Реестр изменений проекта

Комиссия по приемке


Выполнить работы согласно плану

Контролировать статус и отклонения проекта

Получить и принять результаты проекта

Подписать промежуточные акты по проекту

(если применимо)

Закрыть все договора по

проекту (если применимо)

Передать результаты проекта

заинтересованным сторонам

Подготовить финальный отчет

по проекту

Расформировать команду

проекта

Отследить и оценить выгоды,

полученные по результатам

проекта

Финальные акты

по

договорам

Описание


проекта

Ключевые вопросы

интеграции

Делал ли кто-нибудь что-то подобное

до нас? Кто и что будет влиять на

проект?

На кого и что будет влиять

проект?

Все ли заинтересованные лица

определены?

Все связанные активности

идентифицированы?

Все работы и точки по

интеграции запланированы?

Известили ли нас про изменения в смежных

активностях?

Извещены ли смежные активности о наших

изменениях?

Предоставлены ли смежным активностям

ожидаемые ими промежуточные результаты?

Что можно взять из других

активностей?

Можно ли консолидировать

закупки?

Извещены ли смежные

активности о завершении

проекта?

Предоставлены ли смежным

активностям ожидаемые ими

окончательные результаты?

Проект инициирован / выполняется

Проект утвержден

Проект планируется Проект завершается Проект завершен

Терминология

Совещание по запуску

проекта (Kick-off)Стартовое совещание с

подрядчиками

Документы

контрактования

Оценочный отчет

Промежуточные акты

по

договорам

Реестр рисков и проблем

(Матрица рисков)

- ключевые вехи проекта

Прорабатывается идея проекта

- документы, обязательные для всех проектов (в

базовом или детальном варианте)

Запрос на изменение

Описание

содержания

проекта

План персонала проекта

Отчет членов команды

проекта

1 неделя

- совещания уровня проекта, которые

обязательны в зависимости от профиля проекта

Встречи команды проекта

Встречи группы

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


1 месяц или чаще

1 месяц или чаще

1 неделя

1 неделя

Заседания УК проекта 2 месяца или чаще

периодичность - периодичность для всех проектов, вне

зависимости от профиля

периодичность- периодичность зависит профиля

Протоколы

приемки



по

договорам


по

договорам

- документы, обязательные для проектов, в которых

участвует внешний исполнитель

Интеграционные встречи1 месяц или чаще


Матрица ответственности

Как выглядят параметры (каждому параметру соответствует «закрытый» список значений, что

сильно облегчает выбор)

Заполнение значений параметров

Обсуждение рекомендаций полученного в

результате работы "Конфигуратора"

профиля

Принятие/оклонение рекомендаций и формирование

финального профиля

Утверждение финального профиля вместе с запросом на проекта на Проектном

Комитете

Выдаваемый результат – профиль конкретного проекта (показана часть)

Более подробный отчет

«Как это работает». Внутренности конфигуратора (главная настроечная таблица, «матрица

связанности»). По вертикали перечислены сгруппированные элементы управления, по

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

элементеТребования и рекомендации к элементу управления

подробнее обязательный смотреть принять сделать обязательным


подробнее рекомендуемый смотреть принять сделать обязательным





Управляющий комитет проекта подробнее рекомендуемый смотреть принять сделать обязательным

Владелец проекта подробнее обязательный смотреть принять сделать обязательным

Лидер проекта подробнее обязательный смотреть принять сделать обязательным

Со-Лидер проекта подробнее обязательный смотреть принять сделать обязательным

Руководитель проекта подробнее рекомендуемый смотреть принять сделать обязательным

Администратор проекта подробнее рекомендуемый смотреть принять сделать обязательным

Риск-менеджер подробнее рекомендуемый смотреть принять сделать обязательным

Член проектной команды/рабочей группы подробнее обязательный смотреть принять сделать обязательным

Рабочая группа по направлению и ее

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

Группа по приемке и ее руководитель подробнее необязательный смотреть принять сделать необязательным

Группа по интеграции и ее руководитель подробнее рекомендуемый смотреть принять сделать обязательным

Куратор проекта от Исполнителя подробнее необязательный смотреть принять сделать необязательным

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

Член проектной команды от Исполнителя подробнее необязательный смотреть принять сделать необязательным

Эксперт в предметной области подробнее рекомендуемый смотреть принять сделать обязательным

Представитель ФНД подробнее необязательный смотреть принять сделать необязательным

Ключевой пользователь подробнее необязательный смотреть принять сделать необязательным

Функциональный руководитель - владелец

ресурса подробнее обязательный смотреть принять сделать обязательным

Запрос на проект подробнее стандартный вариант документа смотреть принять стандартный вариант документа

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

Итоговый отчет по проекту подробнее базовый вариант документа смотреть принять базовый вариант документа

Матрица ответственности подробнее стандартный вариант документа смотреть принять стандартный вариант документа

План приемки результатов подробнее базовый вариант документа смотреть отклонить сделать необязательным

Описание содержания (ТЗ) подробнее стандартный вариант документа смотреть принять стандартный вариант документа

Запрос на изменение подробнее стандартный вариант документа смотреть принять стандартный вариант документа

Описание результатов проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа

Протокол приемки результатов подробнее стандартный вариант документа отклонить сделать необязательным

Уведомление о проекте подробнее стандартный вариант документа смотреть принять стандартный вариант документа

Отчет для ПК подробнее стандартный вариант документа смотреть принять стандартный вариант документа

Отчет о статусе проекта подробнее базовый вариант документа смотреть принять базовый вариант документа

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

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

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

Реестр вопросов и поручений проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа

Реестр изменений проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа

План персонала проекта подробнее необязательный смотреть принять сделать необязательным

Отчет членов команды проекта подробнее рекомендуемый смотреть принять стандартный вариант документа

Пакет документов на закупку подробнее необязательный смотреть принять сделать необязательным

Оценочный отчет подробнее необязательный смотреть принять сделать необязательным

Акты подробнее необязательный принять сделать необязательным

подробнее рекомендуемо проведение смотреть принять сделать обязательным

подробнее рекомендуемо проведение смотреть отклонить сделать необязательным

подробнее рекомендуемо проведение принять сделать обязательным

подробнее проведение необязательно смотреть принять сделать необязательным

1 смотреть принять 1








2 принять 2



План персонала проекта

Реестр вопросов и поручений

Профиль проекта

Жизненный цикл проекта


Совещание по запуску проекта (Kick-off)

Интеграционные встречи (на всех этапах на начиная

с предпроектного этапа)

Встречи группы управления проектом

Документы контрактования

Заседания Управляющего комитета

Интеграционные встречи (на всех этапах на начиная с

предпроектного этапа)

Отчет членов команды проекта

Отчет о статусе проекта

Отчет для ПК


Организационная структура и роли

Предпроектный этап

Оперативное управление (группа управления проектом)

Этап "Выбор"

Этап "Определение"

Этап "Выполнение"

Этап "Завершение"

Стратегическое управление

Периодичность проведения совещаний и встреч

Рабочий календарный план проекта

Рабочий финансовый план проекта

Периодичность предоставления/обновления документов

Периодичность (1 -еженедельно, 2 - два раза в неделю, 3 - три раза в неделю, 4 - ежемесячно, 8 -раз в два месяца)

Встречи и совещания

Постпроектный этап (мониторинг)


Обязательные документы

Оперативные документы

Этап "Оценка"

Показания к

профилю

Изменить

профиль проекта

Профиль проекта с учетом

внесенных изменений

Встречи группы управления проектом

Рабочая группа

Внешний исполнитель

Профильные роли

Контроль и приемка

горизонтали параметры. На пересечении проставляется необходимость данного элемента

(обязательный, рекомендуемый, не влияет и т.д.)

Указанный подход был разработан совместно с коллегами из компании PM Expert и

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

по политическим причинам данный эксперимент пришлось свернуть. В настоящий момент в

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

Заключение One size doesn’t fits all!

Сама идея подстраивающейся, динамической методологии не нова. Еще в 1999 году

Алистер Коуберн написал статью «Каждому проекту своя методология»v, в дальнейшем он развил

свои идеи в статье «Каждой методологии - свое время»vi. Необходимо отметить, что фокусом его

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

перенести на другие типы проектов.

В то же время предложенный в статье подход может быть довольно легко перенесен на

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

предметные результаты для проектов внедрения готового ПО одной крупной корпорации

выглядел следующим образом.

Также, аналогичный подход «профилирования» может быть использован при построении

системы контроля проектов (соответственно, появляется «Профиль контроля проекта» и т.д.).

Впрочем, это тема уже для другой статьи.

< 1 млн. руб. от 1 до 10 млн.руб. >10 млн.руб. < 6 мес. от 6 до 12 мес. > 12 мес.

одно рабочая

группа не более 3

PST в рамках

одного Блока

2-3 рабочие

группы из 2-3

Блоков

более 3 рабочих

групп из более чем

2-3 Блоков

нет прямой

зависимости/влиян

ия

влияние/зависимо

сть с 1-2 проектами

зависимость/влиян

ие на 3 и более

проектов/на

ключевые проекты

нет внешних

исполнителей1 исполнитель

несколько

исполнителей

все кроме (MS-O,

GFP, GS-O)/нет

точек

1 точка MS-O, или

GFP, или

commitments

несколько точек

MS-O, GS-OБюджет Качество Срок низкая вероятность

средняя

вероятность

высокая

вероятность

есть опыт

аналогичных

проектов в ОКОИ

есть опыт у

команды

управления

нет опыта низкие средние высокие

никто, результат

проекта

используется

единоразово

Владелец проекта третье лицо

Оценка характеристик проекта (1/пусто), выбирается одно из значений 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Предпроектный этап

Этап "Оценка"

Этап "Выбор" Х Х Х Х Х Х Х Х Х Х Х Х Н О О Х Х Х Х Х Х Х Х Х Н Р О Н Н Р Х Х Х

Этап "Определение" Н Р О Р Р О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Н Р О Н Н Р Х Х Х

Этап "Выполнение"

Этап "Завершение"

Постпроектный этап (мониторинг) Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Н Р Р Х Х Х Х Х Х

Стратегическое управление

Управляющий комитет проекта Н Н Р Х Х Х Н Р О Н Н Р Н Н Р Х Х Х Х Х Х Х Х Х Н Р Р Н Н Р Н Н Р

Владелец проекта

Оперативное управление (группа управления проектом)

Лидер проекта

Со-Лидер

Руководитель проекта Н Р Р Х Х Х Н Р О Х Х Х Н Р О Х Х Х Н Н Р Х Х Х Н Р Р Н Н О Х Х Х

Администратор проекта Н Н Р Х Х Х Н Р Р Х Х Х Н Р Р Х Х Х Н Н Р Х Х Х Н Н Р Н Н Р Х Х Х

Риск-менеджер Н Н Р Х Х Х Н Н Р Н Н Р Н Н Р Х Х Х Н Н Н Н Н Р Н Р Р Н Р О Х Х Х

Рабочая группа

Член проектной команды/рабочей группы

Рабочая группа по направлению и ее руководитель Х Х Х Х Х Х Н Р О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Контроль и приемка

Группа по приемке и ее руководитель Н Н Р Х Х Х Н Н Р Н О О Х Х Х Х Х Х Н Р Н Х Х Х Н Н Р Х Х Х Х Х Х

Группа по интеграции и ее руководитель Н Н Н Х Х Х Н Р О Р Р Р Н Р Р Х Х Х Н Р Н Х Х Х Н Н Р Х Х Х Х Х Х

Внешний исполнитель

Куратор проекта от Исполнителя Н Н О Х Х Х Х Х Х Х Х Х Н Р О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Руководитель проекта от Исполнителя Н Н О Х Х Х Х Х Х Х Х Х Н О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Член проектной команды от Исполнителя Н Н О Х Х Х Х Х Х Х Х Х Н О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Профильные роли

Эксперт в предметной области Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Н Р Н Х Х Х Н Р О Н Н Р Х Х Х

Представитель ФНД Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Ключевой пользователь Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Н Н О

Функциональный руководитель - владелец ресурса


Запрос на проект

Паспорт проекта Н Р Д Р Д Д Н Р Д Н Б Д Н Б Д Н Р Д Х Х Х Х Х Х Н Б Д Н Б Б Х Х Х

Итоговый отчет по проекту Б Б Д Б Б Д Б Б Д Х Х Х Х Х Х Б Б Б Б Б Б Б Б Д Х Б Д Н Б Б Х Х Х

Матрица ответственности Х Х Х Р О О Р О О Р О О Н О О Р О О Р Р Р Р О О Х О О Н О О Х Х Х

План приемки результатов Б Б Б Х Х Х Р Б Д Р Б Д Н Б Д Х Х Х Р Б Р Х Х Х Н Р Б Х Х Х Х Х Х

Описание содержания (ТЗ) О О О О О О О О О О О О О О О О О О О О О О О О О О О О О О О О О

Запрос на изменение

Описание результатов проекта Х Х Х Х Х Х Р Р О Х Х Х Н Р О Х Х Х Р О Р Х Х Х Н О О Х Х Х Н О О

Протокол приемки результатов О О О Х Х Х Р О О Р О О Н О О Х Х Х Р О Р Х Х Х Н Р О Х Х Х Х Х Х

Оперативные документы

Уведомление о проекте

Отчет для ПК

Отчет о статусе проекта Б Б Д Б Б Б Б Б Д Х Х Х Н Б Б Б Б Б Б Б Б Б Б Б Х Б Д Н Б Д Х Х Х

Рабочий календарный план проекта

Рабочий финансовый план проекта Н О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Реестр рисков и проблем проекта Р О О Р О О Р О О Х Х Х Н О О Х Х Х Х Х Х Х Х Х Н О О Н О О Х Х Х

Реестр вопросов и поручений проекта Р О О Р О О Р О О Х Х Х Н О О Х Х Х Х Х Х Х Х Х Н О О Н О О Х Х Х

Реестр изменений проекта О О О О О О О О О О О О О О О О О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

План персонала Х Х Х Х Х Х Н Р О Н Р Р Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Отчет членов команды проекта Х Х Х Х Х Х Р Р Р Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Документы контрактования

Пакет документов на закупку Х Х Х Х Х Х Х Х Х Х Х Х Н О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Оценочный отчет Х Х Х Х Х Х Х Х Х Х Х Х Н О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Акты Х Х Х Х Х Х Х Х Х Х Х Х Н О О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Совещания

Совещание по запуску проекта (Kick-off) Р Р О Р Р Р Р О О Х Х Х Н О О Р Р Р Р Р Р Р Р Р Н Р Р Н Р О Х Х Х

Встречи команды проекта Х Х Х Х Х Х Р Р Р Х Х Х Х Х Х Х Х Х Р Р Р Х Х Х Х Х Х Х Х Х Х Х Х

Встречи группы управления проектом Н Р О Н Р О Р О О Х Х Х Н О О Х Х Х Р Р Р Х Х Х Н Р Р Н Р О Х Х Х

Интеграционные встречи (на всех этапах на начиная с предпроектного этапа) Х Х Х Х Х Х Н О О Н О О Н Р О Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Периодичность предоставления/обновления

Рабочий календарный план проекта Х Х Х 1 2 2 Х Х Х Х Х Х Х Х Х Х 1 1 Х Х 1 Х Х Х Х Х 1 Х Х 1 Х Х Х

Рабочий финансовый план проекта Х Х Х 2 2 4 Х Х Х Х Х Х Х Х Х Х Х Х 2 Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Ресурсный план проекта Х Х Х 2 2 4 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Реестр вопросов и поручений 1 1 1 1 1 1 1 1 1 Х Х Х Х Х Х Х 1 1 Х 1 Х Х Х Х Х Х 1 Х Х 1 Х Х Х

Отчет членов команды проекта Х Х Х Х Х Х Н 1 1 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Отчет о статусе проекта Х Х Х 1 2 2 Х Х Х Х Х Х Х Х Х Х 1 1 Х 2 Х Х Х Х Х Х 1 Х Х 1 Х Х Х

Отчет для ПК 4 4 4 4 4 4 4 4 4 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

Периодичность проведения

Встречи команды проекта Х Х Х 1 2 2 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х 1 Х Х 1 Х Х Х

Встречи группы управления проектом Х Х Х 1 2 2 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х 1 Х Х 1 Х Х Х

Заседания Управляющего комитета Х Х Х 4 4 8 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х 4 Х Х 4 Х Х Х

Интеграционные встречи (на всех этапах на начиная с предпроектного этапа) Х Х Х 2 2 4 Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х Х

ВСЕГДА ИСПОЛНЯЕТСЯ

Кто будет являться ответственным за

использование результатов проекта

Документ обязателен в проекте в стандартном варианте



Риски выполнения проекта

3

ВСЕГДА ОБЯЗАТЕЛЬНА


ВСЕГДА ОБЯЗАТЕЛЬНА (обязательность не определяется кофигуратором профиля управления проектом)






Жизненный цикл проекта

Организационная структура и роли

Обязательные документы

Периодичность



2

Освещение проекта в прессе, политический

аспект

Инновационность проекта

1

Численность внешних исполнителей

(подрядчиков, поставщиков)

Контрольные точки и другие обоснования

проекта (Уровень контроля со стороны

МОК, Правительства, Оргкомитета)

Приоритет внутри проекта

2 1 3Элемент управления проектом\Критерий

Бюджет Длительность Организационная сложность проекта

(количество PST и/или рабочих групп)

Взаимосвязь/зависимость с другими

проектами

3 2 1 3

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

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

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

области управления проектом будут определяться при запуске проекта в зависимости от

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

Внедрение таких методик позволит сделать первый шаг к решению основной проблемы

проектного управления на текущий момент – отсутствия четкого «инженерного» подхода к

осуществлению управления. Основной причиной этого остается сложная, вероятностная связь

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

Использование адаптивных, динамических методик (представляющих своеобразный

компромисс между жесткостью и свободой) особенно актуально для России, где спокон веков

бардак перманентно борется с удушающим порядком. Где с одной стороны никто не любит

лишний формализм («бюрократия» - ругательное слово), а с другой никто не любит лишний раз

«подумать вперед» и просчитать все риски до того, как «клюнет жареный петух». Подход с

использованием профиля проектов может стать хорошим вариантом выхода из этого

исторического тупика.

Автор с удовольствием готов вступить в дискуссию и обменяться мнениями как с противниками,

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

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

[email protected]

i И.Гете «Фауст» ii Aaron J. Shenhar «One Size Does Not Fit All Projects: Exploring Classical Contingency Domains» http://mansci.journal.informs.org/cgi/content/abstract/47/3/394 iiiLynn Crawford, J. Brian Hobbs, J. Rodney Turner «Project Categorization Systems: Aligning Capability With Strategy for Better Results» http://www.amazon.com/Project-Categorization-Systems-Aligning-Capability/dp/1930699387 iv Владимир Ананьин «Стиль ERP-проекта как фактор его успешности» http://www.management.com.ua/ims/ims139.html v Алистэр Коуберн «Каждому проекту своя методология» http://www.maxkir.com/sd/methyperproject_RUS.htm vi Алистэр Коуберн "Каждой методологии - свое время" http://www.maxkir.com/sd/justintimemethodologyconstruction_RUS.html

mailto:[email protected]

http://mansci.journal.informs.org/cgi/content/abstract/47/3/394

http://www.amazon.com/Project-Categorization-Systems-Aligning-Capability/dp/1930699387

http://www.management.com.ua/ims/ims139.html

http://www.maxkir.com/sd/methyperproject_RUS.htm

http://www.maxkir.com/sd/justintimemethodologyconstruction_RUS.html

Documents

будущее проектной методологии