Привет, Хабр! Меня зовут Данил, я директор по развитию стратегических проектов в СТД “Петрович”. Давайте поговорим о проектном управлении на длинной дистанции – как теоретическая целевая модель процессов реализуется на практике. 

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

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

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

Когда-то подобное могло случаться и у нас. Сейчас – за последние полгода только 1 проект из 15 был отправлен на доработку и благополучно прошел защиту со второго раза. Такое изменение стало возможно благодаря новой модели проектного управления.

Давайте расскажу, как устроена эта концепция.

Предпосылки для реформы проектного управления

“Петрович” – федеральный ретейлер в сегменте DIY и строительных товаров. Бизнес растет, поэтому управление изменениями – не разовая потребность, а привычное дело, можно сказать, что это часть ДНК компании.

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

За последние несколько лет компания выросла существенно (в продажах – в 10 раз за 10 лет, до 119 миллиардов рублей без НДС в 2022). Побочный эффект роста – результативность и скорость изменений может снижаться, как и качество их внедрения. 

Основная форма управления изменениями в компании – проектная деятельность, поэтому для улучшения ситуации мы стали улучшать в первую очередь модель управления проектами. 

Для начала мы посмотрели на статистику, чтобы очертить границы. В среднем мы реализуем примерно 20-25 проектов за год, при этом на стадии проработки и исполнения у нас одновременно находится до 70 активностей схожего масштаба.

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

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

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

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

Такие находки подтолкнули нас к масштабной реформе проектного управления.

Цели реформы

Чего хотим достичь с помощью реформы проектной деятельности – мы сформулировали как OKR:

1. Ноль секретности: все заинтересованные стороны знают о происходящем все детали на каждом этапе работ.

2. Time-to-market проекта равен его критическому пути.

3. Ноль активностей, отправленных на доработку после принятия решения о запуске.

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

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

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

Ключевые атрибуты

Целевой набор параметров проекта мы сформулировали следующим образом: 

1. Бизнес-цель – то, ради чего все делается (зарабатывать больше, тратить меньше, иметь меньше рисков и тому подобное).

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

Результат формулируется по SMART, критерии успеха вносятся в устав.

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

Сюда могут входить расходы на подрядчиков и программное обеспечение; время сотрудников и внимание менеджмента (кто непосредственно вовлечен в работу). 

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

4. Финансовая модель – NPV, IRR, TCO, где применимо.

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

5. Вовлеченные стороны – люди, которые должны знать о проекте и участвовать в формировании требований к нему. 

Тут мы применяем DACI-framework в несколько упрощенном виде – используем как реестр вовлеченных сторон, не расписывая по задачам "букву" для каждого. Главная цель – никого не забыть.

Элементы системы

Далее, мы определили, что система у нас будет состоять из шести частей:

• ролевая модель;

• этапы и события; 

• репозиторий данных;

• коллегиальные органы;

• бюджет;

• Quality Gate в проектной деятельности.

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

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

Наш список причастных: 

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

Задача инициатора – превратить идею в проект; на этапе планирования это основная роль.

• Заказчик (созаказчик) – это руководитель, который получает выгоду от реализации соответствующих работ. 

Требование: заказчик формально должен быть руководителем уровня не ниже, чем минус два уровня от генерального директора, 

Заказчик подтверждает целесообразность проработки идеи и ее доведение до проекта; отвечает за достижение бизнес-целей.

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

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

• Руководитель – отвечает за выполнение работ по проекту в оговоренных рамках (деньги, сроки, риски, команда и так далее), а также за достижение KPI. 

Оценка результатов происходит через проверку критериев успеха (Definition of Done).

• Руководитель от ИТ – если проект содержит существенную ИТ-составляющую.

• Лицо, ответственное за строительство – соответственно, для тех случаев, когда есть существенная строительная составляющая.

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

• Эксперты – люди, к кому проектная команда приходит за конкретной экспертизой. 

Они не участвуют в работах непосредственно, но требования от них также учитываются (юристы, налоговики и другие). 

• Финансовый контролер – отвечает за оценку финансовой модели и бюджета.

Эта роль – наша собственная придумка. 

• Эксперт по проектному управлению – поддерживает руководителя в подготовке к корпоративным процедурам, сопровождает регулярные отчеты.

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

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

Этапы и события мы привязываем к корпоративным процедурам.

Список такой: 

• Инициатива – это когда есть идея и что-то надо сделать, но пока непонятно, что конкретно, сколько это будет стоить; нет подробностей. 

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

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

• Запуск – этап, когда после проработки инициативы мы принимаем решение о реализации проекта. 

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

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

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

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

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

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

• Закрытие – когда выполнены критерии успеха (Definition of Done), мы имеем возможность отчитаться о закрытии проекта и снятии обязательств с команды (“сделали все, что обещали”). 

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

• Пост-мониторинг – проверка достижения бизнес-цели.

Это фоновая процедура, которая запускается после закрытия проекта. Например, за счет выполненных работ мы планировали зарабатывать больше денег; в таком случае, соответственно, мы мониторим конкретный сегмент бизнеса, на который было оказано воздействие, и в течение заданного отрезка времени отслеживаем, выходим мы на целевые параметры или нет. По итогам пост-мониторинга мы собираем список идей об успешных и неуспешных решениях, проводим ретроспективу по целеполаганию (Lessons Learned).

Такая структура этапов и точек принятия решения, совмещенная с постоянным подключением к командам со стороны эксперта по проектному управлению – позволяет повысить общий средний уровень качества реализации. Да, мы тратим довольно много времени на планирование, но на длинной дистанции мы за счет этого сокращаем time-to-market – риск переделок в процессе выполнения работ сокращается.

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

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

Коллегиальные органы – фигурировали в тексте выше под названием “комитеты”. 

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

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

В итоге в качестве принципа разделения контекста мы решили взять привязку к стадиям реализации проекта. Так у нас появились два коллегиальных органа: комитет по изменениям и комитет по проектным инвестициям.

Комитет по изменениям – собирается два раза в месяц, широким составом (50+ человек). Обсуждаем там идеи на самой ранней стадии проработки, слушаем отчеты по проектам. 

Комитет по проектным инвестициям – собирается один раз в месяц, узким составом (до 15 человек). Принимает решения о запуске проектов, изменении рамок и закрытии.

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

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

Quality Gate – эксперты по проектной деятельности, которые помогают руководителям. 

Это краеугольный камень всей нынешней реформы. 

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

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

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

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

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

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

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

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

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

"Все модели неверны, но некоторые полезны"

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

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