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

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

Шаг 1

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

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

Шаг 2

Следующий шаг после определения типов проектов — составление реестра проектов.

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

Шаг 3

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

Шаг 4

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

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

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

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

Шаг 5

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

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

Если же говорить по сути, то при формировании правил и форм отчетности необходимо для каждого проекта определить:

• кто и как часто предоставляет отчетность;

• кому идет отчетность (маршрут может быть зависим от многих факторов, например, от типа проекта, важности проекта и т. д.);

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

• что должно составлять отчетность (какие метрики должны попасть в нее обязательно, какие — при отклонениях, а какие рассматривать не стоит);

• как обрабатывается отчетность. Грубо говоря, что должен сделать тот, кто получил отчет: прочесть его, проанализировать, применить какие-то меры управленческого воздействия;

• что будет, если кто-то нарушает регламент.

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

Шаг 6

Ну а теперь пришло время определить правила работы с рисками и точки воздействия.

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

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

Поэтому, собственно, РИМ-3 и вводит понятие «КТ»: если мы обозначим КТ по уровням, то получим картину точек контроля и, вероятно, сможем сработать на опережение, если заранее поймем, что КТ, например уровня 0 (уровень контроля бизнес-результатов), «поехала».

Шаг 7

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

Когда в проекте в принципе могут возникнуть изменения? Приведу следующие случаи:

• «аппетит приходит во время еды». Начали проект, поняли, что хочется получить другой результат (больше, меньше или вообще отличающийся);

• проблемы в проекте. Столкнулись с ситуацией, которая вынуждает нас подвинуть КТ. Это может быть как «обычная», так и «рисковая» ситуация;

• внешние обстоятельства. Например, проект делался на заемные деньги, и в какой-то момент финансирование прекратилось.

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

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

Во-вторых, следует определить, как запрос на изменение влияет на мотивацию сотрудников (например, проект из полугодового становится годовым вследствие изменения конечной цели — следует ли пересмотреть мотивацию? Или, как вариант, проект требует привлечения дополнительной команды на некоторое время. Будет ли в этом случае на них распространяться мотивация, действующая на основной команде проекта?) и т. д.

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

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

Шаг 8

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

Мне в практике встречалось два случая: первый — когда внедрение проектного управления начиналось с наиболее спокойных проектов; второй — когда проектное управление внедрялось сначала для наиболее сложных проектов.

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

• технология отрабатывается на проектах, где допустим эксперимент и риски не несут больших последствий для компании;

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

Минусы такого подхода:

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

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

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

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

• более быстрое, по отношению к модели «от простого к сложному», внедрение и распространение модели проектного управления.

Минусами в данном случае будут:

• высокие риски сопротивления со стороны участников проектов (менять что-то в налаженном механизме довольно сложно);

• при подобной работе команда внедрения проектной методологии может оказаться в одном контуре ответственности с командой проекта («это они со своими менеджерскими штучками»).

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

• степень удовлетворенности топ-менеджеров текущим положением дел;

• степень удовлетворенности руководителей проектов текущим положением дел.

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

• наличие явного и влиятельного заказчика изменений;

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

Шаг 9

Здесь надо составить план расширения от пилотной группы до полного объема проектного управления. Необходимо понимать, как и когда какой проект будет включаться в контур проектного управления. Как правило, на этом шаге производится обязательное согласование плана с заказчиком внедрения проектного управления и топ-менеджерами (опционально — с руководителями проектов, но, опять-таки, когда и что с кем согласовывать и что не согласовывать — зависит от конкретной ситуации и конкретной организации).

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

Шаг 10

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

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

На этом этапе важно договориться о том, чтобы определить дату старта проектного управления. Затем можно начинать проект «в целом».

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

• перспективную оргструктуру подразделения, которое будет заниматься внедрением ПУ;

• оргпреобразования, которые планируется сделать (будет ли команда внедрения ПУ сохранена после проекта, если да, то в каком статусе, что потребуется изменить в оргструктуре компании по ходу и после внедрения и т. д.);

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

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