Бесплатный фрагмент - Внедрение проектного управления

Об авторе

Александр Борисович Смирнов — профессиональный руководитель проектов, бизнес-тренер и консультант в области проектного управления с более чем 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С, это повод задуматься, нужны ли компании проекты.

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

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

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

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

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

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

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

Ответьте на десять вопросов

Для начала ответьте сами себе, верны ли эти утверждения?

1. Лично собственник Компании не заинтересован во внедрении системы управления проектами.

2. Компания является процессно-ориентированной и в настоящее время у компании нет проектов.

3. Компания относится к сфере малого бизнеса.

4. Компании недостаточно свободных финансовых средств для нормальной операционной деятельности.

5. Компания не готова дополнительно финансово мотивировать сотрудников за работу в проектах.

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

7. В Компании имел место прецедент, когда руководителю и/или членам команды успешно завершенного проекта не выплатили обещанные бонусы.

8. В Компании не внедрено управление процессами и не планируется к внедрению в среднесрочной перспективе.

9. Компания находится в кризисной ситуации, стратегия Компании подразумевает экономию расходной части бюджета.

10. Управление в Компании осуществляется в основном напрямую Собственником/Генеральным директором, делегирование не выстроено.

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

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

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

Опросник

Название компании:

Сфера деятельности:

Количество сотрудников в Компании:

Количество сотрудников, задействованных в проектах в ролях:

— Заказчик проектов:

— Куратор проектов:

— Руководитель проектов:

— Исполнитель, эксперт и проч.:

Основные типы проектов:

Длительность проектов, месяцев:

— минимальная:

— средняя:

— максимальная:

Общее количество активных (запущенных) проектов:

Количество проблемных проектов:

Главными проблемами в проектах являются:

— сдвиг сроков;

— превышение бюджета;

— низкое качество продуктам проекта;

— низкий уровень удовлетворенности Заказчиков проектов;

— непрозрачность проектов для руководства;

— другое:

Оцените текущую удовлетворенность Заказчиков проектов по шкале от 1 до 10:

— результатами проектов:

— качеством ведения проектов:

— отчетностью по проектам:

Для коммуникаций в проектах используются:

— электронная почта;

— мессенджеры;

— аудиоконференции/видеоконференции;

— личные встречи (совещания);

— другое:

Информация по проектам хранится:

— локально;

— на общем сетевом ресурсе;

— в облаке;

— другое:

Управление рисками в проектах:

— не производится;

— ведется интуитивно и/или не всеми;

— есть некая система, но не обязательная к применению;

— риски учитываются в большинстве проектов — как минимум на стадии планирования;

— работа с рисками производится по методологии и в течение всего проекта.

Информация по проектам для внешних подрядчиков/заказчиков:

— недоступна;

— частично доступна или по запросу;

— доступна 24/7.

Для планирования проектов используется следующее программное обеспечение:

Отчетность по проектам:

— отсутствует;

— есть, но не по всем проектам;

— отчетность в полном порядке.

Руководитель Проектного офиса:

— отсутствует, планируется подобрать внутри компании;

— отсутствует, планируется найм;

— требуется обучение или замена;

— присутствует;

— отсутствует и не нужен.

Поддержка внедрения проектного управления по шкале от 1 до 10:

— со стороны Собственника/Акционеров:

— со стороны топ-менеджмента:

— со стороны участников проектной деятельности:

Управление бизнес-процессами:

— полностью отсутствует;

— местами присутствует;

— большей частью бизнес-процессы описаны;

— бизнес-процессы выстроены практически идеально.

Система управления задачами:

— отсутствует;

— работает не для всех и/или в ручном режиме;

— существует некая единая система (типа Excel-файлов);

— существует полноценная система управления задачами.

Опыт внедрения проектного управления в Компании:

— отсутствует;

— есть негативный опыт (внедрение завершилось неудачей);

— есть позитивный опыт (тогда где Проектный офис?).

Желаемые сроки внедрения:

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

Имеющиеся жесткие ограничения, касающиеся внедрения РМО (бюджет, сроки, программное обеспечение, ресурсы и т.д.):

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

Основная цель внедрения проектного управления:

— улучшить результаты реализации проектов;

— улучшить управляемость проектами (руководителями проектов);

— получить реальную информацию по проектам;

— желание владельца компании/акционеров;

— внешние заказчики требуют систему управления проектами;

— общее недовольство внутренних/внешних заказчиков.

Ожидаемые выгоды от внедренной КСУП:

— прозрачная система отчетности;

— выстроенная система коммуникаций;

— сокращение отставаний по срокам;

— единая методология;

— оптимизация затрат на управление проектами;

— удовлетворенность Заказчиков.

Ожидания Заказчика от РМО на первом этапе (до 1—2 месяцев):

Ожидания Заказчика от РМО на втором этапе (на горизонте до 6 месяцев):

Ожидания Заказчика от РМО на последующих этапах (на горизонте 1 год и более):

Ожидания от отчетности по проектам:

Дополнительные пожелания к РМО:

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

Озвучьте Манифест управления проектами

Немного лозунгов из серии «Как оно должно быть»:

«Проекты — двигатель Компании в целом и карьеры участников проектов»

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

«Первое лицо компании и топ-менеджмент — всячески поддерживает проектное управление»

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

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

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

Довольно популярной является модель Гарольда Керцнера, описывающая пять уровней зрелости проектного офиса.

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

Давайте рассмотрим каждый из уровней более детально.

Уровень 1. Общий язык

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

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

Уровень 2. Общие процессы

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

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

Уровень 3. Единая методология

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

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

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

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

Уровень 4. Перенятие опыта

Четвертый уровень возможен только после успешного достижения 3-го. На этом уровне Проектный офис берет на себя новые функции — функции контролера.

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

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

Уровень 5. Постоянные улучшения

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

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

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

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

Определите ключевые Принципы управления проектами

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

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

Принципы управления проектами:

— централизация полномочий по принятию всех оперативных решений и ответственности за достижение целей и решение задач проекта на уровне руководителя проекта;

— целостность и непротиворечивость проекта как временной структуры;

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

— регламентированность действий и коммуникаций участников проекта;

— работа в едином технологическом пространстве (проектный сервер);

— свободный информационный обмен внутри проектной команды;

— экономическая целесообразность проектной деятельности: задачей управления проектами является минимизация финансовых рисков и дополнительных/внеплановых затрат;

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

— предварительное резервирование ресурсов на этапах инициации и планирования проектов при подготовке Устава проекта, разработки расписания и бюджета проекта, которые согласуются с ресурсными менеджерами и утверждаются Наблюдательным Советом;

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

— выделение дополнительных ресурсов санкционируется УК либо НС на основании аргументированного запроса руководителя проекта, согласованного Куратором проекта.

Согласуйте Концепцию Проектного офиса

Иногда бывает полезно согласовать с Заказчиком некую концепцию Проектного офиса — синхронизировать ожидания. Ниже пример концепции для одного из проектов внедрения проектного управления.

Концепция проектного офиса компании *********

Проектный офис (РМО) — подразделение Компании. Руководитель проектного офиса напрямую подчиняется генеральному директору Компании. Сотрудники РМО — руководители проектов (РП). Проектный офис — единый центр управления проектами компании.

Цели РМО:

1. Организовать проекты компании в соответствии с отраслевыми и рыночными стандартами, адаптированными под специфику Компании.

2. Поддерживать и контролировать ключевые процессы исполнения проектов: планирование, управление рисками, проблемами, ожиданиями, изменениями, ресурсами, бюджетом.

3. Быть «фабрикой проектов»: создать и поддерживать единый ритмичный масштабируемый процесс исполнения проектов.

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

Для достижения поставленных целей РМО использует следующие подходы:

— нанимает руководителей проектов, квалификация которых позволяет достигать целей проектов и целей Компании;

— обучает руководителей проектов, помогая им расти профессионально;

— распределяет проекты между руководителями проектов в соответствии с их компетенциями;

— дает руководителям проектов инструменты управления проектами — методики, шаблоны, программное обеспечение;

— внедряет, адаптирует и развивает лучшие практики проектного управления в компании;

— контролирует исполнение проектов компании;

— обеспечивает руководство компании своевременными и качественными отчетами о статусе проектов;

— контролирует уровень компетенций РП, проводит их аттестацию;

— формирует портфель проектов компании и консультирует руководство по вопросам управления портфелем;

— развивает горизонтальные коммуникации между проектами, руководителями проектов, проектными командами;

— продвигает идеи и подходы проектного управления во всех подразделениях компании.

Определите целевую организационную структуру управления проектами

Организационная структура компании может выглядеть по-разному. От текущей и будущей (целевой) организационной структуры компании может существенно зависеть план внедрения проектного управления.

Функциональная организационная структура

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

Если компания ратует за сохранение после внедрения РМО функциональной структуры — это повод задуматься, стоит ли вообще внедрять в компании проектное управление. Скорее всего, это не будет иметь большого смысла.

Проектная организационная структура

Проектная организационная структура — довольно редкий случай. Это идеальная организационная структура для работы с проектами — руководители проектов имеют в этой структуре максимальную власть и полномочия.

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

Матричная организационная структура. Слабая матрица

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

Например, инженер участвует в трех проектах — в двух в роли эксперта, и в одном в роли исполнителя. У этого инженера в сумме целых четыре руководителя, так как у него еще есть непосредственный, функциональный руководитель — начальник инженерной группы.

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

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

Матричная организационная структура. Сбалансированная матрица

Сбалансированная матрица встречается довольно часто в компаниях, в которых выстроено управление проектами. Главное отличие сбалансированной матрицы от слабой: в структуре появляется руководитель проекта, который занимается только проектами, это его основная обязанность. Однако все руководители проектов находятся в своих подразделениях, выделенного отдела управления проектами не существует.

Матричная организационная структура. Сильная матрица

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

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

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

Матричная организационная структура. Смешанная матрица

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

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

Определите основые задачи проектного управления (пример)

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

2. Выявить структурную декомпозицию работ проекта (основные работы, которые предстоит выполнить для достижения целей и решения задач проекта, а также — их взаимосвязи).

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

4. Рассчитать потребность в ресурсах, проанализировать риски проекта, определить необходимые объемы и источники финансирования, а также необходимый уровень резервов бюджета.

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

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

7. Организовать эффективный документооборот и хранение информации в рамках проекта, обеспечить высокую информированность руководства компании о ходе его реализации.

Зафиксируйте цели проекта внедрения

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

Какой может быть главная цель внедрения проектного управления? Вот некоторые часто встречающиеся варианты:

— повысить эффективность работы Компании;

— уменьшить отклонения в проектах (чаще всего по срокам);

— запустить ключевые проекты;

— выстроить стройную и прозрачную систему управления проектами с регламентацией, отчетностью и контролем.

Определите ограничения проекта внедрения

Какие могут быть ограничения? Приведу некоторые из моей практики:

— руководителем проектного офиса будет А. Иванов, другие варианты не рассматриваются;

— руководителя проектного офиса нужно обязательно найти внутри компании, найм извне не рассматривается;

— руководителем проекта ********** должен быть **** **************;

— КСУП должна быть только ******, так как у нас уже есть лицензии;

— все руководители проектов должны находиться в функциональных подразделениях, а не в Проектном офисе;

— бюджет на внедрение проектного управления составляет не более N рублей;

— бюджет на внедрение проектного управления составляет ноль рублей;

— проектный офис должен заработать к **.**.****;

— никакого Agile;

— методология должна быть построена на основе ГОСТ.

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

Разумеется, все ограничения нужно будет занести в Устав проекта.

Договоритесь о параметрах приемки результатов

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

Можно (и нужно!) подсказывать Заказчику правильные ответы. Он ведь не обязан разбираться в тонкостях внедрения проектного управления — для этого он пригласил профессионала, то есть Вас. Поэтому предлагайте свои варианты!

Несколько примеров возможных результатов по итогам внедрения РМО:

— существует общая терминология по управлению проектами, понятная всем участникам проектов;

— создан центр компетенций в области управления проектами (Проектный офис);

— описаны бизнес-процессы в рамках управления проектами;

— имеется общая методология управления проектами;

— внедрена информационная система управления проектами;

— внедрена система мотивации участников проектной деятельности;

— проведено обучение управлению проектами;

— разработан план развития компетенций сотрудников в области управления проектами;

— создан единый реестр проектов, реализуемых в Компании;

— создан и функционирует Проектный Комитет;

— имеется и функционирует общая система периодической отчетности по проектам;