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

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

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

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

Как правило, началом начал любой методологии является описание жизненного цикла. Жизненный цикл – набор этапов, через которые должен проходить проект с момента инициации до его завершения. Все проекты должны как-то начинаться, как-то планироваться, при выполнении работ должны быть налажены коммуникации, отчетность и принятие решений, а после получения всех необходимых продуктов и сервисов проект должен закрыться. Это основные фазы, которые описываются всегда и включаются в регламент управления проектами. С их началом и завершением связывают подготовку документов, по ним ориентируются для проведения регулярных совещаний и выполняются многие другие управленческие функции. Когда вы беретесь за создание методологии, то в вашем первом документе будут описаны ключевые вехи, которые дадут понимание позиции проекта, заложат основные документы и действия для управления.

Например, PMBok приводит схему жизненного цикла так:

То есть все очень просто – опишите жизненный цикл.

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

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

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

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

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

Пример визуализации плана КТ в системе ADVANTA

Пример отчета о статусе проекта в системе ADVANTA

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

• то, что дорого;
• то, что долго;
• то, что непонятно, как делать;
• то, что использует дефицитные ресурсы;
• то, что нужно руководству.

Но и это не гарантия большой сложности исполнения.

Дополнительно по теме: Что нужно знать, начиная проект, чтобы избежать провала? 

PMBoK также не дает ответа на этот вопрос. Фраза «временное предприятие для получения уникальных результатов» не раскрывает сути и иногда только мешает пониманию. С какого момента нужен отдельно назначенный руководитель, когда выполнение той или иной задачи должно освещаться в отчетности для руководства, в каких случаях требуется обучение персонала и мониторинг хода работ в программном продукте? Кроме того, если нет понимания, насколько проект сложный или важный, то возникает много связанных проблем, которые придется решать «вручную». Например:

• сложные проекты управляются как «простые» или наоборот;
• сложность работ может не учитывать необходимые компетенции руководителя или уровень его полномочий;
• нет обоснования требования «дорогих» ресурсов;
• нет обоснования мотивации/финансовой мотивации;
• сложно акцентировать важность принятия решения, сложный проект может не получить должного внимания.

Все эти вопросы приводят к необходимости создания методики определения типов проектов. Я назвала такой документ «методикой определения сложности».

Методика определения сложности проектов

Сложность проекта должна основываться на сложности управления и требованиям к компетенциям персонала. Поэтому при создании методики я руководствовалась ГОСТ Р 53892-2010 «Руководство по оценке компетентности менеджеров проектов» и использовала метод группировки по нескольким критериям. ГОСТ позволил мне выявить критерии для понимания сложности работ, а метод сформировал понятный алгоритм использования этих критериев. Для применения метода необходимо сформулировать признаки, подчеркивающие сложность выполнения проекта. Каждому признаку (критерию) назначают вес и систему оценки. Вес определяет приоритет критерия, акцентирует на той или иной сложности, а система оценки позволяет оцифровать проектные работы по признаку.

Пример системы критериев, их оценок и весов:

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

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

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

Как упростить управление: пример из жизни

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

• Проекты
• Стратегические инициативы
• Проекты описания бизнес-процессов

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

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

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

Когда термин «проект» был определен, подготовка регламента управления проектами компании не составила большого труда, мне оставалось просто собрать требования к поддержке жизненного цикла двух типов активностей. Определение жизненного цикла для действительного «ПРОЕКТА» – то, что нужно для старта методологии. Такая работа расставит все точки над «i»: определит, чем вы будете руководить, как вы это будете делать и какие документы использовать. 

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

Дополнительно по теме: Что первично: методология или ИСУП?