От проектирования системы к реальной работе по целевым процессам руководители проектов, команды и проектный офис мы перешли ровно через 1 месяц , а еще через 1,5 месяца модель работы была стабилизирована и подготовлена к тиражированию.
В кейсе вы узнаете о проекте по внедрению гибридного управления, который мы реализовали в FMCG-компании, для запуска новых продуктов; о том, почему этот проект стал актуальным для организации и какие были поставлены цели и задачи. Также мы расскажем про предложенный подход к управлению сроками и отклонениями.
О компании
Ведущий российский FMCG-производитель косметических товаров, бытовой химии и продуктов питания. В отдельных сегментах занимает до 19% российского рынка. Продукция компании представлена на рынках СНГ и других стран мира.
Компания одновременно реализует 60-70 проектов по разработке новых продуктов, десятки проектов по организационным изменениям и развитию компетенций, несколько проектов по внедрению различных ИТ-систем и приложений, а также большое количество проектов по изменению упаковки.
Проблематика
В компании создан проектный офис, более года внедряется проектное управление. Предшествующие попытки внедрения новых процессов и ИТ-инструментов проектного управления забуксовали и были приостановлены. Новое руководство, отвечающее за развитие проектного управления и запуск новых продуктов на уровне Правления, решило сделать еще один «подход к снаряду», переосмыслив жизненный цикл проекта, разделив его на исследовательский и коммерческий этап. С учетом предпринимательского духа компании требовалось внедрить максимально простые и прагматичные подходы к управлению проектами, поддерживаемые сквозными ИТ-инструментами.Работы на исследовательском этапе проектов, например, разработка дизайна или рецептуры, из-за большого количества итераций может занимать несколько месяцев. Количество итераций может насчитывать десятки или сотни, что не позволяет достоверно прогнозировать сроки. В результате проекты превышают плановые сроки в среднем более чем на два месяца, а иногда зависают на несколько лет.
Для бизнеса компании крайне важно регулярно и своевременно пополнять свой ассортиментный портфель новыми продуктами. Это позволит новым продуктам оказаться на полках магазинов к сезону и увеличить продажи.
Топ-менеджмент контролирует выполнение проектов на периодических комитетах либо выборочно. Проблемы на проектах решаются преимущественно в момент возникновения, когда потенциальные риски и угрозы срокам и результатам проектов уже реализовались. Некоторые проекты тянутся по несколько лет безрезультатно, и прогнозные сроки их завершения продолжают вызывать сомнения у участников и руководства.
Топ-менеджмент видит регулярный срыв сроков проектов, но не всегда понимает первопричину. Основными причинами срыва сроков считаются:
- нехватка ресурсов функциональных подразделений,
- недостаток лидерства руководителей проектов,
- недостаточная четкость организации работ со стороны руководителей проектов.
Руководство признает, что проблема носит системный характер, и поддерживает внедрение единых процессов управления проектами и создание необходимой ИТ-инфраструктуры в организации в целом.
Исходные условия
- В компании недавно согласован процесс разработки новых продуктов
- Планы и отклонения от них фиксируются в презентациях [дорожная карта], которая обновляется только по запросу топ-менеджмента, либо к проектным или продуктовым комитетам
- Задачи проектов ведутся в виде таблиц, со сроками и ответственными.
Информация не всегда своевременно обновляется руководителями проектов. - Заказчик на момент старта проекта уже выбрал систему для управления задачами Atlassian Jira, которую планировал использовать для управления проектами запуска новых продуктов (NPD) и другими проектами, в том числе для управления процессами.
Бизнес-задачи
Клиенту важно выводить на рынок к сезону требуемое количество новых ассортиментных позиций (SKU) каждой продуктовой категории, сокращать сроки вывода продуктов на 30-50%, при этом не жертвуя качеством продукта.Задачи, которые ставил заказчик перед своим проектным офисом и консультантами
Построить и внедрить такую систему управления проектами, которая позволяет реализовывать приоритетные проекты в требуемые сроки, несмотря на высокий уровень неопределенности на исследовательском этапе (Рис.1). При этом она должна обеспечить:
- Реалистичное прогнозирование сроков, в том числе:
- учитывать прогнозные сроки реализации проектов при их приоритизации;
- пересматривать прогнозные сроки проекта с учетом актуальных прогнозов участников команды, добиться онлайн-прогнозирования сроков по проектам.
- Вовлечь в активную работу всех участников проектов, в том числе:
- четко разделять ответственность за ключевые результаты проектов между членами команд, но не вынуждать руководителя проекта детализировать планы до мельчайших действий;
- вовлечь функциональных руководителей в работу над проектами. Они должны отвечать за результаты проекта в своей части так же, как и их сотрудники, делегированные в проект.
- Своевременно выявлять отклонения, реагировать на проблемы и риски, в том числе:
- обеспечивать объективный контроль за происходящими изменениями в проектах для своевременного подключения руководителя проекта, функциональных руководителей;
- создавать условия для своевременной фиксации и решения возникающих проблем и рисков;
- эскалировать критичные отклонения на уровень руководства как можно раньше.
- Систематизировать проектную коммуникацию для снижения зависимости от конкретного исполнителя или руководителя проекта, в том числе с помощью ИТ-инструментов;
- Видеть адекватную картину загрузки по проекту, на каких проектах и кто из их сотрудников загружен, что поможет обещать реальные сроки и расшивать «узкие места» по ресурсам.
Рис.1 Задачи проекта по настройке проектного управления по участникам
Цели пилотного проекта
- Отработать новый подход к оперативному управлению проектами на уровне руководителя проекта и команды, включая
- разработку, создание и актуализацию календарного плана в Jira,
- закрепление ответственности за конкретными исполнителями,
- проведение регулярных планерок команды с использованием Jira,
- управление проблемами, фиксация и решение открытых вопросов с использованием ИТ-системы,
- ежедневную отчетность о выполненных задачах и прогнозирование сроков по текущим задачам и проекту в целом,
- оперативный контроль задач на командной доске проекта (на 1-2 недели вперед),
- эскалацию проблем командой на руководителя проекта,
- управление проектами по отклонениям вех от согласованных сроков.
Далее – подготовка портфельной отчетности и проведение совещаний руководства для разбора проблем и ключевых отклонений, принятия необходимых управленческих решений.
Пилотная зона – 4 проекта, находящихся в активной фазе с датой прогнозного запуска в течение 6 месяцев. Далее планируется тиражирование на весь портфель NPD и другие портфели проектов компании.
Решение
Мы предложили клиенту использовать элементы гибридного метода управления, который позволяет объединить высокую степень контроля за сроками и рисками на уровне руководства, вовлеченность, гибкость и ориентацию на результат на уровне команды.
Такой эффект становится возможен, если синхронизировать различные уровни управления, скоординировать работу всех участников – руководства, руководителей проектов и команд, в том числе с помощью ритмичных управленческих совещаний, согласованных действий участников проектов и совместной работы в специализированной ИТ-системе.
Управление сроками
В проектах по запуску новых продуктов критично выполнение проектов в срок с учетом ограниченных ресурсов команды и нескольких параллельно выполняемых проектов, в которых участвует каждый член команды.
Но если объективно выявлен дефицит ресурсов, то могли быть дополнительно привлечены внешние эксперты с рынка или произведена ротация внутри компании. Главное, чтобы запрос на ресурсы был обоснованным и своевременным.
Перед консультантами была поставлена задача обеспечить контролируемость сроков запущенных проектов по вехам, возможность на всех уровнях управления видеть и реагировать на существенные отклонения.
В качестве основы для разработки плана запуска новых продуктов был выбран ранее описанный и согласованный процесс, который был доработан в рамках консалтингового проекта с учетом специфики конкретных проектов и текущего состояния работ. Можно сказать, что план этот крупноблочный (по сути, структура продуктов проекта, product breakdown structure), не детализированный до атомарных действий команды и от проекта к проекту он несущественно изменяется.
Рис.2 Календарно-сетевая модель проекта с вехами
Например, задача закупки сырья и материалов требовала широкого набора действий, но на уровне плана данная вариативность не отражалась, кроме ситуаций, когда необходимо отследить закупку отдельной важной позиции с длинным сроком поставки или проблемным поставщиком.
Сформированный план учитывал взаимосвязи работ и представлял собой календарно-сетевую модель, которая создавалась и актуализировалась в Jira. Как только план проекта был сформирован, исполнителям стали понятны блоки работ, а руководству — вехи проекта и необходимые ресурсы. После этого план по вехам был утвержден топ-менеджментом.
Вехи утвержденного плана проекта сохранялись в качестве базового плана проекта в Jira, что позволило в автоматическом режиме проконтролировать отклонения прогнозных или фактических сроков вех или проекта в целом от согласованного плана. Каждая веха показывала выполнение определенного блока работ. Некоторые вехи проекта были связаны между собой технологически, например, успешное прохождение тестов рецептуры и производство пилотной партии. Поэтому фактическое или прогнозное отставание выбранного блока работ приводило к изменению прогнозных сроков следующих блоков работ и проекта в целом.
Но может ли в принципе руководитель проекта своевременно обновлять план, особенно если над проектом работает большая распределенная команда представителей из разных подразделений, в том числе находящихся в разных городах? В нашем случае у руководителя проектов с учетом загрузки в 5-10 параллельных проектов не хватало времени на полное, регулярное и своевременное обновление плана. А если планы своевременно не обновляются и отклонения не видны, то и решения руководителя проектов, функциональных и высших руководителей оказывались запоздалыми.
Отслеживание выполняемой работы
Как же организовать работу команды проекта и отслеживать сроки в реальном времени? В идеале руководитель проекта предоставляет объективную и понятную информацию топ-менеджменту. Для того, чтобы данной информацией располагал руководитель проектов, необходимо было организовать систему управления задачами команды и своевременную отчетность по ним.
В данном проекте мы решили уйти от часто возникающего «экранирования» информации о ходе проекта со стороны руководителя проекта, который подает ежемесячный отчет о состоянии проекта, во многом отражающий его личное мнение, либо пускает отчет по цепочке согласований, после чего он становится полностью «зеленым» и малоинформативным. Каждый член команды отчитывается по своим работам, фиксируя как то, что уже выполнено, так и корректируя прогнозные сроки по задачам, которые пока еще выполняются. В случае, если необходимо сдвинуть прогнозный срок, каждый член команды должен был указать причину отклонения.
Такой подход к прогнозированию позволил держать руководителя проекта постоянно в тонусе по поводу изменений в проекте, так как его бездействие быстро приведет к необратимым отклонениям.
Таким образом, наш подход позволил в реальном времени прогнозировать сроки завершения проекта и реагировать на потенциальные отклонения до того, как отставание от графика станет неуправляемым (Рис.3).
Так мы реализовали управление сроками проекта и отклонениями от них:
Рис.3 Отслеживание календарного плана
Это важный, но не единственный элемент гибридной модели управления, который был внедрен в организации.
Организация работы исполнителей
Команде проекта недостаточно просто поддерживать актуальность плана проекта и управлять отклонениями — команде также необходимо было спланировать и организовать свою работу и работу своих подчиненных, если они сами являются лидерами команд.
То есть члены команд проектов могли детализировать планы работ до необходимой степени, чтобы организовать работу на своем участке. Планы по исполнителям (кроме членов проектной команды) не включались в общий план проекта, чтобы сохранить понятность плана проекта для руководства, руководителя проекта и всех членов команды. При этом никаких единых жестких требований к уровню детализации планов не было введено, лишь бы сроки проекта в целом были бы соблюдены.
Данный подход позволил одновременно сохранить контроль над получением требуемых промежуточных и финальных результатов в заданные сроки и при этом децентрализовать планирование на отдельных участках работы проекта.
Оперативное планирование работы
Один из инструментов, применяемых в Agile-методах — визуальная доска (канбан-доска) проекта — помогает наглядно отобразить задачи команды на ближайшую перспективу – 1-2 недели (спринт). Но, если вы не можете посадить всех членов проектных команд компактно и количество параллельных проектов исчисляется десятками, то физические доски – не вариант. Мы предложили использовать электронные доски, формируемые в ИТ-системе на основании задач и вех проекта (Рис.4).
Мы настроили такие доски для всех команд пилотных проектов, которые позволили руководителю проекта и команде в любой момент времени понимать, какие задачи нужно оперативно завершать, какие проблемы, вопросы и препятствия существуют, и какие задачи необходимо стартовать. Данные доски также используются руководителем проекта и командой для планирования ближайшего спринта (1-2 недели) на регулярной планерке команды.
На доску проекта попадают задачи с горизонтом старта 1-2 недели из календарного плана, находящиеся в работе или завершенные, а также мероприятия, о которых договорилась команда.
Рис. 4 Пример канбан-доски для команды
Работа с проблемами и открытыми вопросами
План со сроками и зависимостями между блоками работ и ритмичное еженедельное или ежедневное отслеживание хода работ мотивирует команду заранее сообщать о тех проблемах и открытых вопросах, которые мешают выполнению конкретных вех, да и всего проекта в срок.
Для того, чтобы структурировать выявление и обсуждение данных проблем, была разработана система флагов в ИТ-системе, подсвечивающая проблемы, препятствующие дальнейшему выполнению конкретной задачи, и открытые вопросы, требующие решения. Данные флаги также отражались на электронной доске проекта. Руководитель ежедневно и еженедельно разбирал поднятые проблемы и открытые вопросы, помогал их разрешить и, при необходимости, выносил их на более высокое руководство.
Координация работы команды
Еженедельная планерка
РП и команда проекта еженедельно (иногда раз в две недели) проводил планерки и обсуждал план проекта по вехам — отклонения от первоначальных сроков, разбирал проблемы и открытые вопросы, разрабатывал стратегии реагирования на текущую ситуацию и формулировал риски, проблемы и вопросы для эскалации. В случае серьезных отклонений от плана организовывал отдельное обсуждение с теми членами команды, которых они касаются (Рис. 5).
Рис. 5. Пример плана проекта по вехам с отклонениями
После разбора плана проекта по вехам команда планировала оперативные задачи на одну-две недели вперед на электронной доске. При этом длительность горизонта планирования зависела от частоты проведения планерок. Рекомендуемая частота – неделя, но период мог доходить до двух недель. Самое важное, чтобы горизонт планирования был синхронизирован с частотой планерок, в противном случае возникали ситуации, когда о проблемах и отклонениях сроков руководитель проекта узнавал слишком поздно.
Ежедневная синхронизация
После планерки исполнители ежедневно работали в ИТ-системе: обновляли статусы по своим задачам, уточняли прогнозы по срокам завершения, отмечали проблемы и открытые вопросы. Задачи контролировались и перемещались командой на общей электронной доске проекта. Коммуникация по задачам также осуществлялись с использованием ИТ-платформы, а не
в электронной почте или по телефону, что, конечно же, не умаляет необходимость в личном общении.
Контроль за состоянием портфеля
Контроль за состоянием портфеля должен был осуществляться на проектных комитетах с частотой не реже раза в месяц. Для этого в ИТ-системе предусмотрены дорожные карты и отчеты по вехам, позволяющие видеть ключевые события проекта и отклонения сроков их выполнения (Рис.6).
Рис. 6. Пример дорожной карты
Индивидуальная отчетность
У каждого из участников проекта был настроен персональный дэшборд, на котором можно было видеть ключевые вехи и задачи, наличие открытых вопросов и проблем, фактические и прогнозные отклонения.
У функциональных руководителей, чьи сотрудники участвуют в проектах, были настроены специализированные дэшборды, показывающие ключевые вехи в их зоне ответственности, отклонения сроков по задачам подразделения, а также другие задачи подразделения, требующие отслеживания.
Компоненты ИТ-системы
В качестве ИТ-платформы был выбран таск-трекер Atlassian Jira. Данная платформа также использовалась для автоматизации бизнес-процессов функциональных подразделений.
В качестве инструмента календарно-сетевого планирования использован ряд надстроек, которые были настроены вместе с Jira для упомянутых выше задач. По сути они позволяют дать альтернативное представление и инструмент для работы с теми же задачами, что ведутся в Jira.
Отчетность была построена на стандартных дэшбордах Jira.
Реализация управления по отклонениям
У каждой задачи в плане был настроен индикатор отклонения от базового плана. В зависимости от величины отклонения индикатор загорается желтым или красным.
В плане проекта некоторые задачи были связаны с вехами. После изменения срока таких задачах, изменялся срок у зависимой вехи и включался ее светофор. Причем для разных уровней контроля (проект, веха, задача) настраивались различные допустимые отклонения, которые приводили к изменению цвета светофора. Для более низких уровней они были жестче, чем для более высоких.
Что компания получила от такой модели управления?
- Ориентацию команд на результат – вся команда в курсе целей и влияния своих действий на итоговый результат проекта.
- Прозрачность – вся информация по проекту доступна любому члену команды и руководству в реальном времени.
- Слаженность – планерки, а также другие мероприятия и действия обеспечили слаженную работу команды и руководства.
- Проактивность – команда и руководство смогли видеть отклонения, проблемы, риски и перегрузку заранее.
- Ответственность – участники проектов знают, что и к какому сроку они должны сделать. Полностью исключены комментарии «А что, это я должен был сделать?».
На данный момент четыре продуктовых проекта компании ведутся по новой методологии с использованием созданных ИТ-инструментов, постепенно осуществляется тиражирование на другие проекты. О бизнес-результатах говорить рано, это будет понятно после тиражирования подхода на весь портфель продуктовых проектов компании и его стабильной работы на горизонте 6-12 месяцев.