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

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

Но не все проходит гладко. Практически каждый месяц появляется новый проект, который приносят на защиту, комитет отклоняет его, отправляет концепцию на доработку, заявка снова возвращается, снова уходит на доработку, так 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%; соответственно, выгоды от распараллеливания мы получим немного, а вот риски можем привнести, если вдруг кого-то забудем.

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

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

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

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

Комментарии (10)


  1. AllegroAssai
    12.12.2023 02:57

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


    1. Danilskvortsov Автор
      12.12.2023 02:57

      Здорово, что вы разделяете наши принципы:) какую часть статьи вам было бы интересно раскрыть через практический пример?


      1. AllegroAssai
        12.12.2023 02:57

        Интересно посмотреть на путь какого-то конкретного проекта по этим этапам, со всеми сложностями

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


        1. Danilskvortsov Автор
          12.12.2023 02:57

          Я боюсь, что конкретный проект не смогу вам показать (NDA история), но если чуть конкретнее, я могу очертить с какими проблемами мы уже столкнулись:

          1) качество планирования проектов - мне кажется, что это сложная история всегда, поэтому мы не одиноки. Как ни странно, чаще всего сталкиваемся с неоправданно амбициозными сроками (чаще всего по причине потерянного куска объема). Работаем над этим путем личного вовлечения или включения в работу над проектом тех, кто уже умеет в планирование.

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

          3) Достаточно сложно дается история с написанием конкретных критериев успешности проекта - измеримые метрики вроде как понятны, но вот декомпозировать их на те, которые действительно будут достигнуты благодаря проекту, а какие случились за счет других факторов - сложно. Ну и вторая часть: отделить бизнес-цель проекта от критериев успешности не всегда бывает просто. Работаем, тренируемся, другого тут быть не может, со временем все придет, я уверен.

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


  1. Mikhail_A_M
    12.12.2023 02:57

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

    У меня, как у ПМ, возникло несколько практических вопросов:

    1. Какой уровень проработки стадий "Инициатива" и "Запуск"? Насколько детально определены scope и бюджет?

    2. Из статьи следует, что после одобрения Инициативы, до Запуска инициатор лично прорабатывает проект, это так? На этом этапе команда еще не формируется и ПМ не назначен?

    3. Закладываете ли резервы по расписанию и бюджету? Как их определяете?

    4. Как решается вопрос нехватки/конфликта ресурсов в проектах?


    1. Danilskvortsov Автор
      12.12.2023 02:57

      Спасибо:) уверен, что у вас тоже все удастся. Отвечая на ваши вопросы:

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

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

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

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

      Надеюсь, что удалось ответить на ваши вопросы :)


      1. Mikhail_A_M
        12.12.2023 02:57

        Спасибо за ответ! 20% это прям мечта. На предыдущих местах было 5-10%, если больше - перезащита. На текущем - строго НОЛЬ.


  1. Kanstebl
    12.12.2023 02:57

    У нас магазин настольных игр, плюс клуб настольных игр, и еще разные проекты.
    Попробовали Conflurence. он оказался слишком огромным и объемным, там еще специалист нужен отдельный)))
    Всякие инструкции и документацию мы ведем на https://logycore.net/ Он очень простой и удобный. Возможностей меньше чем в Conflurence, но для маленьких проектов подходит. главное сотрудников не пугает)
    Еще пробовали notion тоже очень сложно оказалось)))


  1. mcovkin
    12.12.2023 02:57

    Отличная статья!

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

    Гейт - эксперт? Могли развернуть идею?


    1. Danilskvortsov Автор
      12.12.2023 02:57

      Спасибо, рад, что откликается. Под этим неочевидным термином кроется понятный процесс контроля. Контролируем два аспекта: суть и форму. Смотрим на то, что качество проработки соответствует требуемому уровню, условно "все понятно", деталей достаточно, все существенные атрибуты проекта есть. Форма - тут все совсем просто. Есть ряд шаблонов (по разным поводам), надо, чтобы эти шаблоны были корректно заполнены, потому что документация это важно. В чем, наверное, ключевое отличие нашей контрольной функции от привычной, мы скорее партнер, чем контролер, не ставим штамп "переделать" без объяснений. Живем в диалоге с бизнесом, РП, заказчиком, стараемся раскрыть назначение и смысл каждого пункта, фразы, показателя, слайда. Иногда и в обратную сторону работает, когда это обосновано, корректируем наш шаблон под конкретный проект. Стало чуть понятнее? Возможно в самой статье не очень аккуратная формулировка получилась :)