Кейс внедрения гибридного управления с применением ИТ-платформы. Часть 2

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

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

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

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

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

Один из инструментов, применяемых в Agile-методах — визуальная доска (канбан-доска) проекта — помогает наглядно отобразить задачи команды на ближайшую перспективу – 1-2 недели (спринт). Но, если вы не можете посадить всех членов проектных команд компактно и количество параллельных проектов исчисляется десятками, то физические доски – не вариант. Мы предложили использовать электронные доски, формируемые в ИТ-системе на основании задач и вех проекта (Рис.4).

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

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

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

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

Еженедельная планерка

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

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

Ежедневная синхронизация

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

Контроль за состоянием портфеля должен был осуществляться на проектных комитетах с частотой не реже раза в месяц. Для этого в ИТ-системе предусмотрены дорожные карты и отчеты по вехам, позволяющие видеть ключевые события проекта и отклонения сроков их выполнения (Рис.6).

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

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

В качестве ИТ-платформы был выбран таск-трекер Atlassian Jira. Данная платформа также использовалась для автоматизации бизнес-процессов функциональных подразделений.

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

У каждой задачи в плане был настроен индикатор отклонения от базового плана. В зависимости от величины отклонения индикатор загорается желтым или красным.

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

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