План работы руководства проектом

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

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

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

1. старт
2. планирование
3. выполнение
4. мониторинг выполнения
5. завершение.

В создании project management plan участвуют проектный менеджер, команда проекта и ключевые стейкхолдеры — люди и организации, которые влияют на проект: инвестор, заказчик, акционеры.

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

Из чего состоит план управления проектом?

В начале указывают резюме плана и краткое описание:

• в резюме описывают цели, ожидаемые результаты, проблему проекта и её решение;
• в кратком описании плана описывают ключевые элементы проекта, которые подробно раскрываются в плане управления проектом.

В project management plan входят три базовых плана:

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

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

В Worksection диаграмма Ганта показывает разницу между базовым и рабочим планом. Так, границы проекта в базовом плане отмечены синим цветом, а вовремя завершенные и просроченные задачи в рабочем плане — зеленым и красным соответственно.

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

В рабочем плане управления жизненным циклом проекта определяют, как долго продлится проект. Это легко сделать при работе по методологии Waterfall, в которой фазы проекта идут в четкой последовательности. А вот в Agile не получится спланировать проект от начала и до конца. Так, ретроспектива в первом спринте Scrum приведет к изменению планированию в другом спринте.

1. Определите стартовые условия разработки плана.
   Определите, с кем вы будете разрабатывать план, где и когда. Также пропишите методики (например, брейншторминг) и программы для планирования проекта (Worksection, Microsoft Visual Studio), которые будете использовать.

   

2. Определите стартовые условия проекта.
   Опишите содержание проекта, список требований к управлению и результатам проекта. К примеру, вы хотите запустить годовой проект по продаже неоновых спиннеров с принтами супергероев. Успех проекта подразумевает продажу 100 тысяч единиц товара за 12 месяцев со старта проекта, после чего проект будет завершен.

   
3. Определите, какие задачи будет выполнять проектная команда, а какие вы отдадите на аутсорс.
   Поговорите с командой перед стартом — так вы лучше поймете компетенции и заинтересованность участников в будущем проекте. В Agile-манифесте справедливо отмечено: «Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана… доверьтесь им».

   

4. Выстройте иерархическую структуру работ (WBS), разбив проект на меньшие куски.
   WBS — это деление проекта на конкретные результаты для достижения целей проекта. Например, в проекте неоновых спиннеров один из крупных элементов WBS — «Купленный и обустроенный склад». Он включает в себя несколько элементов-результатов: «Согласованные стоимость и сроки передачи», «Посещенные 10 потенциальных объектов», «Разработанная система логистики», «Заключенный договор».

   

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

   

6. Определите необходимые компетенции для выполнения каждой задачи.
   Сосредоточьтесь на «идеальных» для задач требованиях, чтобы не начать подгонять требуемые знания и навыки под потенциальных участников проекта.
7. Оцените, сколько времени и денег вы потратите на выполнение задач.
   

   

   
   

8. Разработайте критический путь проекта.
   Методика критического пути хороша для продуктового бизнеса. В Worksection критический путь можно построить через диаграмму Ганта.

   

9. Создайте календарный план проекта.
   Отметьте начальную, промежуточные и конечную даты. Например, начальная дата — 1 ноября, запуск проекта, 1 декабря, 31 декабря, 15 января — промежуточные даты продаж в честь праздников, 20 февраля — конечная дата, подведение итогов.

   

10. Рассчитайте стоимость проекта.
11. Уточните требования к качеству. Каким стандартам качества должны отвечать изготовленные спиннеры? Какие условия хранения должны быть на складах, чтобы принты на спиннерах не отслаивались, а краска — не слезала?
12. Назначьте ответственных по задачам.
    
    
13. Определите, как вы будете работать с ключевыми стейкхолдерами.
    Подберите каналы связи и определите степень вовлечения стейкхолдеров в работу над проектом. Будет ли инвестор влиять на ассортимент принтов и цвет спиннеров? Смогут ли акционеры добиться досрочного завершения проекта в случае его неудачи в первые 3 месяца? Наладив коммуникации со стейкхолдерами, вы сможете выработать единое видение проекта.
    

    

    
    
    

14. Просчитайте риски.
    В примере со спиннерами это может быть перенасыщение рынка, судебный иск о нарушении авторских прав, нарушение поставщиком условий договора. Анализируя риски, используйте данные с предыдущих пунктов.
15. Запишите ограничения проекта.
    Детали спиннеров доставляют из Китая, которые собирают в Украине. Такая схема ограничивает возможность жестко контролировать качество материалов и быстро переналадить производство в случае брака.
16. Проверьте все пункты плана.
    Что вы упустили, а что оказалось лишним? Доработайте список закупок и согласуйте план со стейкхолдерами — у вас на руках готовый план управления проектом!

5 вопросов для проверки плана управления проектом

1. Почему? Какую проблему решает проект, в чем его ценность?
2. Что? Какие главные результаты (deliverables) проекта? Что сделать для его успешного завершения?
3. Кто? Кто работает над проектом и за что отвечает каждый из участников проектной команды?
4. Когда? Когда проект начнется и закончится? Когда будут достигнуты контрольные точки (milestones)?

Как управлять проектом? Самый простой пошаговый план для новичков

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

Совсем немного введения

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

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

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

Для полноценного проектирования и детализации требований продукта необходимо подготовить следующее:

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

• Прототипы дизайна, где в общем виду показать какая информация будет размещаться на основных экранах

• Смета проекта, где указаны все виды работ на проекте и их оценка в человеко-часах или в днях, а также стоимость проекта

Из второстепенных материалов:

• Роадмап проекта, где указываем календарный план работ и майлстоуны

• Устав, который часто разрабатывается вместе с контрактом на этапе инициации и где указываем правила работы над проектом (полезная вещь, особенно в неопытных командах)

Ниже я буду описывать процесс работы над проектом, где опишу немного подробнее разработку материалов:

Этап Инициации

На этом этапе идея продукта формируется в виде более подробных требований. Необходимо описать в техническом задании следующее:

• Общая информация о проекте

• Цели проекта

• Целевая аудитория проекта и ее проблемы (потребности), которые будет решать продукт

• Ожидаемые выгоды от проекта (для ЦА)

• Основные функции, которые пользователи смогут выполнять в системе. Составляется в общем виде с базовым описанием. Нужно разбить проект на компоненты, в состав которых может входить несколько функций.

• Основные экраны и информация на них (в текстовом виде), которая составляется на основе требований к функциям из пункта выше.

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

Пример прототипа

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

Пример сметы

Также можно составить Роадмап проекта на этом этапе, где указать календарный план работ и майлстоуны:

Этап Разработки

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

Для каждого компонента системы указывается следующее:

• Список use cases (можно постепенно дополнять use case диаграмму или сразу сделать ее в полном объеме) с описанием каждого use case

• Описание экранов (также можно постепенно составлять схему экранов или карту сайта)

• Дополнительная информация:

  • База данных для компонента (может постепенно дополняться или разрабатываться сразу полностью)

  • Остальные UML-диаграммы

  • Другая информация

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

Этап Запуска

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

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

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

Боевая практика учила: тот, кто застыл в учёбе, отстал или не хочет замечать нового в тактике воздушного боя, тот неизбежно будет бит. И ничто не спасёт его – ни интуиция, ни личная храбрость

кому: собственникам, топ-менеджерам, руководителям

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

Составные задачи и проекты, как пожиратели времени руководителя

Извечный вопрос: “В чём причина высокой загруженности руководителей бесконечным потоком оперативных задач, генерируемых подчинёнными?” Ответ может показаться на первый взгляд неожиданным: одна из причин — отсутствие у руководителя технологии управления составными задачами и проектами. В этом случае очень много времени руководителей тратится на две вещи:

• Тотальный контроль, ибо стоит отпустить задачу в более или менее “свободное плавание”, как она обязательно найдёт свой айсберг.
• Тысяча вопросов по каждому проекту и составной задаче на каждом шаге её выполнения от подчинённого: “Это мы сделали, какое должно быть следующее действие?”, “Мы столкнулись вот с таким препятствием, что делать?”, “Какие важные параметры необходимо учесть для этого действия?” и т.д.

Есть, конечно же, и другие причины высокой загруженности руководителя. Если они вам интересны, рекомендую прочитать статью “Сказка о потерянном времени для руководителей, или Как избежать «возврата обезьянок» и «отфутболивания задач» от подчинённых”

“Золотой ключик” для собственников и топ-менеджеров

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

А вот в несколько раз сократить время на чрезмерный контроль и свою вовлечённость при решении задач подчинённых — это реально. Для собственников и топ-менеджеров это один из “золотых ключиков”, позволяющих открыть выход из ”трясины” оперативных задач и перейти на уровень стратегического развития и управления компанией.

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

Базовые определения, различия между проектами

Различия в проектах будут важны на некоторых этапах “Алгоритма подготовки и управления составной задачей или проектом”. В зависимости от типа проекта может отличаться набор действий в рамках шага алгоритма.

Давая определения, я подразумеваю, что речь идёт о проектах и составных задачах, которые выполняются впервые (в этом и есть сложность, ибо отсутствует регламент выполнения и/или сотрудник, выполнявший эту работу ранее). Ибо при наличии актуального регламента выполнить задачу становится делом техники (если, конечно, в вашей компании внедрён “регулярный менеджмент”).

Проект — это набор связанных единой целью задач, выполнить которые необходимо в рамках ограниченных ресурсов (время, люди, деньги и т.д.). Например, “внедрить CRM” или “запустить контекстную рекламу” — это классические проекты.

Составная задача — это проект небольшого масштаба, своего рода “мини-проект” (как правило, состоит не более чем из 40 задач с планируемой длительностью не более 1,5-2 месяца). Далее там, где употребляется слово “проект”, будет подразумеваться и “составная задача” (т.е. эти понятия будут синонимами), за исключением случаев, когда в тексте есть отдельная оговорка об их разделении.

Отличия между проектами есть. Найдите их, прочитав все определения. И заодно найдите отличия на картинке. Если отсутствует управление проектами, вам часто придётся их искать у своих сотрудников

Уникальный проект — проект, который выполняется с большой долей вероятности единожды. Например, “внедрить систему управления задачами”.

Повторяющийся проект — проект, который с большой вероятностью будет неоднократно повторяться в будущем с небольшими изменениями. “Внедрить CRM” будет повторяющимся проектом, если фирма, где вы работаете — часть группы компаний.

Смешанный проект — частично “уникальный”, частично “повторяющийся” проект. Например, “составить типовой договор для клиентов” будет смешанным проектом. Здесь уникальная часть — суть договора. Повторяющаяся часть — принципы и правила при составлении типовых договоров, которые важно выработать для последующих аналогичных работ.

Внутренний проект — проект, который нацелен на решение внутренних задач компании.

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

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

Прежде чем приступать к работе, если у вас есть вышестоящий руководитель, то задайтесь вопросом: “Какого типа он вам поручил проект?” Для вас это может быть “уникальный проект”, а для него “повторяющийся”.

Алгоритм подготовки и управления составной задачей и проектом

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

Преимущества алгоритма для руководителей

• Значительно увеличивается вероятность успешного выполнения проекта. Без правильно организованной работы результаты носят зачастую негативный оттенок. Например: убытки от проекта и затраты превосходят положительный результат; всё сделано НЕ так как надо; все разругались со всеми; компания НЕ достигает результатов и целей проекта и т.д.
• Колоссальная экономия времени при управлении проектами и составными задачами.
• Возможность наконец-то взяться за многие важные задачи, которые откладывались годами из-за того, что вероятность их положительного завершения была крайне мала.
• Прозрачность: понятно кто, когда и какую работу будет выполнять. С кого спрашивать за итоговые результаты проекта.
• Минимизация рисков, а значит и рост вероятности успешного выполнения задачи.

Преимущества алгоритма для подчинённых/исполнителей

• Меньшая вероятность получить небольшой, а то и крупный проект от руководителя, описанный всего в двух словах (например, “внедрите CRM!”), без каких-либо ресурсов и согласования плана проекта. Ведь заранее понятно, что при делегировании в таком формате, скорее всего, вы будете виноваты, что бы вы ни сделали (и алгоритм выполнения был не тот, и внедрение не так организовали, и результаты неудовлетворительные).
• Ясность в вопросах о том, кто ответственен за координацию исполнителей и за всю работу по проекту.
• Больше возможностей получить положительную оценку за свою работу от руководителя, а это: перспективы карьерного роста, увеличения денежного вознаграждения и т.д.

Теперь практика. Речь о конкретных действиях в рамках пошагового алгоритма подготовки и управления проектом.

1. Назначьте ответственного за проект

Ответственный за проект (руководитель проекта) должен быть в единственном числе. Избавьтесь здесь от “комитетов”, общих собраний, коллегиальных решений и других технологий, “размывающих” ответственность.

Выбирая ответственных за проект, учитывайте их профессиональные и управленческие навыки, а также область ближайшего развития

Например, в одной из компаний регулярно выполнялся проект “отрисовка баннера”. Ответственный должен был утвердить итоговую версию более чем у пятерых человек, по итогам комментариев каждого из которых в баннер должны были вноситься изменения.

Что получилось в итоге? На вопрос руководителя: “Почему в баннере есть вот такая штука?” был получен прогнозируемый ответ “Эту штуку предложил один из тех, кто вносил дополнения”. Поскольку все внесения дополнений обсуждались впятером на трёх собраниях, причём без ведения протокола, то никто не смог вспомнить, кем и когда предложение было внесено. И более того: кто отвечает за его принятие.

Эту штуку предложил один из тех, кто вносил дополнения!

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

Отсюда следует, что выбирая ответственного за проект, необходимо учитывать как его текущую квалификацию, так и область ближайшего развития. Соотнесите их с критичностью качества процесса + результата и сроков выполнения задачи. Взвесив «за» и «против» определите степень участия руководителя проекта на нижеперечисленных подготовительных этапах (возможные варианты: тотальное с выполнением наиболее важных работ, руками сотрудников в целях их обучения, подготовка планов и контроль — остальное делают только исполнители).

2. Определите цели проекта

Важный этап, который, как обычно это бывает, пропускается в порыве быстрее приступить к работам.

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

Смысл всякой деятельности лежит вне ее пределов

На практике это выглядит так. Цель проекта “Внедрение CRM” отличается от “внедрить CRM”, и должна звучать примерно так: “Создать базу данных по клиентам и взаимодействию с ними в формализованном виде для увеличения продаж и снижения персоналозависимости”.

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

3. Зафиксируйте критерии успеха проекта

Классические критерии успеха — это соблюдение и/или допустимые отклонения от ключевых параметров проекта. Достиг ли проект ключевой и дополнительных целей? Выполнен ли проект в назначенный срок и в рамках выделенных изначально ресурсов?

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

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

4. Определите риски и возможности. Продумайте, как предотвратить и реагировать на риски, и как использовать возможности

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

Кто не учитывает риски, тот продолжает тянуть изо всех сил и в ситуации, изображённой на картинке

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

• Внутренние сильные стороны (внутренние факторы, зависящие от компании, которые усиливают вероятность успеха проекта. Ответ на вопрос “в чём сила, брат?”) — относятся к возможностям.
• Внутренние слабые стороны (внутренние факторы со стороны компании/опыта/технологий и т.д., которые “ослабляют” или могут негативно повлиять на проект) — относятся к рискам.
• Внешние сильные стороны (внешние факторы, которые увеличивают вероятность и помогают и/или могут помогать выполнению проекта) — относятся к возможностям. Например, в проекте “внедрение CRM” большая конкуренция на этом рынке позволяет выбрать подрядчика, исходя из соотношения цена/качество, т.е. получить качественную работу без “космических” инвестиций.
• Внешние слабые стороны (внешние факторы по отношению к компании, которые несут риски для проекта) — относятся к рискам. Например, для проекта “внедрение CRM” — это программное обеспечение, для которого сложно найти подрядчиков + отсутствие регулярного и быстрого развития продукта.

Алгоритм работы с рисками

По итогам составления таблицы SWOT-анализа, сначала выпишите последовательно для каждого риска (расположите их по степени критичности и вероятности возникновения):

1. действия, которые должны быть предприняты по минимизации вероятности его наступления;
2. действия, которые планируется выполнить в том случае, если событие всё-таки произойдёт.

Оба пункта включите в план работ по проекту. Но не увлекайтесь, вряд ли руководитель оценит ваш благородный порыв, когда вы ему предоставите десять страниц по отработке риска “внезапный ядерный удар” для проекта “внедрение CRM”.

Алгоритм работы с возможностями

Теперь пришло время для возможностей. Для каждой из них выпишите последовательно (расположите возможности по степени полезности и вероятности их появления):

• действия, которые необходимо выполнить, чтобы воспользоваться и/или увеличить вероятность наступления этой возможности;
• действия, которые планируется сделать, если возможность “откроется”.

Типичная возможность при покупке программного обеспечения (и не только!) — задать вопрос: “Действуют ли сейчас какие-либо акции? Какие акции планируются в ближайшие 2 недели?” Когда будете делать план проекта, дополните его получившимися действиями.

Выводы по итогам SWOT-анализа

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

5. Сделайте подробный план работ по проекту (тотальная декомпозиция)

Кто сказал, что “качество плана определяет на 70% результат работы” я не помню, однако мой опыт показывает справедливость этого изречения. Недаром в заголовке я употребил термин “тотальная декомпозиция”. Подразумевается, что каждый пункт в плане будет расписан так подробно, насколько это возможно. Если есть для какого-то из этапов регламент или принципы выполнения работ, на них обязательно должна быть ссылка рядом с соответствующим пунктом плана работ. Если у вас в компании только планируется внедрение системы регламентов, рекомендую пройти мой мини-курс «Мастер регламентов».

Также обязательно у каждой задачи указывайте ответственного за её выполнение (помните, что спрашивать результат будут всё равно с руководителя проекта!) + время, которое планируется затратить на выполнение этой задачи. Более подробно о требованиях к задачам в планах читайте в статье “Ежедневный план: Как организовать, чтобы сотрудники сами планировали свой рабочий день (версия 2.0)”.

Качество плана на 70% определяет результат работы

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

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

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

Как составлять план, когда проект очень громоздкий

Бывают отдельные случаи,. когда проект очень сложный и масштабный (так называемый супер-проект или длительная программа). Классический пример такого проекта — “развитие сайта”.

Одно из важнейших свойств плана то, что после ознакомления с ним исполнители должны понимать, что им необходимо делать

Здесь нас могут сильно выручить майнд-карты. С их помощью удобно разрабатывать неочевидные планы и решать сложные задачи (про использование майнд-карт и программы для их создания я рассказывал в статье “Обзор книги Сергея Бехтерева «Майнд-менеджмент. Решение бизнес-задач с помощью интеллект-карт”).

Сделайте майнд-карту для супер-проекта. Разделите его на более простые подпроекты и их уже “прогоняйте” по данному алгоритму. Например, “развитие сайта” можно разделить на подпроекты: “Сбор и выкладка отзывов от клиентов”, “Создание справочника FAQ”, “Интеграция с сервисами рассылки” и т.д.

Как выбрать составителя плана

Мне часто задают вопрос: “А кто должен составлять план, руководитель или подчинённый, которому поручается проект?” Выбирая “кто будет составлять план”, разумно учитывать как квалификацию, так и область ближайшего развития подчинённого.

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

Если сотрудника должность и необходимость обязывает, а положительной динамики нет из-за отсутствия талантов или лености, такой человек, к сожалению, профнепригоден. Что с этим делать, я рассказываю в “Несвоевременное увольнение сотрудников: Почему опасно работать с человеком, которого давно пора уволить”.

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

6. Составьте список ключевых документов по проекту

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

Например, вы начинаете проект “создание системы привлечения клиентов из интернета” (кстати, в этом случае мы сможем помочь вам составить хороший и правильный план проекта в рамках услуги “Разработка стратегии привлечения клиентов из интернета”). Здесь в список ключевых документов будет правильно включить: действующий алгоритм продаж, ссылку на предыдущие отчёты по работам от подрядчиков, результаты маркетинговых исследований и т.д.

7. Определите объём необходимых ресурсов, выделите их руководителю проекта

Да, теперь, когда у вас есть подробный план, определить объём необходимых ресурсов — это дело техники (разительно отличается от метода “с потолка”, не правда ли?”).

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

Не забудьте выделить требуемые ресурсы руководителю проекта. Фраза “с ресурсами любой дурак умеет, а ты найди всё сам” заведомо гарантирует провал. Если в вашей компании всё происходит именно так, попробуйте перейти к этапу “Оценка полученных результатов и орг. выводы”. Вас устраивают результаты? Поздравляю, вы волшебник 80-го уровня и умеете лепить золотые слитки “из говна и пыли”. Немедленно закрывайте статью, она вам только навредит

8. Фиксируйте промежуточные результаты и договорённости в ЛОГе проекта

ЛОГ проекта — это место, куда необходимо фиксировать промежуточные результаты проекта (если у вас всё формализовано в системе постановки задач, фиксируйте ссылки на них), ключевые договорённости, изменения ресурсов и других параметров.

Кроме всего, вы сможете при необходимости произнести коронную фразу: “У меня все ходы записаны!”

Например, в рамках проекта “внедрение CRM” вы решили исследовать различные сервисы, зафиксировали итоги в отдельном документе и обсудили с генеральным директором. Итоговое решение и принципы, которыми генеральный директор руководствовался, обязательно должны быть зафиксированы в ЛОГе проекта. Иначе, сами понимаете, потом никто “не найдёт концов”.

9. Стартуйте выполнение проекта, управляйте и контролируйте

Проект перед стартом может быть разделён на несколько этапов. В зависимости от масштабов руководитель проекта переносит часть задач или все одного из этапов (а может быть и сразу всех) в систему постановки задач в формализованном виде (например, “Битрикс24”).

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

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

Лучший контроль со стороны руководителя — предварительный

Да, на этапе оценки качества плана работ и рисков, может быть потрачено дополнительное время руководителя. Но это именно тот “золотой ключик”, который я упоминал вначале статьи. Зато в процессе выполнения работ будет во много раз больше сэкономлено времени и руководителя, и подчинённого!

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

10. Финал. Проанализируйте результаты и выполните работу над ошибками

Тот, кто не выполняет анализа и не делает работу над ошибками, наступает многократно на одни и те же грабли. В рамках финального контроля проанализируйте и зафиксируйте в ЛОГе проекта следующее:

Свои успехи советский лётчик-ас Александр Иванович Покрышкин, сбивший более 53-х самолётов противника, объяснял так: “В учебных полетах большое внимание уделял овладению пилотированием самолета в усложненных условиях”. Рекомендую его книгу “Познать себя в бою” в качестве настольной для руководителя.

1. Качество полученного результата и соответствие сформулированным стандартам. Есть ли отклонения? Почему и в чём причина их возникновения? Какие действия необходимо предпринять для предотвращения их в других работах и проектах? Подробно про методы оценки читайте в статье “Как оценить эффективность работы сотрудников по итогам рабочего дня с помощью ежедневных отчётов: метод «анализа и комментариев»”.
2. Ошибки и сложности, возникшие по факту и действия, выполняемые для их решения. Почему их не удалось избежать? Как их избежать на других проектах и работах? Какие регламенты необходимо составить и/или внести изменения в существующие?
3. Каких сложностей и ошибок удалось избежать? Почему? Как их избежать и на других проектах?
4. Возможности и успехи, использованные в работе над проектом. Благодаря чему они возникли? Как удалось использовать? Как использовать и в других работах и проектах? Какие регламенты необходимо составить и/или внести изменения в существующие?
5. Какие возможности не удалось использовать? По каким причинам? Как использовать в других работах и проектах? Какие регламенты необходимо составить и/или внести изменения в существующие?

После фиксации и анализа результатов руководитель проекта сдаёт результат постановщику задачи, который собственно и выбирает, где ставить запятую в предложении “поощрить нельзя наказывать”.

Какой софт использовать для управления проектами

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

Если вы только переходите на проектное управление, рекомендую следующий способ:

1. Используйте файл в формате GoogleDocs (подойдут и другие текстовые редакторы, с которыми можно работать в онлайн-формате) для всех перечисленных выше пунктов. Очень удобно обсуждать риски и план работ с помощью системы комментариев к документу и возможности одновременно его редактировать/дополнять. Когда план проекта составить сложно, прибегайте к помощи майнд-карт. Большой проект дробите на несколько подпроектов.
2. Перенесите задачи из плана в систему постановки задач (мы используем для этого “Битрикс24”). Контролируйте в этой системе время и другие параметры задач. Что касается Битрикс24, то в ней есть возможность делать связи между задачами, а также создавать задачи второго и третьего уровня (подзадачи).
• Один из вариантов занесения в систему. Сделайте одну “корневую” задачу для всего проекта, назначьте ответственным руководителя проектом. У неё сделайте подзадачи по количеству этапов с тем же ответственным. Далее у только что созданных подзадач добавляйте подзадачи второго уровня, которые будут соответствовать пунктам в плане проекта, присваивая ответственных и планируемое время на выполнение.
• Задачи по контролю также заносите в систему постановки задач!

Бонус для внимательных читателей: шаблон “ЛОГа проекта”!

Хотите получить образец шаблона “ЛОГа проекта с разработанной структурой: цели, SWOT-анализ, план, подведение итогов?

Выполните 2 простых действия:
1) Оставьте комментарий к статье в самом низу, как на скриншоте по ссылке:
https://yadi.sk/i/QHQ2_R4oiWjkV (Напишите кратко о том, как вы управляете проектами и составными задачами? С какими сложностями вам приходилось сталкиваться? Аргументируйте, пожалуйста, свой ответ. При желании добавляйте к вашему комментарию вопросы).

2) Отправьте запрос на получение документа через мои личные аккаунты в социальных сетях (через личное сообщение):

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

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

Это избавит вас от бесконечного потока оперативных задач, вопросов от подчинённых и проблем, прилетающих не иначе как кучной стаей.

По итогам прочтения этой статьи, инструментарий работы с проектами и составными задачами — у вас в руках!

Иллюстрация: Mike Dotta / Shutterstock / Colowgee для Skillbox Media

Обозреватель Skillbox Media, отраслевой журналист. Работала с TexTerra, SMMplanner, «Нетологией», «ПланФактом», Semantica. Написала больше 60 текстов для рекламных кампаний в «Дзене». Вела нишевой канал на YouTube.

О плане проекта рассказал

Эксперт в области управления цифровыми проектами с 17-летним международным опытом. Бизнес-архитектор. Студент программы Skillbox и СПбГУ MBA «Лидеры изменений».

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

В этом материале Skillbox Media расскажем о плане проекта.

• Что такое план проекта и зачем он нужен
• Что входит в планирование
• Как планировать по PMBoK
• Как устроено планирование в Agile
• Где брать шаблоны

---

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

Вот какие элементы ещё есть в документе:

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

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

План проекта составляют на этапе подготовки. Сначала он может быть укрупнённым — только с важными ограничениями и этапами. Позже его могут детализировать, уточнять или корректировать. Но работают с ним всегда в одном документе, чтобы не упустить из виду ничего важного.

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

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

Курсы Skillbox для тех, кто хочет освоить проектный менеджмент

• «Профессия Менеджер проектов» — изучить разные методологии и управлять бюджетом, сроком и командой.
• «Управление проектами» — сопровождать проекты из любой отрасли на каждом этапе, от брифования до поддержки.
• «Управление командами» — управлять конфликтами, мотивировать и развивать сотрудников.

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

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

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

• Держите цели и задачи в фокусе. Менеджеру проекта важно проявить лидерские качества и повести за собой команду к общей цели. Поэтому он сам должен фокусироваться на ней.
• Сделайте планирование коллективным творчеством. Подключайте к процессу как можно больше участников и заинтересованных сторон. Это сделает план проекта проработанным и устойчивым.
• Используйте принцип меритократии. Он подразумевает, что важные решения должны принимать компетентные люди. Поэтому учитывайте все мнения, но они должны влиять на проект в разной степени. Создавайте такие условия, чтобы объективно талантливые люди могли влиять на принятие решений.
• Не бойтесь вносить изменения в план. Управляйте ими умно и проактивно. Помните, что план устаревает в момент, когда он готов. Поэтому старайтесь предвидеть возможные трудности и действуйте на опережение.

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

PMI — институт управления проектами — выпускает PMBoK (Project Management Body of Knowledge). Это свод знаний по управлению проектами. В PMBoK среди прочего описано планирование.

Согласно PMBoK, планирование — постоянный процесс. Для него менеджер должен использовать почти все области знаний, описанные в своде. Это управление:

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

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

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

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

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

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

Рисками. Это поиск и идентификация рисков, их качественный, количественный анализ и разработка планов действий для случаев, если риски наступят.

Интеграцией. Это сборка всех «элементов» в единый план управления, согласование с командой и заинтересованными сторонами. Интеграция позволяет объединить усилия всех сторон для достижения цели.

Этот список можно использовать как чек-лист, чтобы убедиться в полноте плана проекта. Если какая-то область знаний не учтена, постарайтесь понять, как это исправить. Например, можно привлечь кого-то в качестве заинтересованного лица, спонсора, партнёра или члена команды, чтобы он помог вам в управлении рисками или ресурсами.

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

Но в Agile составляют планы при формировании бэклога спринта. Спринт — это цикл работы, бэклог — перечень задач, которые нужно выполнить в этом цикле. Исходя из этих задач, менеджер планирует ресурсы, длительность, стоимость каждого спринта и приоритет работ в нём.

Поэтому планирование в Agile остаётся, но этот процесс совмещён с фазой исполнения и «растворён» в ней. Вы можете часто встречаться с командой и клиентом, чтобы контролировать и корректировать план.

В программах для управления проектами встречаются готовые шаблоны планов. В некоторых программах форматы планов подобраны для разных проектов и подходов к управлению.

В Skillbox Media есть подборка из восьми программ для менеджера проектов. Здесь мы перечислим главное, что о них нужно знать:

• MS Project — самое популярное, но сложное решение, оплата которого сейчас недоступна в России.
• Wrike — облачный сервис для планирования и управления проектами.
• Comindware — сервис с облачной и локальной версией, большим числом шаблонов. Подходит для Agile-разработки.
• «Аспро.Cloud» — российский облачный сервис, подходящий для Agile.
• Podio — программа с открытым исходным кодом, которую можно интегрировать с любыми сервисами.
• Worksection — сервис, который прекратил работу с пользователями из России.
• Advanta — российская программа, поддерживающая методологии Scrum и Agile.
• Jira — сервис, который работает на сервере или облаке. Оплатить его из России нельзя.
• «Битрикс24» — российский комплексный софт, в котором есть функция управления проектами.

Редакция «маркетинг» рекомендует

Как узнать больше об управлении проектами

• Управление проектами — отдельное направление в менеджменте. В нём много методик, принципов, концепций и практик. Начать изучение темы можно с этого материала Skillbox Media.
• Чтобы правильно составить план проекта, можно использовать декомпозицию. Это значит разобрать проект на небольшие части, или задачи. Так вы поймёте, сколько ресурсов и времени понадобится на достижение цели. Прочитайте наш гайд, чтобы научиться декомпозиции.
• За управление проектами отвечают менеджеры. Они умеют планировать, выстраивать систему коммуникаций, управлять командой и процессами и много что ещё. Узнать о профессии подробнее можно в этом материале Skillbox Media.
• Если вы хотите стартовать в профессии, приходите на курс Skillbox «Профессия Менеджер проектов». На нём учат определять цели проекта, собирать команду, работать с бюджетом, общаться с заказчиком. Также на курсе можно научиться готовить презентации и работать с Excel: делать сложные расчёты и готовить отчёты.

Другие материалы Skillbox Media о проектном менеджменте

• Что такое проект и что может быть его целью
• Главное о PMBoK — своде знаний по управлению проектами
• Что такое KPI, какие они бывают, как их разработать и показать графически
• Пошаговое руководство по управлению бюджетом проекта
• Что такое матрица RACI и как она помогает достигать целей в срок

Научитесь: Профессия Менеджер проектов
Узнать больше

Неудачное планирование проекта может привести к провалу еще до начала работы над ним. Но вы сможете избежать бесконтрольного расширения его объемов и раздувания бюджета и достигнете намеченных целей. Однако сесть и распланировать весь проект не так просто, как кажется. Как предугадать, сколько времени займет выполнение задач? Как превратить ожидания заинтересованных сторон в конкретные результаты работы? А вдруг что-нибудь пойдет не так? Как составить идеальный план управления проектами?

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

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

Что нужно включить в план управления проектом? По мнению Элизабет Харрин, известного блоггера, пишущего об управлении проектами, тщательно проработанный план проекта включает следующие элементы:

Wrike — система планирования управления проектами, которой пользуются 14000 компаний во всем мире. Попробуйте, чтобы улучшить планирование!