Внедрение проектного управления. Практическое руководство по созданию Проектного Офиса

Дизайнер обложки Мадина Уралова

Корректор Анна Ильина

Редактор Мадина Уралова

© Александр Смирнов, 2022

© Мадина Уралова, дизайн обложки, 2022

ISBN 978-5-0056-7677-1

Создано в интеллектуальной издательской системе Ridero

Об авторе

Александр Борисович Смирнов – профессиональный руководитель проектов, бизнес-тренер и консультант в области проектного управления с более чем 20-летним опытом. Имеет степень MBA, сертификации PME®, PMP®, ICP® (ICAgile Certified Professional), авторизован PMI® проводить курсы подготовки к сертификации на степень PMP®.

Успешно реализовал более ста проектов, в том числе ряд проектов по внедрению проектного управления в компаниях различной направленности (производство, логистика, продажи, строительство, информационные технологии). Провел более двухсот тренингов по управлению проектами. Автор обучающих курсов в области управления проектами. Более 10 лет проработал в качестве топ-менеджера на позициях руководителя проектного офиса, заместителя генерального директора, операционного директора, директора по закупкам, директора по логистике.

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

Введение

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

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

Итальянские и африканские студенты наотрез отказались изучать китайский язык. Немец оценил необходимую длительность подготовки в 5 лет, француз согласился изучить за 4 года, беспечный латыш обязался за 3 года освоить непростой язык.

Наконец, добрались исследователи до Саратовского Института Сталей и Сплавов, подходят к студенту, который курит у входа в институт:

– Китайский язык сдашь? Хорошо заплатим.

Студент неопределенно мотает головой:

– Ну что ж не сдать. Сдам.

– А когда будешь готов?

Студент задумчиво:

– А методичка есть?

Исследователи недоуменно переглядываются между собой.

– Ну есть, в принципе, методичка…

Студент спокойно отвечает:

– Ну тогда сейчас докурю и сдам.

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

Но не все так просто. И сделать, как в анекдоте – докурить, а затем быстренько внедрить проектное управление – не получится.

Во-первых, PMBоK не является методическим руководством по построению проектного офиса, а во-вторых, мощь инструмента должна соответствовать поставленной задаче. PMBоK создавался в основном как набор лучших практик, скорее для крупных проектов, он избыточен для небольших проектов. И в любом случае PMBоK не является регламентом по управлению проектами.

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

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

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

Необходимая оговорка: в данной книге я рассматриваю вариант внедрения проектного управления, использующего классический (или предиктивный, водопадный) подход к управлению проектами. Agile пока применим к довольно ограниченному числу проектов, да и внедрять Agile на самом деле не нужно – agile-культура должна появиться сама… Но это совсем другая история.

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

В разделах книги пошагово описано, как внедрить управление проектами в компании «с нуля», со всеми необходимыми шаблонами и примерами. Шаги не обязательно делать в строгой последовательности (хотя порядок и не помешает).

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

Глоссарий

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

– это ограниченная временем деятельность по созданию новых (уникальных) продуктов, услуг или результатов (PMI PMBоK);

– это уникальное, временное, мультидисциплинарное и организованное усилие, направленное на получение согласованного конечного результата в рамках предопределенных требований и ограничений (ICB 4);

– это одноразовая, не повторяющаяся деятельность или совокупность действий, в результате которых за определенное время достигаются четко поставленные цели (DIN 69901);

– это комплекс взаимосвязанных мероприятий, направленных на создание уникального продукта или услуги в условиях временных и ресурсных ограничений (ГОСТ Р 54869—2011).

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

Предиктивный подход (водопадный подход, waterfall) – классический подход к управлению проектом, при котором разрабатывается четкий план реализации проекта, состоящий обычно из этапов инициации, планирования, исполнения, мониторинга и контроля, завершения.

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

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

Критическая задача – любая задача на критическом пути. Если увеличить длительность такой задачи – то длительность проекта также увеличится.

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

Частными критериями успешного выполнения проекта являются его KPI – сформулированные в соответствии с принципами целеполагания SMART (правильная постановка цели означает, что цель является конкретной, измеримой, достижимой, значимой и соотносится с конкретным сроком) промежуточные и окончательные результаты выполнения задач проекта.

FTE (Full-time equivalent) – оценивает долю участия сотрудника, например, в проектной деятельности. Занятость в проекте с FTE 0,2 означает, что сотрудник тратит 20% своего рабочего времени на работу в проекте. Если у него стандартная 40-часовая рабочая неделя, значит, 40 х 0,2 = 8 часов – именно столько часов в неделю сотрудник будет тратить на работу в данном проекте.

КСУП – Корпоративная Система Управления Проектами, включающая в себя:

– Проектный офис, команды управления проектами;

– методологию управления проектами, регламент;

– информационную систему управления проектами.

ИСУП – информационная система управления проектами.

Устав проекта – один из ключевых документов, описывающих цели проекта, ключевые задачи, допущения, ограничения проекта, сроки и бюджет проекта. Дает старт проекту и назначает руководителя проекта. Разрабатывается на этапе инициации проекта. Также может называться Меморандумом, Карточкой проекта, Приказом, Project Charter и др.

PMO (Project Management Office, Проектный офис) – структурное подразделение, выполняющее роль центра компетенций в области управления проектами. Может выполнять контрольно-ревизионные и администрирующие функции, в случае необходимости – антикризисное управление.

Также в состав Проектного офиса могут входить руководители проектов и администратор Проектного офиса. Функционал подразделения подробно описывается в Положении о Проектном офисе.

Может также называться Проектным отделом, или Отделом/Департаментом управления проектами. Это совершенно не принципиально и зависит от общей структуры компании. Также Проектный офис может состоять из одного человека, являющимся больше методологом – а руководители проектов могут находиться в других подразделениях компании.

Далее в книге будет использоваться термин «Проектный офис» или аббревиатура «РМО».

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

Управляющий Комитет (УК) – совещание в рамках проекта (обычно ежемесячное), на котором могут присутствовать руководитель проекта, Заказчик, Куратор проекта, ключевые эксперты.

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

Команда управления проектом – члены команды проекта, которые непосредственно вовлечены в управление проектом, включая представителей некоторых участников проекта и технический персонал. В команду управления проектом входят: Заказчик, Куратор, руководитель проекта, администратор проекта.

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

Руководитель проекта (РП, менеджер проекта, project manager, PM) – сотрудник, несущий перед Заказчиком и Куратором проекта всю полноту ответственности за соответствие промежуточных и окончательных результатов проекта заданным целевым значениям параметров качества, достижение его целей, эффективное распоряжение бюджетом проекта и соблюдение сроков его реализации.

Все члены команды проекта подчиняются руководителю проекта в рамках проекта в соответствии со своими функциональными ролями, закрепленными за ними в Уставе проекта.

Инициатор проекта – любое должностное лицо компании, являющееся автором идеи проекта и постановщиком начальных задач по нему. Роли Инициатора и Заказчика проекта могут быть совмещены.

Заказчик проекта – будущий владелец и основной пользователь результатов проекта. Обладает полномочиями по запуску, приостановке или прекращению работ проекта. Осуществляет окончательную приемку промежуточных и конечных результатов проекта. Обычно это Генеральный директор либо профильный топ-менеджер. Роли Инициатора и Заказчика проекта могут быть совмещены. Для проекта внедрения проектного управления Заказчиком должен быть либо один из акционеров бизнеса, либо генеральный директор компании. Куратором в идеале должен быть один из ключевых топ-менеджеров компании.

Куратор проекта (Спонсор) – полномочный представитель Заказчика в проекте (один из топ-менеджеров). Осуществляет контроль хода исполнения проекта по укрупненным показателям со стороны высшего руководства. Может курировать несколько проектов, как не связанных между собой, так и объединенных в портфель/программу.

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

Куратор возглавляет Управляющий комитет проекта, проводит заседания УК, утверждает протоколы УК и ежемесячный отчет о прогрессе по проектам своей зоны ответственности.

Роли Куратора и Заказчика проекта могут быть совмещены. Роли Куратора и руководителя проекта совмещены быть не могут.

Администратор проекта – участник команды проекта, который отвечает перед руководителем проекта за техническое обеспечение исполнения проекта и документооборот.

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

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

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

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

Изучите компанию

Начинать проект внедрения проектного управления необходимо с тщательного изучения компании. Для этого есть ряд причин.

Во-первых, далеко не всем компаниям нужно внедрять управление проектами. Например, если основная деятельность компании – покупка в Италии газовых котлов и продажа их затем в России – зачем ей управление проектами? Какие проекты будут там запускаться, с какой целью? Покупай и продавай котлы, налаживай операционные процессы, развивай продажи и клиентский сервис. Управление проектами, скорее всего, будет для такой компании лишним.

Абсолютное большинство компаний – процессно-ориентированные. У них существуют определенные хорошо налаженные (или не очень хорошо налаженные) бизнес-процессы, в результате которых рождается какой-то продукт или услуга. И этот продукт или услуга ежедневно предлагается широкому спектру потребителей. В такой компании чрезвычайно важны процессы, а уж если возникнет очень важный и срочный проект (например, внедрение CRM или ERP-системы), им проще нанять внешнего подрядчика, который все сделает «под ключ», чем выстраивать ради одного проекта проектное управление в компании.

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

Самый простой способ сделать это – проверить текущие крупные активности компании – являются ли они проектами. Если Вы действительно видите десятки активностей, формально подпадающих под определение «проект» – это хороший знак. А вот если их приходится отыскивать, и самый крупный проект – это обновление 1С, это повод задуматься, нужны ли компании проекты.

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

Раздел «Предпосылки проекта» из Устава проекта внедрения проектного управления в компании-лидере рынка в России в своей отрасли (ИТ сфера)

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

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

В-третьих, у компании может быть своя специфика, которая будет препятствовать успешному началу реализации проекта создания РМО.

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

Будет еще и «в-четвертых», и «в-пятых», и так далее. Этап аналитики очень важен, пропускать его нельзя.

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