Автор: Кира Бурма, директор по внедрению ERP-систем, департамент платформенных решений Axellect
Ключевая роль грамотного планирования в управлении проектами очевидна. Однако далеко не все руководители уделяют ему должное внимание. Объясняем, почему такое пренебрежение – путь к провалу с гарантией почти в 100%, и даем методику, как держать все под контролем и придерживаться первоначальных сроков.
Есть план?
Подтвержденная годами практики аксиома, с которой хотелось бы начать разговор: в центре успешного проектного менеджмента всегда лежит качественное планирование работы – и точка. Планирование в project management (PM) — это фундаментальный элемент для бюджетного контроля и достижения порядка в проекте на всех его уровнях, а также критически важный элемент для управления и контроля со стороны CEO.
Первая ошибка, которую чаще всего допускают, это использование только дорожной карты (Roadmap) без детального операционного плана. Поэтому предлагаем начать разговор с терминологии, что есть что?
- Дорожная карта (Roadmap): представляет общую структуру проекта в качестве стратегического инструмента. Дает высокоуровневое представление – ключевые этапы, основные цели и вехи. Roadmap обычно ориентирован на долгосрочные цели и может охватывать месяцы или даже годы.
«Дорожная карта» может адаптироваться к изменениям в условиях рынка, стратегии компании или приоритетах проекта. Также это коммуникационный инструмент, который можно предоставить заинтересованным сторонам, если те захотят получить общее представление о направлении работы;
- Оперативный план: более детальное планирование, ключ к рутинному ежедневному управлению. Это тактический инструмент, он фокусируется на конкретных задачах и действиях, необходимых для достижения целей, указанных в roadmap. Обычно охватывает более короткие периоды времени - недели или месяцы. Оперативный план гораздо детализированнее, чем Roadmap, и включает в себя конкретные задачи, сроки и ответственных лиц. Он также используется для управления ежедневными операциями проекта и для контроля за его прогрессом.
Выбор инструмента для создания оперативного плана зависит от предпочтений и нужд команды. Microsoft Project является специализированным инструментом в этом сегменте, но многие предпочитают простоту и доступность Excel.
Однако независимо от выбора программного решения важна наглядность – для этого хорошо подойдут детализированные диаграммы Ганта, которые включают в себя список задач на разных уровнях и позволят визуально отмечать их разными цветами для простоты. С таким подходом легче отслеживать прогресс работы и налаживать сотрудничество между различными членами команды, включая программистов, юристов, финансистов и других.
Детализация карты и оперплана
Подытожим: roadmap проекта можно рассматривать как карту, показывающую направление и основные этапы пути, в то время как оперативный план - подробный маршрут, описывающий каждый его шаг.
Рабочий день хорошего проектного менеджера, который нацелен на результат, начинается с анализа оперативного плана. Он регулярно проводит собрания (планерки), на которых все участники могут сверить часы – какие задачи стоят на текущей неделе, кто не достиг поставленных целей за минувшие семь дней и т.д. Все это важно анализировать для контроля за продвижением проекта и сроками его завершения. Грамотное распределение и управление задачами в рамках оперативного плана составляют до 70% успеха в проекте.
При этом проектные работы часто идут не строго последовательно, а параллельно друг другу. Например, если один из потоков проекта (финансовый) завершает сбор требований, он может начать следующий этап (реализацию), в то время как другие потоки все еще заняты на проектировании.
Но так происходит не всегда. В некоторых случаях синхронный подход критически важен для достижения успеха – например, невозможно приступить к тестированию, если продукт готов, но сбор данных еще не закончен. Грамотный проектный менеджер может предвидеть эти ситуации и запланировать старт каждого из этапов в нужный по времени момент, рассчитав силы и возможности, имеющиеся у его команды.
Именно поэтому оперативный план должен быть разбит минимум на три уровня задач. Приведу пример из ИТ.
На первом уровне фазы проектирования решаются такие задачи, как сбор требований, определение концептуального дизайна, создание общей архитектурной диаграммы и планирование подходов для последующих этапов.
Для того, чтобы верхнеуровневая задача по сбору требований к продукту завершилась успешно, необходимо организовать встречи (воркшопы) с командой заказчика, написать и согласовать документацию. Это – второй уровень задачи по сбору требований, на прохождение которого может уйти от нескольких недель до месяцев, в зависимости от объема и сложности задач.
На третьем уровне происходит еще более детальная разбивка – по функциональным областям. Например, при планировании воркшопов по Supply Chain (цепочке поставок) необходимо учитывать взаимосвязь с финансовым аспектом проекта, так как требования могут не совпадать с бюджетными возможностями.
Добавим, что адекватный бюджет проекта тоже напрямую зависит от умения проектного менеджера работать с планом и дорожной картой. Бюджет – это отражение оперативного плана в цифрах, включая распределение ресурсов и персонала. Накладывая на оперплан требования в ресурсах, в том числе в людских, проектный менеджер получает взвешенный реалистичный финансовый документ, который не потребует пересмотра в процессе реализации.
На фото Кира Бурма
Подходы к разработке операционного плана
Многолетний опыт в проектном менеджменте показывает, что многие менеджеры, особенно со стороны клиента, сталкиваются с трудностями в ежедневном планировании, а кто-то и вовсе игнорирует этот процесс, что неудивительно.
Сопротивление часто вызвано страхом постоянного контроля и необходимостью регулярной демонстрации результатов. Однако я уверена, что без строгой дисциплины невозможно эффективно управлять проектом, а главное – оперативно корректировать его с учетом допущенных ошибок или сбоев.
Существуют две основные методики для разработки оперативного плана: нисходящая и восходящая. Обе они заимствованы из практик проектирования ПО в ИТ-отрасли.
1. Нисходящее проектирование исходит из общих этапов проекта, указанных в дорожной карте. План, детализируясь, разворачивается вниз. Этот метод позволяет сохранять в голове общую картину и обеспечивает стратегический контроль над проектом.
2. Восходящее проектирование начинается с мелких задач и постепенно объединяет их в более крупные цели. Этот подход часто используется в условиях применения Agile-методологий и подходит для малых проектов в таких сферах, как телеком или банковские услуги, где требования формируются по ходу дела.
Для крупных проектов и программ обычно более эффективен нисходящий подход. Особое внимание стоит уделить зависимостям и ключевым этапам (Mile Stones), так как именно они часто определяют успех проекта. Например, для тестирования программы необходимо не только настроить саму систему, но и предварительно подготовить тестовые данные. Пользователи ожидают от системы готовности к полноценной работе сразу. Это означает, что система должна быть не только технически настроена, но и наполнена необходимой информацией – от списка поставщиков и клиентов до банковских счетов.
Таким образом, задачи по подготовке данных и разработке инструментов для их загрузки должны быть выполнены заранее.
Этот пример показывает, как важно учитывать зависимости между этапами проекта. Если система не установлена вовремя – нет возможности загрузить данные, это приведет к задержкам на этапе тестирования. Задержка на одном этапе может сдвинуть сроки реализации всего проекта на несколько месяцев.
Кроме того, понимание сроков для запуска очередного этапа проекта важно, чтобы грамотно распределить нагрузку на членов команды. В нее чаще всего входят не люди со стороны, для которых проект становится основной деятельностью, а уже работающие в компании профессионалы, с которых никто не снимает основную нагрузку. Поэтому, к примеру, для главного бухгалтера важно понимать, когда его компетенции потребуются на проекте, чтобы распределить свою основную нагрузку на коллег.
Прозрачность - это важно
Для руководителя или заказчика проекта очень важно видеть регулярный прогресс и результаты. Так он будет представлять картину происходящего. Если мы говорим об IТ-проектах, то представить промежуточный результат будет непросто - собранные требования в виде длинных списков могут быть неинформативны и не впечатлят заказчика, которому в реальности некогда разбираться в этих подготовительных таблицах и графиках.
Однако отчеты о прогрессе – ключевой инструмент коммуникации с заказчиками и топ-менеджментом. Часто проектный менеджер демонстрирует заказчику дорожную карту, растянутую на несколько месяцев. Но, как мы уже отмечали, этот документ слишком общий и в реальности не может эффективно показать текущий прогресс в деталях.
Иначе обстоит дело с оперативным планом. Он позволяет не только отслеживать выполнение задач, но и делать наиболее реалистичные прогнозы о сроках конца работ, а также в случае задержек понимать и объяснять их причины. Это покажет профессионализм проектного менеджера, который разбирается во всех деталях проекта и обладает полным контролем за всем, что происходит. Еще более иллюстративным и понятным план станет, если каждый его этап (задачу) дополнить подсчетом требований необходимых ресурсов и их балансировки. Но это тема, которая требует отдельного рассмотрения.
Добавлю еще одно правило, которое лично я советую соблюдать при ведении любого проекта. Очень важно сохранять визуализацию первоначального плана, даже при его дальнейшей корректировке, которую лучше отмечать разными цветами. Это помогает ясно видеть, где и почему произошли отклонения от первоначального планирования и сроков.
К сожалению, многие менеджеры избегают такого подхода, так как не хотят выставлять на показ свои ошибки. Однако их признание и анализ – неотъемлемая часть успешного и профессионального управления проектом. Необходимо помнить, что технические ошибки в проектах часто исправимы, но сложности с управлением приведут в тупик даже при наличии всех необходимых ресурсов. Не ошибается только тот, кто не работает.
