Павел Алферов. Сотрудник автономной некоммерческой организации                  БУДУЩЕЕ ПРОЕКТНОЙ МЕТОДОЛОГИИ:            ...
можно проигнорировать, будет проигнорировано вне зависимости от общетеоретической иабстрактно-практической полезности пред...
Стандартный подход                                                Все счастливые семьи счастливы одинаково,               ...
К сожалению, необходимо отметить, что этот подход в нашей реальности не сработал.Подавляющее большинство проектов незаметн...
1. Управление проектом может быть построено на использовании определенных         инструментов проектного управления (элем...
Обсуждение                                                                                                                ...
Выдаваемый результат – профиль конкретного проекта (показана часть)Более подробный отчет
Профиль проекта                                                                    Показания к      Изменить           Про...
будущее проектной методологии
будущее проектной методологии
будущее проектной методологии
Upcoming SlideShare
Loading in …5
×

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

2,660 views
2,575 views

Published on

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

  1. 1. Павел Алферов. Сотрудник автономной некоммерческой организации БУДУЩЕЕ ПРОЕКТНОЙ МЕТОДОЛОГИИ: ОТ КЛАССИФИКАЦИИ К ПРОФИЛЯМВведение Проектирование стула и океанского лайнера различается только параметрами, но не методологией немецкий архитектор и теоретик архитектуры Вальтер Гропиус В конце 90-х, когда проектное управление только начало свое робкое шествие по России умногих участников этого процесса было наивное ощущение найденного «Священного Грааля» -появился набор инструментов, шагов и ролей, следуя которому можно гарантированно получитьнеобходимый результат. И правда – на Западе же получается… Потом был длительный и сложный путь к пониманию того, что Управление проектами натекущий момент хотя и является зрелой профессиональной сферой, но все-таки пока еще далекоот науки. Что фактически управление проектами на текущий момент это набор наблюдений,лучших практик, применение которых, как было кем-то и когда-то замечено, дает положительныйэффект. И что, соответственно, подавляющее большинство существующих стандартов не являются«истиной в последней инстанции»: это именно сборники идей в помощь проектному менеджеру,«ящик с инструментами», из которого менеджер должен сам подобрать инструменты,подходящие для его конкретного проекта. Наиболее юридически точно эта мысль выражена вамериканском стандарте PMBOK (выделение автора): Основной целью Руководства PMBOK является выделение той части Свода знаний по управлению проектами, которая обычно считается хорошей практикой. Термин "выделение" предполагает подготовку обобщенного обзора, а не исчерпывающего описания. "Обычно считается" означает, что описываемые знания и практики применимы к большинству проектов в большую часть времени, причем относительно их значения и пользы в целом существует консенсус. "Хорошая практика" означает, что в целом существует согласие относительно того, что правильное применение этих навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. Хорошая практика не означает, что описываемые знания должны всегда одинаковым образом применяться во всех проектах; возможность их применения для каждого конкретного проекта определяется командой управления проектом. Это горькое понимание отразилось в используемых корпоративных проектныхметодологиях. Как известно сотрудники российских предприятий весьма скептически относятся клюбым задачам, не являющимся обязательными для исполнения под угрозой расстрела или, нахудой конец, выговора со строгим занесением. Иными словами: в большинстве случаев все, что
  2. 2. можно проигнорировать, будет проигнорировано вне зависимости от общетеоретической иабстрактно-практической полезности предложенного. Соответственно корпоративная методология российского предприятия не можетсоставлять собой набор общих рекомендаций, оставляющих подбор проектного инструментарияисключительно на ответственность проектной команды. Если это сделать, то, скорее всего, в«большинстве проектов большую часть времени» проектная команда будет использовать толькоабсолютный минимум, а может, и его не будут использовать. Причем это не будет решениемтолько проектного менеджера, на него будет оказывать воздействие все окружение: заказчикпроекта, команда и прочие выступающие под лозунгом «Долой бюрократию! Даешь работу!». Так что национальные традиции требуют, чтобы методология была формальна, конкретнаи легко проверяема. Исходя из этого подхода самые первые появившиеся методологии этапа«Первоначального накопления проектного капитала» содержали в себе универсальныеопределения проекта, ролей в проекте, этапов и прочего необходимого. Все было прописанодостаточно однозначно и не допускало двояких толкований. Также предполагалось, что к несоблюдающим методологию будут применяться небесные кары и эскалация на руководство. Уже первые 1-2 года применения такого подхода показывали, что «теория суха мой друг, адрево жизни зеленеетi». Конечно, внедрение любой формализованной методологии стандартновстречает сопротивления проектных менеджеров и других участников проекта. Их позициюможно обобщить крылатой фразой «Вам шашешчки или ехать?», в смысле «Вам чтобы я проектделал или чтобы дурацкие планы/документы/<подставить по вкусу> заполнял?». Дружескиебеседы и прямые указания руководства обычно позволяют справиться с этой проблемой 1. Ночасто оказывается, что и на самом деле жизнь богаче, и включенные в методологию элементысмотрятся глупо и не адекватно. Например, требование вести и еженедельно обновлять бюджет проекта для проекта безбюджета вообще-то слабо применимо2. Или необходимость создавать Управляющий комитет напроект, который делается силами одного подразделения и не предполагает вовлечения другихтоже не особенно полезно. Конечно, в каждом конкретном случае это решалось, но этоподрывало саму идею методологии как универсального стандарта для всех проектов. Справедливости ради необходимо отметить, что с этой же проблемой столкнулись и наЗападе, см. например статью Аарона Шенара «Один размер не подходит для всех проектов»ii. Естественным ответом на эту ситуацию стало появления проектных классификаций –подходов разделяющих проекты на группы, и адаптация базовой методологии к каждой из них.Таким образом, к каждой группе применяются свои кастомизированные требования и правила.Этот подход является на текущий момент основным для подавляющего количества организаций. В2005 году PMI даже выпустил отдельные рекомендации по данному вопросу iii. Темаклассификации и типологии проектов активно развивается, отдельные исследователи достиглиочень интересных результатовiv. Автономная некоммерческая организация (АНО), в которой я нанастоящий момент работаю (название из политкорректности опущено), вначале пошла по тому жепути.1 Правда только в том случае, если само руководство не разделяло подход «Копать! Не думать! Быстреекопать!», что в российской практике встречается к сожалению достаточно часто2 Да, да, как отлично знают все бухгалтеры, ни одной деловой активности, на самом деле, без финансовойсоставляющей не бывает. И тем не менее.
  3. 3. Стандартный подход Все счастливые семьи счастливы одинаково, а каждая несчастная семья несчастна по-своему Л.Н.Толстой Внедрение проектного управления в АНО было проведено мощно, масштабно по всемправилам (с созданием соответствующих организационных подразделений, массовымитренингами, разработкой нормативных документов и последующим внедрениемспециализированной информационной системы, настроенной на подготовленные и внедренныепроцессы). Внедрение активно поддерживалось на уровне высшего руководства. Все это в общемназывалось внедрением проектно-ориентированной организации. Уже на начальном этапе внедрения проектного управления в нашей организации былподготовлен документ «Временное Положения по проектной деятельности». Согласно данному документу все проекты классифицировались по (см.рисунок) : – Масштабу • Комплексные • Средние • Малые – Организационному охвату • Функциональные • Кросс-функциональные • Общие проекты Организации По «Крупным» проектам была определена достаточно «тяжелая» методология:обязательные этапы, необходимые роли, детальные шаблоны документов. По «малым» проектамбыли прописаны всего два обязательных документа и две роли. Для «средних» проектовспециальных требований закреплено не было – к ним относились те же требования, что и к«малым» + рекомендовалось отобрать из арсенала «крупных» то, что необходимо. К «мероприятиям» (фактически мини-проектам, выполняемым 1-2 сотрудниками) никакихтребований не предъявлялось. Только были поставлены ограничения, что мероприятия не могутдлиться больше 3-х месяцев, содержать бюджет более 1 млн.рублей и иметь трудоемкость выше3-х человеко-месяцев.
  4. 4. К сожалению, необходимо отметить, что этот подход в нашей реальности не сработал.Подавляющее большинство проектов незаметно мигрировали в «средние», т.е. «никакие» с точкизрения управления. Никаких дополнительных инструментов управления проектами проектныекоманды предпочитали не использовать. Проведенный анализ показал, что можно выделить четыре основные причины этой ситуации.  Слишком разные подразделения. В штате организации выделено более полусотни подразделений, которые занимаются очень разными вопросами, начиная от контроля строительства объектов и до подготовки волонтеров и проведения культурных мероприятий.  Слишком разный опыт Лидеров3 и менеджеров проектов. В организации работают как сотрудники с профессиональными сертификатами (PMI®, IPMA®, PME®), так и люди, только что прошедшие здесь же свое первое обучение проектному управлению и еще до конца не уверенные, что все эти прекрасные рассказы имеют отношение к реальной жизни.  Слишком много задач. Многие проекты были недостаточно обеспечены ресурсами, соответственно руководители проектов пытались максимально уменьшить «непроизводительную» с их точки зрения работу.  Слишком сложно осуществлять контроль. Большое количество проектов и небольшое количество имеющихся в центральном PMO4 ресурсов не давало возможности наладить глубокую систему контроля. В результате при очередном обновлении методологии был применен альтернативныйподход – адаптивная методология, «самоподстраивающаяся» предполагающая зависимостьотдельных элементов применяемой к проекту методологии от конкретных параметров самогопроекта.Профили и конфигураторПоздно вечером приятели начали переговоры с Конфигуратором. Арнольд настойчивонашептывал ему о прелестях повторения. Грегор громко рассуждал об эстетическомнаслаждении от многократного производства таких шедевров, как элементы системыуправления. Арнольд все шептал о трепете от бесконечного производства одних и тех жепредметов. Снова и снова — все те же детали, все из того же материала, производимые содной и той же скоростью. Экстаз! Грегор философствовал, сколь гармонично этосоответствует облику и способностям Конфигуратора. Он говорил, что повторение гораздоближе к энтропии, которая с механической точки зрения само совершенство. Роберт Шекли. «Необходимая вещь»Подход построен на нескольких основных предположениях.3 Ответственных за проект от подразделения. Осуществляет общее оперативное управление проектом.Несет ответственность за проект в целом и за соответствие результатов проекта требованиям организации.Может делегировать часть своих задач менеджеру проекта, но не может делегировать ответственность запроект.4 PMO – project management office/Центральный проектный офис
  5. 5. 1. Управление проектом может быть построено на использовании определенных инструментов проектного управления (элементов), которые можно скомпоновать в 5 основных групп:  этапы жизненного цикла проекта;  организационная структура/проектные роли;  документы;  ключевые встречи и совещания;  контрольные точки. 2. Основных элементов, необходимых в реальной жизни не так много – порядка 50-60. Они составляют общий профиль управления проектом в организации. 3. Для каждого конкретного проекта их гораздо меньше – порядка двух десятков элементов. Их совокупность для конкретного проекта, составляет Профиль управления данным проектом. Таким образом, Профиль задает набор и требования к элементам управления, которые должны быть использованы при управлении конкретным рассматриваемым проектом. 4. Отбор элементов для профиля проектов осуществляется на основе нескольких ключевых параметров проекта и его окружения (длительности проекта, бюджет, организационная сложность, количество вовлеченных подразделений и т.д.). Именно эти параметры определяют важность и полезность элементов для конкретного проекта (например, наличие в проекте представителей из более чем 3-х различных подразделений означает обязательное создание матрицы распределения ответственности, наличие нескольких подрядчиков – необходимость интеграционных встреч и т.д.). 5. Оценку полезности в зависимости от параметров можно провести с помощью экспертов заранее и зафиксировать в некоторой матрице, где будет указано, что наличие такого-то параметра приводит к необходимости (или наоборот– не нужности или рекомендуемости) некоторого элемента управления проектом (мы назвали его «Конфигуратором»).Таким образом, мы создали «Конфигуратор» – инструмент на основе MS Excel®, позволяющий наосновании оценки проекта по критериям классификации получить профиль управленияпроектом, содержащий как обязательные, так и рекомендуемые элементы управления проектом.А в общем процесс разработки и использования адаптивной методологии выглядит следующимобразом:При разработке и внедрении методологии в организации Определяется Определяются Настраивается "максимальный" возможные матрица связей профиль наиболее параметров и управления критичные элементов проектом параметры проекта ("Конфигуратор")При запуске отдельного проекта
  6. 6. Обсуждение Утверждение рекомендаций Принятие/оклонение финального профиля Заполнение значений полученного в рекомендаций и вместе с запросом на параметров результате работы формирование проекта на Проектном "Конфигуратора" финального профиля Комитете профиляСуществует общий «максимальный профиль», включающий все элементы Проект планируется Проект завершается Проект завершен Проект утвержден Терминология Прорабатывается идея проекта Проект инициирован/ выполняется 1 месяц Отчет для ПКРегулярная отчетность по Отчет о статусе проекта 2 недели или чаще проекту 1 неделя Отчет членов команды проекта Реестр вопросов и поручений 1 неделя Реестр рисков и проблем (Матрица рисков) 1 месяц или чаще План персонала проекта 2 недели или чаще Календарный план проекта Рабочие документы 1 месяц или чаще е проекта кт Финансовый план проекта ое пр ео Реестр изменений проекта ни ле ом Матрица ответственности ед Ув по по по м ы ле ы ы кт кт кт те на по еа еа еа ни в т ы м ны м ны че то ол ы кт м н от ен р а оч сп ра оч ра оч м а у ум й си ра е во ут во ут во ут во ны ны пк ок го еж го е ж го еж р го ль оч ку д во до ром до ом до ром за акет ен до ина го Пр П Оц До П Документы Ф П контрактования ов атт ль ов зу ат я по ре т ни а ль кт т и а че зу рж мк ое т о ки от ре кт пр та е м ие де ое кт й кт ие в пр со ль и т о е вы пр ор зу пр Запрос на изменение ое ан ы кт ие пр того сп на пр пис ре лан а у ол ое анОфициальные документы Па ос ок пр пис а О П И пр от О Пр За проекта Фазы жизненного цикла Предпроектный этап Оценка Выбор Определение Выполнение Завершение Постпроектный этап Ключевые вехи проекта Проект Проект утвержден Результаты Выбран оптимальный вариант Все планы разработаны и Проект закрыт инициирован на ПК проекта приняты (стратегия) реализации проекта акцептованы Совещание по запуску Конкурсная Стартовое совещание с ПК блока/ УК Комиссия по приемке ПК блока ПК ОКОИ ПК ОКОИ проекта (Kick-off) комиссия подрядчиками проекта результатов 1 неделя Ключевые Встречи команды проекта совещания Заседания УК проекта 2 месяца или чаще 1 месяц или чаще Интеграционные встречи Встречи группы 2 недели или чаще управления проектом  Стартовать проработку проекта  Провести предварительную  Уточнить границы и содержание  Оформить и заключить контракт  Выполнить работы согласно плану  Закрыть все договора по  Отследить и оценить выгоды,  Идентифицировать Владельца, проработку проекта по всем проекта, требования к результатам с поставщиками (если  Контролировать статус и отклонения проекта проекту (если применимо) полученные по результатам Лидера, Менеджера проекта аспектам (цели, сроки, финансы,  Провести анализ вариантов применимо)  Получить и принять результаты проекта  Передать результаты проекта проекта  Идентифицировать основных участники) реализации проекта  Провести детальное  Подписать промежуточные акты по проекту заинтересованным сторонам Ключевые задачи заинтересованных лиц  Оценить выгоды и  Подготовить и провести конкурс по планирование всех аспектов (если применимо)  Подготовить финальный отчет  Согласовать проект внутри блока целесообразность проекта выбору поставщиков (если проекта по проекту фазы  Известить о старте проекта  Согласовать проект с центральным применимо)  Оформить и утвердить Паспорт  Расформировать команду центральный PMO PMO, блоком финансов, проекта проекта владельцами ресурсов  Окончательно сформировать  Утвердить проект на ПК команду проекта  Делал ли кто-нибудь что-то подобное  Кто и что будет влиять на  Что можно взять из других  Все ли заинтересованные лица  Известили ли нас про изменения в смежных  Извещены ли смежные Ключевые вопросы до нас? проект? активностей? определены? активностях? активности о завершении интеграции  На кого и что будет влиять  Можно ли консолидировать  Все связанные активности  Извещены ли смежные активности о наших проекта? проект? закупки? идентифицированы? изменениях?  Предоставлены ли смежным  Все работы и точки по  Предоставлены ли смежным активностям активностям ожидаемые ими интеграции запланированы? ожидаемые ими промежуточные результаты? окончательные результаты? Условные обозначения: периодичность - периодичность для всех проектов, вне - совещания уровня ОКОИ - документы, обязательные для всех проектов (в зависимости от профиля базовом варианте) периодичность - обязательные совещания уровня проекта - периодичность зависит профиля - документы, обязательные для всех проектов (в базовом или детальном варианте) - документы, обязательные для проектов, в которых - совещания уровня проекта, которые участвует внешний исполнитель - документы, которые могут быть обязательны в обязательны в зависимости от профиля проекта зависимости от профиля проекта (в базовом или детальном варианте) - ключевые вехи проектаКак выглядят параметры (каждому параметру соответствует «закрытый» список значений, чтосильно облегчает выбор)
  7. 7. Выдаваемый результат – профиль конкретного проекта (показана часть)Более подробный отчет
  8. 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«Как это работает». Внутренности конфигуратора (главная настроечная таблица, «матрицасвязанности»). По вертикали перечислены сгруппированные элементы управления, по

×