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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

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

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

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

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

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

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

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

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

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

А где же Agile?

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

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

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

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

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

«PRINCE2»

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

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

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

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

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

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

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

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

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

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

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

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

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

Источник

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

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

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

Что считается проектом

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

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

Рисунок 1. Условия выделения группы задач в проект

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

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

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

Управление проектами – это деятельность, в ходе которой определяются и достигаются цели проекта, при этом соблюдается баланс между объемом работ, ресурсами, временем, качеством и рисками. Наиболее популярными подходами к управлению проектами являются:

Отличия у подходов существуют, но общего значительно больше. Основные различия обусловлены масштабами управляемых проектов и гибкостью использованного инструментария. Мой взгляд на различные подходы к управлению проектами представлен в таблице 1. Важно помнить, что все это – инструменты проектного управления. Использование тех же принципов в рамках рутинных операционных задач необоснованно перегрузит ресурсы компании.

Таблица 1. Общее сравнение наиболее популярных подходов проектного управления

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

Основные этапы проекта

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

Можно выделить группы процессов, которые свойственны каждому проекту (см. рисунок 2).

Рисунок 2. Группы процессов проекта

Далее рассмотрим их подробнее.

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

Инициирование проекта можно разделить на две части:

Устав проекта – это относительно небольшой по объему документ (6–7 слайдов максимум). Напомню, что мы говорим о внутренних проектах, где исполнитель и заказчик работают в одной компании. Устав проекта преследует следующие цели:

Устав проекта резюмируется в небольшую таблицу (см. таблицу 2).

Таблица 2. Резюме проекта.

Наименование проекта: Улучшение процесса обслуживания покупателей

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

Периметр проекта: подразделение Южного-Федерального округа

Документация проекта будет рассмотрена не позднее20 декабря 2019 г.

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

Утверждение проекта – январь 2020 г.

Анализ и протоколирование источников – февраль 2020 г.

Утверждение рекомендаций – апрель 2020 г.

Внедрение рекомендаций – май 2020 г.

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

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

Этап должен ответить на следующие вопросы:

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

Результатом завершения этого этапа должен стать документ «План проекта», который будет включать в себя следующие разделы (см. рисунок 3).

Рисунок 3. Структура плана проекта

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

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

Планирование проекта – это сложный и порой дорогостоящий процесс. Самое важное на этом этапе понять два ключевых момента:

Исполнение проекта

Из всего, что важно для успешного исполнения задач проекта, можно подчеркнуть следующее:

Мониторинг и контроль проекта

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

Рисунок 4. Иерархия проектов

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

Закрытие проекта

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

Рисунок 5. Варианты закрытия проекта

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

Заключение

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

Безусловным минусом внедрения проектного менеджмента в компании являются дополнительные расходы и бюрократизация процессов. В малых масштабах оно не окупается.

Источник