Статьи

Home › News

Как правильно прописать план управления проектом?

29.08.2018

Планирование — фундамент, на котором строится любой проект. И чем он крепче, тем больше вероятности, что проект будет успешным. Для этого и существует project management plan, состоящий из трех блоков: активностей (целей, концепции проекта, ресурсные предназначения и т.д.), задач и ресурсов (люди, оборудование, деньги и т.д.).

Что такое план управления проектом?

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

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

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

Обычно в проекте задействовано два плана управления:

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

Для чего он нужен?

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

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

Веха (milestone) — контрольная точка в ходе проекта (например, переход к новой итерации).

Задачи Project Management Plan такие:

координация действий участников  — к ним относятся не только непосредственно проектная команда, но и стейкхолдеры. Чем масштабнее проект, тем сложнее наладить рабочий процесс. отслеживание статуса выполнения проекта  — если в традиционном менеджменте существует жесткая последовательность этапов, то в проектном менеджменте чаще используются разновидности Agile-модели, где проект разбивается на маленькие рабочие кусочки. четкое понимание каждым участником своего места в проекте  — этого, кстати, не хватало программисту Рику из  вирусной статьи «Мы уволили нашего ТОП-таланта. Лучшее решение, которое приняли». поиск проблемных мест проекта до фазы активной разработки  — долгосрочные проекты больше всех страдают от этой «болячки». В Agile-концепции проблема частично решается постоянным тестированием и поиском уязвимых мест для дальнейшего исправления.

Ключевые составляющие плана управления проектом

Составлять планы управления проектами по одному шаблону не получится, но существует набор базовых элементов, зная которые, легко построить каркас будущего проекта:

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

PBS (product breakdown structure) — инструмент для анализа, документирования и передачи результатов проекта. PBS — часть методики планирования на основе продукта (один из главных методов в модели проектного менеджмента PRINCE2).

WBS (work breakdown structure) — иерархическая разбивка проектной работы на более мелкие задачи (операции) до того уровня, когда понятны способы выполнения работ, есть возможность оценки и планирования.

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

Список разделов плана дополняется в зависимости от особенностей конкретного проекта.

Базовый и рабочий планы проекта

Во время работы над проектом проектный менеджер, участники команды и  стейкхолдеры работают с двумя видами планов:

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

В ходе развития проекта можно сравнить базовый и рабочий планы, понять, где «провисает» работа, а где наоборот — выполнение проекта идет быстрее (экономнее) задуманного. В редких случаях изменения по ходу проекта вносятся в базовый план управления .

В Worksection диаграмма Ганта позволяет увидеть разницу межу базовым и рабочим планом

(синее — общее время, красное — просроченные задачи, зеленое — вовремя завершенные задачи)

Разработка плана управления проектом

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

Мы сконструировали простую пошаговую процедуру написания плана, состоящую из 16 пунктов:

Определите стартовые условия разработки плана  — важно понять, с кем вы будете его разрабатывать (один, с участием руководства, стейкхолдеров), где и когда и т.п. Важно заранее прописать методики (например, брейншторминг) и программное обеспечение (типа Microsoft Visual Studio), которые будут использоваться в создании плана — это значительно сэкономит время и упростит задачу. Определите стартовые условия проекта  — здесь описывается содержание проекта, список требований к результатам и его управлению. К примеру, задуман проект по продаже качественных неоновых спиннеров с принтами супергероев. В результате успешной реализации годового проекта должно быть продано 100 000 единиц товара за 12 месяцев со старта проекта, после чего пройдет продажа бизнеса. Структура управления проектом будет состоять из генерального проектного менеджера в центральном офисе и соответствующих отделов в региональных представительствах проекта. Разграничьте выполняемые действия на такие, которые будут делаться силами проектной команды, и аутсорсинг. Создайте WBS проекта, разбив его на меньшие управляемые куски. Это похоже на Agile-подход, когда полный код делится на много маленьких рабочих кусков. Пропишите набор задач для выполнения каждой части WBS и постройте зависимость между ними. Так, задача покупки и обустройства регионального склада для хранения спиннеров может быть выполнена только после анализа рынка и продажи определенного количества товара в конкретной области. Определите необходимые компетенции для выполнения каждой задачи. Здесь важно не подгонять требуемые знания и навыки под потенциальных участников проекта, а сосредоточиться на «идеальных» требованиях. Оцените временные и денежные затраты на выполнение задач. Разработайте критический путь проекта. Методика хороша как раз для продуктового бизнеса, и её легко отобразить через схемы (например, диаграмму Ганта). Создайте календарный план проекта  — начальная, промежуточные, конечная даты. К примеру, упрощенная схема: 1 ноября запускается проект, 1 декабря — старт продаж к Новому году, 31 декабря — подведение итогов новогодних продаж, 15 января — запуск специализированной линейки ко Дню святого Валентина, 20 февраля — подведение итогов и т.д. Рассчитайте стоимость проекта (в нашем случае — во сколько обойдется успешная реализация 100 000 спиннеров и продажа бизнеса). Уточните требования к качеству (например, прописанные стандарты качества изготовления спиннеров). Назначьте ответственными конкретных людей на задачи. Здесь вам и пригодится п. 6, со списком которого вы будете связывать компетенции членов команды. Распланируйте формат работы со стейкхолдерами  — подберите каналы связи, определите степень их вовлечения в работу над проектом и т.д. Просчитайте риски (например, по формуле кумулятивного метода). В нашем примере со спиннерами это может быть банальное перенасыщение рынка, нарушение условий договора экспедиторами и т.п. В анализе рисков используйте данные с предыдущих пунктов. Запишите ограничения проекты и с их учетом внесите данные в план управления проектом. В нашем случае детали спиннеров доставляют из Китая, сборка происходит в Украине, а это уже ограничивает возможность жесткого контроля качества материалов и быстрой переналадки. Пройдите еще раз по всем пунктам плана , чтобы достичь дзен. Осталось доработать список закупок и требований к ним, согласовать с заинтересованными лицами — и у вас на руках готовый план управления проектом.

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

Утверждение плана управления проектом

В книге «Хватит платить за все» Владислав Гагарский в качестве примера приводит такую схему утверждения:

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

Но  эта схема больше подходит готовым коллективам , которые выполняют друг за другом несколько проектом или сменили профиль деятельности. Для тех, кто «с нуля» решил написать и утвердить project management plan, методика не подойдет. В таких случаях базовый проект утверждается руководителем компании или проекта (заказчиком) с подачи проектного менеджера.

Советы по созданию плана управления проектами:

оформите план в материальном виде  — неважно, будет это сделано на бумаге или в специальном ПО. Даже самый мелкий нюанс должен быть прописан, в противном случае — ждите проблем с коммуникацией между участниками и стейкхолдерами. привлеките к созданию плана стейкхолдеров  — наладив коммуникации с ними, вы избежите проблем с выработкой единого видения проекта и ожидаемых результатов. организуйте систему документооборота  — проекты генерируют огромное количество документов: первичные концепции, идеи, эскизы, презентации, планы управления рисками, диаграмма критического пути и т.п. Они попадают в базовый и рабочий планы управления проектом. Для удобного доступа и быстрой актуализации нужна четкая система организации документов. исследуйте детали перед разработкой плана  — перефразируя Остапа Бендера из «Двенадцати стульев: «Утром исследование, вечером — план. Или вечером — план, утром — исследование».

Изучите ожидания клиентов, участников проекта, предполагаемые цели проекта, методики, которые стоит применить при разработке плана управления проектом. Такая предварительная работа сократит временные затраты и главное — минимизирует количество ошибок в project management plan. поговорите с командой перед стартом  — так вы актуализируете знания о компетенциях сотрудников, поймете заинтересованность в будущем проекте. Не зря один из принципов Agile-манифеста : "Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана... доверьтесь им".

Вердикт

План управления проектом — не  палочка-выручалочка.

Он будет декларацией изначально без инструментов по его внедрению. Инструментом же может стать Worksection с его проектами/задачами/подзадачами и учетом денег, времени и ответственных прямо в задачах. Это оптимальный способ организовать наглядную работу компании, где связь между базовым и рабочим планами очевидна всем.

Но план  — это тот старт, который определит 50% успешности проекта.