1. Павел Алферов. Сотрудник автономной некоммерческой организации
БУДУЩЕЕ ПРОЕКТНОЙ МЕТОДОЛОГИИ:
ОТ КЛАССИФИКАЦИИ К ПРОФИЛЯМ
Введение
Проектирование стула и океанского лайнера
различается только параметрами, но не методологией
немецкий архитектор и теоретик архитектуры
Вальтер Гропиус
В конце 90-х, когда проектное управление только начало свое робкое шествие по России у
многих участников этого процесса было наивное ощущение найденного «Священного Грааля» -
появился набор инструментов, шагов и ролей, следуя которому можно гарантированно получить
необходимый результат. И правда – на Западе же получается…
Потом был длительный и сложный путь к пониманию того, что Управление проектами на
текущий момент хотя и является зрелой профессиональной сферой, но все-таки пока еще далеко
от науки. Что фактически управление проектами на текущий момент это набор наблюдений,
лучших практик, применение которых, как было кем-то и когда-то замечено, дает положительный
эффект. И что, соответственно, подавляющее большинство существующих стандартов не являются
«истиной в последней инстанции»: это именно сборники идей в помощь проектному менеджеру,
«ящик с инструментами», из которого менеджер должен сам подобрать инструменты,
подходящие для его конкретного проекта. Наиболее юридически точно эта мысль выражена в
американском стандарте PMBOK (выделение автора):
Основной целью Руководства PMBOK является выделение той части Свода
знаний по управлению проектами, которая обычно считается хорошей практикой.
Термин "выделение" предполагает подготовку обобщенного обзора, а не
исчерпывающего описания. "Обычно считается" означает, что описываемые знания и
практики применимы к большинству проектов в большую часть времени, причем
относительно их значения и пользы в целом существует консенсус. "Хорошая
практика" означает, что в целом существует согласие относительно того, что
правильное применение этих навыков, инструментов и методов способно повысить
вероятность успеха для широкого диапазона различных проектов. Хорошая практика
не означает, что описываемые знания должны всегда одинаковым образом
применяться во всех проектах; возможность их применения для каждого
конкретного проекта определяется командой управления проектом.
Это горькое понимание отразилось в используемых корпоративных проектных
методологиях. Как известно сотрудники российских предприятий весьма скептически относятся к
любым задачам, не являющимся обязательными для исполнения под угрозой расстрела или, на
худой конец, выговора со строгим занесением. Иными словами: в большинстве случаев все, что

2. можно проигнорировать, будет проигнорировано вне зависимости от общетеоретической и
абстрактно-практической полезности предложенного.
Соответственно корпоративная методология российского предприятия не может
составлять собой набор общих рекомендаций, оставляющих подбор проектного инструментария
исключительно на ответственность проектной команды. Если это сделать, то, скорее всего, в
«большинстве проектов большую часть времени» проектная команда будет использовать только
абсолютный минимум, а может, и его не будут использовать. Причем это не будет решением
только проектного менеджера, на него будет оказывать воздействие все окружение: заказчик
проекта, команда и прочие выступающие под лозунгом «Долой бюрократию! Даешь работу!».
Так что национальные традиции требуют, чтобы методология была формальна, конкретна
и легко проверяема. Исходя из этого подхода самые первые появившиеся методологии этапа
«Первоначального накопления проектного капитала» содержали в себе универсальные
определения проекта, ролей в проекте, этапов и прочего необходимого. Все было прописано
достаточно однозначно и не допускало двояких толкований. Также предполагалось, что к не
соблюдающим методологию будут применяться небесные кары и эскалация на руководство.
Уже первые 1-2 года применения такого подхода показывали, что «теория суха мой друг, а
древо жизни зеленеетi». Конечно, внедрение любой формализованной методологии стандартно
встречает сопротивления проектных менеджеров и других участников проекта. Их позицию
можно обобщить крылатой фразой «Вам шашешчки или ехать?», в смысле «Вам чтобы я проект
делал или чтобы дурацкие планы/документы/<подставить по вкусу> заполнял?». Дружеские
беседы и прямые указания руководства обычно позволяют справиться с этой проблемой 1. Но
часто оказывается, что и на самом деле жизнь богаче, и включенные в методологию элементы
смотрятся глупо и не адекватно.
Например, требование вести и еженедельно обновлять бюджет проекта для проекта без
бюджета вообще-то слабо применимо2. Или необходимость создавать Управляющий комитет на
проект, который делается силами одного подразделения и не предполагает вовлечения других
тоже не особенно полезно. Конечно, в каждом конкретном случае это решалось, но это
подрывало саму идею методологии как универсального стандарта для всех проектов.
Справедливости ради необходимо отметить, что с этой же проблемой столкнулись и на
Западе, см. например статью Аарона Шенара «Один размер не подходит для всех проектов»ii.
Естественным ответом на эту ситуацию стало появления проектных классификаций –
подходов разделяющих проекты на группы, и адаптация базовой методологии к каждой из них.
Таким образом, к каждой группе применяются свои кастомизированные требования и правила.
Этот подход является на текущий момент основным для подавляющего количества организаций. В
2005 году PMI даже выпустил отдельные рекомендации по данному вопросу iii. Тема
классификации и типологии проектов активно развивается, отдельные исследователи достигли
очень интересных результатовiv. Автономная некоммерческая организация (АНО), в которой я на
настоящий момент работаю (название из политкорректности опущено), вначале пошла по тому же
пути.
1
Правда только в том случае, если само руководство не разделяло подход «Копать! Не думать! Быстрее
копать!», что в российской практике встречается к сожалению достаточно часто
2
Да, да, как отлично знают все бухгалтеры, ни одной деловой активности, на самом деле, без финансовой
составляющей не бывает. И тем не менее.

3. Стандартный подход
Все счастливые семьи счастливы одинаково,
а каждая несчастная семья несчастна по-своему
Л.Н.Толстой
Внедрение проектного управления в АНО было проведено мощно, масштабно по всем
правилам (с созданием соответствующих организационных подразделений, массовыми
тренингами, разработкой нормативных документов и последующим внедрением
специализированной информационной системы, настроенной на подготовленные и внедренные
процессы). Внедрение активно поддерживалось на уровне высшего руководства. Все это в общем
называлось внедрением проектно-ориентированной организации.
Уже на начальном этапе внедрения проектного управления в нашей организации был
подготовлен документ «Временное Положения по проектной деятельности».
Согласно данному документу все проекты классифицировались по (см.рисунок) :
– Масштабу
• Комплексные
• Средние
• Малые
– Организационному охвату
• Функциональные
• Кросс-функциональные
• Общие проекты Организации
По «Крупным» проектам была определена достаточно «тяжелая» методология:
обязательные этапы, необходимые роли, детальные шаблоны документов. По «малым» проектам
были прописаны всего два обязательных документа и две роли. Для «средних» проектов
специальных требований закреплено не было – к ним относились те же требования, что и к
«малым» + рекомендовалось отобрать из арсенала «крупных» то, что необходимо.
К «мероприятиям» (фактически мини-проектам, выполняемым 1-2 сотрудниками) никаких
требований не предъявлялось. Только были поставлены ограничения, что мероприятия не могут
длиться больше 3-х месяцев, содержать бюджет более 1 млн.рублей и иметь трудоемкость выше
3-х человеко-месяцев.

4. К сожалению, необходимо отметить, что этот подход в нашей реальности не сработал.
Подавляющее большинство проектов незаметно мигрировали в «средние», т.е. «никакие» с точки
зрения управления. Никаких дополнительных инструментов управления проектами проектные
команды предпочитали не использовать.
Проведенный анализ показал, что можно выделить четыре основные причины этой ситуации.
 Слишком разные подразделения. В штате организации выделено более
полусотни подразделений, которые занимаются очень разными вопросами,
начиная от контроля строительства объектов и до подготовки волонтеров и
проведения культурных мероприятий.
 Слишком разный опыт Лидеров3 и менеджеров проектов. В организации
работают как сотрудники с профессиональными сертификатами (PMI®, IPMA®,
PME®), так и люди, только что прошедшие здесь же свое первое обучение
проектному управлению и еще до конца не уверенные, что все эти прекрасные
рассказы имеют отношение к реальной жизни.
 Слишком много задач. Многие проекты были недостаточно обеспечены
ресурсами, соответственно руководители проектов пытались максимально
уменьшить «непроизводительную» с их точки зрения работу.
 Слишком сложно осуществлять контроль. Большое количество проектов и
небольшое количество имеющихся в центральном PMO4 ресурсов не давало
возможности наладить глубокую систему контроля.
В результате при очередном обновлении методологии был применен альтернативный
подход – адаптивная методология, «самоподстраивающаяся» предполагающая зависимость
отдельных элементов применяемой к проекту методологии от конкретных параметров самого
проекта.
Профили и конфигуратор
Поздно вечером приятели начали переговоры с Конфигуратором. Арнольд настойчиво
нашептывал ему о прелестях повторения. Грегор громко рассуждал об эстетическом
наслаждении от многократного производства таких шедевров, как элементы системы
управления. Арнольд все шептал о трепете от бесконечного производства одних и тех же
предметов. Снова и снова — все те же детали, все из того же материала, производимые с
одной и той же скоростью. Экстаз! Грегор философствовал, сколь гармонично это
соответствует облику и способностям Конфигуратора. Он говорил, что повторение гораздо
ближе к энтропии, которая с механической точки зрения само совершенство.
Роберт Шекли. «Необходимая вещь»
Подход построен на нескольких основных предположениях.
3
Ответственных за проект от подразделения. Осуществляет общее оперативное управление проектом.
Несет ответственность за проект в целом и за соответствие результатов проекта требованиям организации.
Может делегировать часть своих задач менеджеру проекта, но не может делегировать ответственность за
проект.
4
PMO – project management office/Центральный проектный офис

5. 1. Управление проектом может быть построено на использовании определенных
инструментов проектного управления (элементов), которые можно скомпоновать в 5
основных групп:
 этапы жизненного цикла проекта;
 организационная структура/проектные роли;
 документы;
 ключевые встречи и совещания;
 контрольные точки.
2. Основных элементов, необходимых в реальной жизни не так много – порядка 50-60.
Они составляют общий профиль управления проектом в организации.
3. Для каждого конкретного проекта их гораздо меньше – порядка двух десятков
элементов. Их совокупность для конкретного проекта, составляет Профиль управления
данным проектом. Таким образом, Профиль задает набор и требования к элементам
управления, которые должны быть использованы при управлении конкретным
рассматриваемым проектом.
4. Отбор элементов для профиля проектов осуществляется на основе нескольких
ключевых параметров проекта и его окружения (длительности проекта, бюджет,
организационная сложность, количество вовлеченных подразделений и т.д.). Именно
эти параметры определяют важность и полезность элементов для конкретного проекта
(например, наличие в проекте представителей из более чем 3-х различных
подразделений означает обязательное создание матрицы распределения
ответственности, наличие нескольких подрядчиков – необходимость интеграционных
встреч и т.д.).
5. Оценку полезности в зависимости от параметров можно провести с помощью
экспертов заранее и зафиксировать в некоторой матрице, где будет указано, что
наличие такого-то параметра приводит к необходимости (или наоборот– не нужности
или рекомендуемости) некоторого элемента управления проектом (мы назвали его
«Конфигуратором»).
Таким образом, мы создали «Конфигуратор» – инструмент на основе MS Excel®, позволяющий на
основании оценки проекта по критериям классификации получить профиль управления
проектом, содержащий как обязательные, так и рекомендуемые элементы управления проектом.
А в общем процесс разработки и использования адаптивной методологии выглядит следующим
образом:
При разработке и внедрении методологии в организации
Определяется Определяются Настраивается
"максимальный" возможные матрица связей
профиль наиболее параметров и
управления критичные элементов
проектом параметры проекта ("Конфигуратор")
При запуске отдельного проекта

6. Обсуждение
Утверждение
рекомендаций Принятие/оклонение
финального профиля
Заполнение значений полученного в рекомендаций и
вместе с запросом на
параметров результате работы формирование
проекта на Проектном
"Конфигуратора" финального профиля
Комитете
профиля
Существует общий «максимальный профиль», включающий все элементы
Проект планируется Проект завершается Проект завершен
Проект утвержден
Терминология
Прорабатывается идея проекта Проект инициирован/ выполняется
1 месяц
Отчет для ПК
Регулярная отчетность по Отчет о статусе проекта
2 недели или чаще
проекту
1 неделя
Отчет членов команды
проекта
Реестр вопросов и поручений 1 неделя
Реестр рисков и проблем
(Матрица рисков)
1 месяц или чаще
План персонала проекта
2 недели или чаще
Календарный план проекта
Рабочие документы
1 месяц или чаще
е
проекта
кт
Финансовый план проекта
ое
пр
ео
Реестр изменений проекта
ни
ле
ом
Матрица ответственности
ед
Ув
по
по
по
м
ы
ле
ы
ы
кт
кт
кт
те
на
по
еа
еа
еа
ни
в
т
ы
м ны
м ны
че
то
ол
ы
кт
м н
от
ен
р а оч
сп
ра оч
ра оч
м а
у ум
й
си
ра е
во ут
во ут
во ут
во ны
ны
пк ок
го еж
го е ж
го еж
р
го ль
оч
ку д
во
до ром
до ом
до ром
за акет
ен
до ина
го
Пр
П
Оц
До
П
Документы
Ф
П
контрактования
ов
атт
ль
ов
зу
ат
я
по
ре
т
ни
а
ль
кт
т
и
а
че
зу
рж
мк
ое
т о ки
от
ре
кт
пр
та е м
ие
де
ое
кт й
кт ие
в
пр
со
ль и
т
о е вы
пр
ор
зу пр
Запрос на изменение
ое ан
ы
кт ие
пр того
сп
на
пр пис
ре лан
а
у
ол
ое ан
Официальные документы
Па
ос
ок
пр пис
а
О
П
И
пр
от
О
Пр
За
проекта
Фазы жизненного
цикла
Предпроектный этап Оценка Выбор Определение Выполнение Завершение Постпроектный этап
Ключевые вехи
проекта Проект Проект утвержден Результаты
Выбран оптимальный вариант Все планы разработаны и Проект закрыт
инициирован на ПК проекта приняты
(стратегия) реализации проекта акцептованы
Совещание по запуску Конкурсная Стартовое совещание с ПК блока/ УК Комиссия по приемке
ПК блока ПК ОКОИ ПК ОКОИ
проекта (Kick-off) комиссия подрядчиками проекта результатов
1 неделя
Ключевые Встречи команды проекта
совещания
Заседания УК проекта 2 месяца или чаще
1 месяц или чаще
Интеграционные встречи
Встречи группы 2 недели или чаще
управления проектом
 Стартовать проработку проекта  Провести предварительную  Уточнить границы и содержание  Оформить и заключить контракт  Выполнить работы согласно плану  Закрыть все договора по  Отследить и оценить выгоды,
 Идентифицировать Владельца, проработку проекта по всем проекта, требования к результатам с поставщиками (если  Контролировать статус и отклонения проекта проекту (если применимо) полученные по результатам
Лидера, Менеджера проекта аспектам (цели, сроки, финансы,  Провести анализ вариантов применимо)  Получить и принять результаты проекта  Передать результаты проекта проекта
 Идентифицировать основных участники) реализации проекта  Провести детальное  Подписать промежуточные акты по проекту заинтересованным сторонам
Ключевые задачи заинтересованных лиц  Оценить выгоды и  Подготовить и провести конкурс по планирование всех аспектов (если применимо)  Подготовить финальный отчет
 Согласовать проект внутри блока целесообразность проекта выбору поставщиков (если проекта по проекту
фазы
 Известить о старте проекта  Согласовать проект с центральным применимо)  Оформить и утвердить Паспорт  Расформировать команду
центральный PMO PMO, блоком финансов, проекта проекта
владельцами ресурсов  Окончательно сформировать
 Утвердить проект на ПК команду проекта
 Делал ли кто-нибудь что-то подобное  Кто и что будет влиять на  Что можно взять из других  Все ли заинтересованные лица  Известили ли нас про изменения в смежных  Извещены ли смежные
Ключевые вопросы до нас? проект? активностей? определены? активностях? активности о завершении
интеграции  На кого и что будет влиять  Можно ли консолидировать  Все связанные активности  Извещены ли смежные активности о наших проекта?
проект? закупки? идентифицированы? изменениях?  Предоставлены ли смежным
 Все работы и точки по  Предоставлены ли смежным активностям активностям ожидаемые ими
интеграции запланированы? ожидаемые ими промежуточные результаты? окончательные результаты?
Условные обозначения: периодичность - периодичность для всех проектов, вне
- совещания уровня ОКОИ
- документы, обязательные для всех проектов (в зависимости от профиля
базовом варианте) периодичность
- обязательные совещания уровня проекта - периодичность зависит профиля
- документы, обязательные для всех проектов (в
базовом или детальном варианте) - документы, обязательные для проектов, в которых
- совещания уровня проекта, которые участвует внешний исполнитель
- документы, которые могут быть обязательны в обязательны в зависимости от профиля проекта
зависимости от профиля проекта (в базовом или
детальном варианте) - ключевые вехи проекта
Как выглядят параметры (каждому параметру соответствует «закрытый» список значений, что
сильно облегчает выбор)

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

8. Профиль проекта Показания к Изменить Профиль проекта с учетом
Подробнее об профилю профиль проекта внесенных изменений
Элемент управления проектом Требования и рекомендации к элементу управления
элементе
Жизненный цикл проекта
Предпроектный этап подробнее обязательный смотреть принять сделать обязательным
Этап "Оценка" подробнее обязательный смотреть принять сделать обязательным
Этап "Выбор" подробнее рекомендуемый смотреть принять сделать обязательным
Этап "Определение" подробнее рекомендуемый смотреть принять сделать обязательным
Этап "Выполнение" подробнее обязательный смотреть принять сделать обязательным
Этап "Завершение" подробнее обязательный смотреть принять сделать обязательным
Постпроектный этап (мониторинг) подробнее рекомендуемый смотреть принять сделать обязательным
Организационная структура и роли
Стратегическое управление
Управляющий комитет проекта подробнее рекомендуемый смотреть принять сделать обязательным
Владелец проекта подробнее обязательный смотреть принять сделать обязательным
Оперативное управление (группа управления проектом)
Лидер проекта подробнее обязательный смотреть принять сделать обязательным
Со-Лидер проекта подробнее обязательный смотреть принять сделать обязательным
Руководитель проекта подробнее рекомендуемый смотреть принять сделать обязательным
Администратор проекта подробнее рекомендуемый смотреть принять сделать обязательным
Риск-менеджер подробнее рекомендуемый смотреть принять сделать обязательным
Рабочая группа
Член проектной команды/рабочей группы подробнее обязательный смотреть принять сделать обязательным
Рабочая группа по направлению и ее
руководитель подробнее необязательный смотреть принять сделать необязательным
Контроль и приемка
Группа по приемке и ее руководитель подробнее необязательный смотреть принять сделать необязательным
Группа по интеграции и ее руководитель подробнее рекомендуемый смотреть принять сделать обязательным
Внешний исполнитель
Куратор проекта от Исполнителя подробнее необязательный смотреть принять сделать необязательным
Руководитель проекта от Исполнителя подробнее необязательный смотреть принять сделать необязательным
Член проектной команды от Исполнителя подробнее необязательный смотреть принять сделать необязательным
Профильные роли
Эксперт в предметной области подробнее рекомендуемый смотреть принять сделать обязательным
Представитель ФНД подробнее необязательный смотреть принять сделать необязательным
Ключевой пользователь подробнее необязательный смотреть принять сделать необязательным
Функциональный руководитель - владелец
ресурса подробнее обязательный смотреть принять сделать обязательным
Обязательные документы
Официальные документы
Запрос на проект подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Паспорт проекта подробнее детальный вариант документа смотреть принять детальный вариант документа
Итоговый отчет по проекту подробнее базовый вариант документа смотреть принять базовый вариант документа
Матрица ответственности подробнее стандартный вариант документа смотреть принять стандартный вариант документа
План приемки результатов подробнее базовый вариант документа смотреть отклонить сделать необязательным
Описание содержания (ТЗ) подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Запрос на изменение подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Описание результатов проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Протокол приемки результатов подробнее стандартный вариант документа отклонить сделать необязательным
Оперативные документы
Уведомление о проекте подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Отчет для ПК подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Отчет о статусе проекта подробнее базовый вариант документа смотреть принять базовый вариант документа
Рабочий календарный план проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Рабочий финансовый план проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Реестр рисков и проблем проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Реестр вопросов и поручений проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа
Реестр изменений проекта подробнее стандартный вариант документа смотреть принять стандартный вариант документа
План персонала проекта подробнее необязательный смотреть принять сделать необязательным
Отчет членов команды проекта подробнее рекомендуемый смотреть принять стандартный вариант документа
Документы контрактования
Пакет документов на закупку подробнее необязательный смотреть принять сделать необязательным
Оценочный отчет подробнее необязательный смотреть принять сделать необязательным
Акты подробнее необязательный принять сделать необязательным
Встречи и совещания
Совещание по запуску проекта (Kick-off) подробнее рекомендуемо проведение смотреть принять сделать обязательным
Встречи команды проекта подробнее рекомендуемо проведение смотреть отклонить сделать необязательным
Встречи группы управления проектом подробнее рекомендуемо проведение принять сделать обязательным
Интеграционные встречи (на всех этапах на начиная
с предпроектного этапа) подробнее проведение необязательно смотреть принять сделать необязательным
Периодичность
(1 -еженедельно, 2 - два раза в неделю, 3 - три раза в неделю, 4 - ежемесячно, 8 -раз в два месяца)
Периодичность предоставления/обновления документов
Рабочий календарный план проекта 1 смотреть принять 1
Рабочий финансовый план проекта 2 смотреть принять 2
План персонала проекта 0 смотреть принять 0
Реестр вопросов и поручений 1 смотреть принять 1
Отчет членов команды проекта 0 смотреть принять 0
Отчет о статусе проекта 2 смотреть принять 2
Отчет для ПК 4 смотреть принять 4
Периодичность проведения совещаний и встреч
Встречи команды проекта 0 смотреть принять 0
Встречи группы управления проектом 2 принять 2
Заседания Управляющего комитета 4 смотреть принять 4
Интеграционные встречи (на всех этапах на начиная с
предпроектного этапа) 0 смотреть принять 0
«Как это работает». Внутренности конфигуратора (главная настроечная таблица, «матрица
связанности»). По вертикали перечислены сгруппированные элементы управления, по