Как выбрать методологию для управления проектами? Обзор популярных методологий УП

Елена Филипова, руководитель корпоративного проектного офиса «Адванта Консалтинг», сертифицированный специалист Project Management Institute, квалификация Project Management Professional (PMP), автор книги «С чего начать внедрение проектного управления? Готовая методология контроля проектов организации»

Когда я училась в университете, мне повезло бывать на лекциях академика Габдулхаева. Не имея понятия об управлении проектами, он учил нас гибкости применения наших знаний, выбору оптимального метода. Его любимый вопрос на экзамене: «Какой метод приближения лучший?». А правильный ответ гласил: «Лучшего нет, в каждой ситуации лучший метод свой». Тоже самое можно сказать и о проектном менеджменте: в каждом проекте, и даже в каждой фазе проекта, может быть свой, лучший подход, своя методология. Как выбрать то, что подходит? Чем отличаются популярные методологии, и в каких проектах их лучше применять?

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

Я часто провожу обучение по управлению проектами и почти всегда слышу один и тот же вопрос: чем отличаются разные методологии, и что лучше выбрать. Для меня подобный вопрос сродни «на каком автомобиле лучше ездить?». На этот упрощенный вопрос гораздо легче ответить, ведь все понимают, что прочувствовать разницу в классе автомобиля, выявить плюсы и минусы автопроизводителя может только опытный водитель. Чтобы понять «что лучше», нужно научиться хорошо управлять автомобилем, в принципе, получить опыт управления в разных ситуациях и на разном покрытии, попробовать несколько марок и моделей, и только тогда можно сделать вывод, какой автомобиль тебе по-настоящему подходит.  К сожалению, в случае с управлением этот цикл может оказаться длиною в жизнь. Кроме того, «пересесть» с одной методологии на другую — это особый проект, который у большинства не получается выполнить быстрее, чем за три года. Поэтому, особенно на старте, хочется подобрать что-то надежное и подходящее.

В мире не так уж и много «официальных» (признанных) методологий, из которых можно выбирать:

При этом большинство (ISO 21500, ГОСТ Р 54869-2011, APMBOK, C-PMBOK) ориентированы на старейший стандарт PMBoK (USA), а другие (P2M, PRINCE2, ICB IPMA) используют собственные подходы.

Что такое методология? Для ее существования необходимо несколько принципиальных моментов:

• Жизненный цикл
• Описание процессов
• Ключевые роли и их функции
• Требования к компетенциям
• Чек-листы качества
• Шаблоны и их образцы

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

Смотрите, как все просто: берете план, вводите в информационную систему статус работ и поставляете результаты. И чего только все так с проектами мучаются? Методология как бы концентрируется на внешнем контуре, а специфику исполнения работ отдает на откуп конкретному руководителю проекта. Но в именно специфике почти всегда и кроется «корень зла», именно из-за особенностей компании, ее инфраструктуры, культуры людей и просто характеров участников проекты либо успешны, либо нет.

А где же Agile?

Я уже предчувствую возмущенные голоса поклонников гибких подходов. Но спешу вас успокоить, что помню про Agile, но намеренно не причислила его к кругу других методологий, потому что это… не методология. Тот, кто знаком с историей возникновения Agile знает, что речь идет об особых подходах к производству и управлению. Кратко сформулировать их можно так:

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

Даже на основании этого манифеста (2001 г.) можно понять, что так же, как проектные команды не ориентированы на документирование, так и сами идеологи Agile не будут тратить время на детальное описание методологии. Последний Scrum Guide (наиболее популярный фреймворк) изложен менее, чем на 20 страницах в сравнении с более, чем 800 страницами PMBoK. «Практика, практика и еще раз практика» - говорят сторонники Agile.

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

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

«Классический» (PMBoK и его модификации)

PMBoK зародился в 70-х годах прошлого века для обеспечения управления проектами космической и оборонной промышленности США. Это объясняет, как объем документа, число процессов и сложность его применения малыми и средними компаниями.

«PRINCE2»

Первая редакция британского стандарта PRINCE2 вышла в свет в 1989 г. и была направлена на управление правительственными проектами по созданию информационных систем. Это объясняет более строгое отношение PRINCE2 к окупаемости и применению продукта.

«Гибкие подходы» (SCRUM)

Более гибкие подходы к управлению проектами стали активно развиваться с прогрессом компьютеризации и программирования. Существующие стандарты тормозили проекты по разработке программного обеспечения, требовались совершенно новые подходы. Поэтому в 2001 году в США встретились передовые 17 разработчиков и сформулировали контур движения Agile. Одним из наиболее популярных фреймворков стал SCRUM.

Как выбрать то, что подходит?

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

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

• Компании среднего уровня практически невозможно полностью применить конкретную методологию. Внедрение «во что бы то ни стало» отнимает время и не способствует достижению целей.
• Выбор методологии должен определять конкретный проект или его фаза. Определять подход к управлению должен не руководитель проекта (наиболее удобный ему), а специфика производства продукта и результатов.
• Если вы хотите сократить время на изобретение своего велосипеда – уделите время чтению. Особенно успешные руководители, не зная стандартов применяют то, что в них написано.
• Даже пара обуви, выпущенная в 1000 экземпляров, будет единственным в мире образом стоптана вашими пятками (мое собственное изречение). Даже стараясь применить конкретный подход или метод, делайте это, адаптируясь к вашим особенностям.

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

Иногда в ходе практики мы находили очень эффективные собственные способы, а затем я отыскивала их прообразы в других стандартах. Так, будучи уверенной, что вношу небольшие корректировки в PMBoK, я начала на уровне методологии использовать регулярные частые и короткие совещания с командой (прообраз Daily Scrum Meeting), применять для фаз и ключевых результатов критерии успеха (аналог Scrum Acceptance Criteria) и многое другое.

Столкнувшись с крупными проектами, которые в комплексе должны производить несколько разных продуктов (стройка, ИТ-решение, организация) пришлось учесть в методологии возможность гибридного управления (для ИТ – Agile, для стройки – прообраз PMBoK), что отлично сработало.

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

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

Чтобы дойти до цели, человеку нужно только одно. Идти. 
Оноре де Бальзак

Спасибо, Вы подписаны на рассылку!