Как составить графика проекта

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

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

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

Как создать график проекта

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

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

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

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

  4. Составьте список всех действий или задач. Возьмите вехи и ожидаемые результаты, которые вы определили, выполняя действие № 1, и разбейте их на более мелкие задачи и подзадачи, чтобы учесть все возможные варианты.

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

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

  7. Организуйте график проекта в одном инструменте и поделитесь им с группой.

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

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

Попробовать Asana для управления проектами

Примеры графика проекта

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

Пример графика планирования мероприятия

Планируете виртуальное мероприятие? В вашем графике должно быть отражено всё, что нужно сделать, с указанием сроков вплоть до самого главного события.

[Вид хронологии] Проект проведения мероприятия для клиентов в Asana

Бесплатный шаблон для планирования мероприятий

Пример графика проекта по запуску нового продукта

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

[Вид хронологии] Хронология запуска продукта в Asana, представление в стиле диаграммы Ганта

Бесплатный шаблон запуска продукта

Пример графика маркетинговой кампании

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

[Вид списка] Проект плана маркетинговой кампании в Asana, представление в стиле электронной таблицы с ожидаемыми результатами проекта

Бесплатный шаблон для управления кампанией

Действия после составления графика проекта

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

Предоставление плана коллективу

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

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

Корректировка проекта по ходу выполнения

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

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

Повышение эффективности путём преобразования планов и графиков в шаблоны

Чтобы сэкономить ещё больше времени при планировании проектов, используйте проверенный шаблон и перестаньте заново изобретать колесо всякий раз, когда запускаете новый проект.

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

Где составлять график проекта?

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

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

Создать хронологии проектов с помощью Asana

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

Визуализировать календари групп в Asana

Работайте умнее с помощью графиков проектов

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

Автор статьи: Александр Захаркин

Рубрики: Управление проектом

– Как соблюсти последовательность работ по проекту?

– Составить проектный график.

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

График проекта

График проекта – дорожная карта работ

Что такое график проекта и зачем он нужен

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

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

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

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

Для составления графика мы используем специализированное ПО. Удобно работать, например в MSP (Microsoft Project). Программа позволяет следить за реализацией каждого этапа, отслеживать связи задач и подзадач, вносить необходимые коррективы.

Как по нотам!

Ноты помогают единому звучанию оркестра, а график проекта – слаженной работе всех участников

Структура графика проекта

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

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

  • Предпроектная подготовка.
  • Поиск помещения.
  • Тендер на проект.
  • Проектная документация.
  • Тендер на строительство.
  • Строительные работы.

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

Например, блок «Тендер» может состоять из таких задач и подзадач:

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

Итогом этапа станет список выбранных подрядчиков.

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

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

  • кто вовлечен в каждый из этапов;
  • кто несет ответственность за этап;
  • в какие сроки должно быть выполнено каждое действие;
  • что станет результатом выполненного действия – согласование или утверждение документов.

После выполнения всех задач результатом этапа станет подписание договора.

Спасательный круг

График проекта минимизирует риски нарушения сроков и последовательности этапов

Особенности работы по графику проекта

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

Проектный график эффективен для решения самых разных задач. Когда мы зашли в один из проектов, в нем уже работали 13 подрядчиков, каждый из которых имел свои собственные сроки и задачи. Это приводило к серьезным сбоям в последовательности действий. Проиллюстрировать ситуацию можно на примере известной басни «Лебедь, щука и рак». Сроки проекта были под угрозой срыва. Мы составили единый проектный график работ, обеспечили его исполнение подрядчиками. В результате строительство закончили в запланированные сроки.

Контроль и оперативная коррекция хода работ с помощью графика

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

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

Работа по графику выгодна для всех участников проекта.

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

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

Статья предоставлена редакцией информационно-аналитического журнала “Управление Проектами” в рамках совместного проекта с Финансовой академией “Актив”.

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

Читайте больше интересных статей в журнале “Управление Проектами”

Для кого эта статья

Существует масса пособий по работе в MS Project. Почти все они рассказывают о технике: как пользоваться приложением, какие сущности в нем существуют, какие связи между задачами используются и т.д. Однако когда доходит до практики, руководитель проекта сталкивается с необходимостью принимать решения другого характера – какие задачи должны входить в график, как найти золотую середину между детальностью графика и удобством работы с ним, какие приемы лучше использовать, чтобы минимизировать трудозатраты на планирование? Как, в конце концов, обеспечить выполнение сроков проекта?

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

Планирование проекта

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

Если говорить об управлении сроками, то можно сформулировать следующие требования. Хороший график проекта:

  1. Приспособлен для информирования заказчика и проектной команды. Для этого он должен быть понятным, компактным, логичным, хорошо структурированным.
  2. Легко модифицируется в случае изменений сроков и состава задач. Его легко поддерживать в актуальном состоянии.
  3. Позволяет контролировать сроки, обнаруживать проблемы и принимать по этому поводу решения.

Для того, чтобы составить такой график предлагаем следующий план действий:

  1. Принять решение о способе планирования.
  2. Избавиться от всего лишнего и упростить план.
  3. Установить взаимосвязи между задачами.
  4. Оценить длительность задач
  5. Избавиться от распараллеливания задач
  6. Выровнять ресурсы.
  7. Установить ограничения по датам.
  8. Выявить критический путь.
  9. Добавить временные буферы в график.
  10. Проанализировать, как можно сократить сроки.

1. Принять решения о способе планирования

1.1. Планирование от начала

Более привычный для большинства способ. Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.

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

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

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

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

Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».

Иногда используют задержки и сдвиги между задачами.

Рисунок 1

image-1

Однако пользоваться задержками лучше по возможности меньше.

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

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

1.2. Планирование от конца

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

Логика планирования в этом случае другая, но в некотором смысле более правильная. Вы задаете себе вопрос: «что необходимо, чтобы завершить проект?». Затем определяете, что необходимо, чтобы достичь этих промежуточных результатов, добавляете предшествующие задачи, к ним в свою очередь присоединяются предыдущие задачи и т.д. Выстраивается последовательная цепочка работ, которые ведут к результатам проекта.

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

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

2. Избавиться от лишнего и упростить план

Лишним считается все, что не помогает планировать сроки проекта.

2.1. Примеры задач, от которых можно избавиться

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

Рисунок 2

image-2

Задача «Поддержка». Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам. Можно включить ее в план проекта, но минимизировать ее детализацию. Эта задача может быть спокойно заменена в плане на две контрольные точки: Начало эксплуатации и Окончание поддержки.

Рисунок 3

image-3

План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения. Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать. В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения. Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.

2.2. Пример излишней детализации

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

Рисунок 4

image-4

  • «Письмо Пятнициной» — «Ответ Пятнициной». Можно спокойно исключить из плана. Если какие-то задачи зависят от получения письма от Пятнициной, и это действительно шоу-стоппер, то вводим веху «Получение списка ключевых пользователей от Пятнициной». То, что для получения списка нам нужно связаться с Пятнициной, может остаться за кадром.
  • «Назначение встречи» — 1д. Скорее всего должно занять несколько минут. Вместо этого можно было бы вставить одну задачу по подготовке презентации и веху «Встреча с директорами обществ». Не нужна группировка задач. Вместо четырех строк — две.
  • «Выпуск организационно-распорядительной документации» может быть одной задачей. В заметках по задаче, можно перечислить, кому нужно выслать письмо. Длительность задачи определяется суммарным временем подготовки всех документации. И эта информация будет точнее, растягивать эту задач на неделю нет никакой необходимости.

3. Установить взаимосвязи между задачами

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

Можем дать следующие рекомендации для выстраивания графика.

3.1. Используйте минимум видов связей

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

3.2. Не используйте связи с суммарными задачами

Рассмотрим упрощенный пример проекта, состоящего из двух этапов. Иногда план выглядит так:

Рисунок 5

image-5

В результате мы имеем неоптимальный план. Иванов и Петров будут простаивать, ожидая завершения работы Сидорова по Этапу 1. Если у нас есть задача максимально сжать график проекта, мы начнем работы по Этапу 2, не дожидаясь завершения всех работ по Этапу 1. И тогда график будет выглядеть следующим образом. Связи между задачами, в данном случае отражают последовательность работ каждого из ресурсов.

Рисунок 6

image-6

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

Рисунок 7

image-7

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

3.3. Используйте Сетевую диаграмму

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

Рисунок 8

image-8

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

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

Рисунок 9

image-9

Рисунок 10

image-10

4. Оценить длительность задач

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

При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:

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

Задачи не должны включать запас «на всякий случай». Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок. Реальность такова, что все опоздания накапливаются, а опережения съедаются. Почему так? Причины могут быть следующие:

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

Поэтому придерживайтесь следующих правил при планировании работ:

  • Вероятность выполнения в указанный срок установите в 50%. Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое. Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
  • Ресурсы не должны быть перегружены. Люди не должны выполнять несколько задач одновременно. В этом случае их производительность будет максимально возможной.

5. Избавиться от распараллеливания задач

Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей. Например,

Рисунок 11

image-11

Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам. Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену. Наличие пяти параллельных задач не имеет смысла. Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.

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

6. Выровнять ресурсы

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

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

В MS Project имеется функция выравнивания ресурсов. Эта функция расставляет задачи с учетом связей между задачами и ограничения по максимальной загрузке каждого ресурса и приоритета (поле «Приоритет»). Не всегда это приводит к нужному результату. План становится слишком длинным, а ресурсы недогружены. Задачи привязываются в плане к конкретным датам, что мешает их перепланировать. Можно добиться более адекватного плана в ходе автоматического выравнивания с помощью пересмотра зависимостей и расстановкой приоритетов, но это очень кропотливый и трудоемкий процесс.

Альтернатива — это ручное выравнивание с помощью установки последовательности задач, выполняемых одним ресурсом. Это возможно, если план не очень сложный.

Например, модифицируем предыдущий пример:

Рисунок 12

image-12

В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова. Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней. Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.

Было бы более правильно вообще разделить задачи между двумя участниками и избавиться от параллельного выполнения задач А.Теном, но в данном случае это сделать сложно. Поэтому приходится идти на нарушение правил, которые мы сами для себя установили выше. Тем не менее, такой план лучше, т.к. помогает контролировать выполнение задач не в конце 14 рабочих дней, которые мы отвели на проектирования функционального блока «Контроль», а уже через 3 дня после начала работы. Кроме того, это дисциплинирует исполнителя с первого дня, у которого нет 14 дней в запасе, а есть целевой срок 3 дня, когда нужно закончить первый документ.

7. Исключить жесткую привязку задач к датам

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

Привязка к датам оправдана, если определяется внешними по отношению к плану условиями. Например, зафиксированная дата начала испытаний; контрольная точка, которая определяется внешним проектом; несдвигаемое событие. Во всех остальных случаях нужно избегать ограничений. Если их избежать не удается, то лучше использовать мягкие ограничения: «Начало не позднее», «Начало не ранее» и т.п. Это позволяет автоматически двигать задачи вслед за теми, от которых они зависят.

8. Выявить критический путь

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

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

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

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

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

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

Рисунок 13

image-13

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

Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».

9. Добавить временные буферы в график

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

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

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

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

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

Рисунок 14

image-14

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

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

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

Подробнее об этом методе построения графика проекта можно прочитать в книге Э.Голдратта «Критическая цепь», которая написана в форме бизнес-романа, легко читается и действует крайне вдохновляюще.

10. Проанализировать график

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

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

10.1. Сокращение сроков

Рассмотрим пример:

Рисунок 15

image-15

Посмотрим, нельзя ли сократить этот график. Самые длинные задачи — номер 17 и 21. 18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.

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

Рисунок 16

image-16

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

10.2. Риски, связанные с графиком

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

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

Заключение

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

График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам. Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.

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

Научитесь контролировать работу проекта в режиме реального времени с помощью дашбордов Power BI на курсе «ACPM: Бизнес-анализ данных в финансах». Зарегистрируйтесь и пройдите 1-й урок бесплатно!

Разработка план-графика проекта

Разработка план-графика проекта

Султанов Искандер Анварович

Свежие публикации автора:

Содержание

  • 1 Отражение содержания проекта в план-графике
  • 2 Прояснение параметров работ
  • 3 Собственно календарный план

При планировании выполнения любой задачи традиционными вопросами являются: «Что сделать?», «Когда?», «Кто?», «Каковы результаты?». И поскольку проектное мероприятие включает в свой состав целую совокупность действий, в группе документов сводного плана обязательно должен присутствовать план-график проекта, который также именуется проектным расписанием или календарным планом. В настоящей статье мы рассмотрим действия по подготовке и варианты визуального представления данного документа.

Отражение содержания проекта в план-графике

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

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

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

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

календарный план и процессы планирования

Место разработки календарного плана в процессах планирования проекта

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

Прояснение параметров работ

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

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

ИСР функционального типа

Пример ИСР функционального типа разбиения

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

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

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

  • продолжительность работ;
  • трудозатраты на выполнение операций.

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

Собственно календарный план

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

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

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

  • распорядительного документа, предписывающего выполнение конкретных действий;
  • мониторингового ресурса;
  • документа для контрольных мероприятий;
  • документа-основания для принятия решения об изменении планов проекта.

электронная форма план-графика

Пример электронной формы плана-графика проекта

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

  1. Табличная форма.
  2. Ленточная диаграмма.
  3. Диаграмма Ганта (или Гантта).
  4. Диаграмма контрольных событий (график по вехам).
  5. Сетевая диаграмма с учетом временного масштаба.

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

табличная форма план-графика

Пример табличной формы план-графика проекта

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

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

Для кого эта статья

Существует масса пособий по работе в MS Project.  Почти все они рассказывают о технике: как пользоваться приложением, какие сущности в нем существуют, какие связи между задачами используются и т.д.   Однако когда доходит до практики, руководитель проекта сталкивается с необходимостью принимать решения другого характера – какие задачи должны входить в график, как найти золотую середину между детальностью графика и удобством работы с ним, какие приемы лучше использовать, чтобы минимизировать трудозатраты на планирование?  Как, в конце концов, обеспечить выполнение сроков проекта?

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

Планирование проекта

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

Если говорить об управлении сроками, то можно сформулировать следующие требования.  Хороший график проекта:

  1. Приспособлен для информирования заказчика и проектной команды.  Для этого он должен быть понятным, компактным, логичным, хорошо структурированным.
  2. Легко модифицируется в случае изменений сроков и состава задач.  Его легко поддерживать в актуальном состоянии.
  3. Позволяет контролировать сроки, обнаруживать проблемы и принимать по этому поводу решения.

Для того, чтобы составить такой график предлагаем следующий план действий:

  1. Принять решение о способе планирования.
  2. Избавиться от всего лишнего и упростить план.
  3. Установить взаимосвязи между задачами.
  4. Оценить длительность задач
  5. Избавиться от распараллеливания задач
  6. Выровнять ресурсы.
  7. Установить ограничения по датам.
  8. Выявить критический путь.
  9. Добавить временные буферы в график.
  10. Проанализировать, как можно сократить сроки.

1. Принять решения о способе планирования

1.1. Планирование от начала

Более привычный для большинства способ.  Удобен, если вы знаете начало проекта, но только приблизительно представляете, когда он закончится.

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

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

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

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

Чтобы избежать раннего начала задач и распределить задачи во времени, можно использовать ограничения на задачи типа «Не ранее чем», «Фиксированная дата начала».

Иногда используют задержки и сдвиги между задачами.

Рисунок 1

image-1

Однако пользоваться задержками лучше по возможности меньше.

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

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

1.2. Планирование от конца

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

Логика планирования в этом случае другая, но в некотором смысле более правильная.  Вы задаете себе вопрос: «что необходимо, чтобы завершить проект?».  Затем определяете, что необходимо, чтобы достичь этих промежуточных результатов, добавляете предшествующие задачи, к ним в свою очередь присоединяются предыдущие задачи и т.д.  Выстраивается последовательная цепочка работ, которые ведут к результатам проекта.

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

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

2. Избавиться от лишнего и упростить план

Лишним считается все, что не помогает планировать сроки проекта.

2.1. Примеры задач, от которых можно избавиться

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

Рисунок 2

image-2

Задача «Поддержка».  Как правило, это задача, которая начинается после запуска в эксплуатацию и имеет, как правило, фиксированную длительность (по договору), либо привязана к некоторым контрольным точкам.  Можно включить ее в план проекта, но минимизировать ее детализацию.  Эта задача может быть спокойно заменена в плане на две контрольные точки:  Начало эксплуатации и Окончание поддержки.

Рисунок 3

image-3

План, в конечном итоге, нужен чтобы ставить задачи и проверять факт и качество исполнения.  Это очень хороший критерий, чтобы определить, с какой степенью детализации его делать.   В план должны попадать только те задачи, которые РП собирается ставить и проверять их исполнения.  Более мелкие задачи переносятся за пределы плана — в Excel, в JIRA или в связанный план рабочей группы в MS Project.

2.2. Пример излишней детализации

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

Рисунок 4

image-4

  • «Письмо Пятнициной» — «Ответ Пятнициной».  Можно спокойно исключить из плана.  Если какие-то задачи зависят от получения письма от Пятнициной, и это действительно шоу-стоппер, то вводим веху «Получение списка ключевых пользователей от Пятнициной».  То, что для получения списка нам нужно связаться с Пятнициной, может остаться за кадром.
  • «Назначение встречи» — 1д.  Скорее всего должно занять несколько минут. Вместо этого можно было бы вставить одну задачу по подготовке презентации и веху «Встреча с директорами обществ».  Не нужна группировка задач.  Вместо четырех строк — две.
  • «Выпуск организационно-распорядительной документации» может быть одной задачей.   В заметках по задаче, можно перечислить, кому нужно выслать письмо.  Длительность задачи определяется суммарным временем подготовки всех документации.  И эта информация будет точнее, растягивать эту задач на неделю нет никакой необходимости.

3. Установить взаимосвязи между задачами

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

Можем дать следующие рекомендации для выстраивания графика.

3.1. Используйте минимум видов связей

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

3.2. Не используйте связи с суммарными задачами

Рассмотрим упрощенный пример проекта, состоящего из двух этапов.  Иногда план выглядит так:

Рисунок 5

image-5

В результате мы имеем неоптимальный план.  Иванов и Петров будут простаивать, ожидая завершения работы Сидорова по Этапу 1.  Если у нас есть задача максимально сжать график проекта, мы начнем работы по Этапу 2, не дожидаясь завершения всех работ по Этапу 1.  И тогда график будет выглядеть следующим образом.  Связи между задачами, в данном случае отражают последовательность работ каждого из ресурсов.

Рисунок 6

image-6

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

Рисунок 7

image-7

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

3.3. Используйте Сетевую диаграмму

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

Рисунок 8

image-8

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

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

Рисунок 9

image-9

Рисунок 10

image-10

4. Оценить длительность задач

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

При оценке исполнителями нужно делать поправку. Учитывайте следующие факторы:

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

Задачи не должны включать запас «на всякий случай».  Добавление запаса в каждую задачу с целью повысить вероятность выполнения в срок каждой задачи, скажем до 90%, делает график длинным, и при этом вы все равно не уложитесь в срок.  Реальность такова, что все опоздания накапливаются, а опережения съедаются.  Почему так?  Причины могут быть следующие:

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

Поэтому придерживайтесь следующих правил при планировании работ:

  • Вероятность выполнения в указанный срок установите в 50%.  Это сократит оценку длительности по сравнению с 90% оценкой вероятности примерно вдвое.  Сокращение времени позволит добавить в график временные буферы, которые вы будете расходовать из-за неизбежного опоздания по задачам. О добавлении буферов смотрите ниже.
  • Ресурсы не должны быть перегружены.  Люди не должны выполнять несколько задач одновременно.  В этом случае их производительность будет максимально возможной.

5. Избавиться от распараллеливания задач

Часто можно увидеть в планах параллельные задачи, назначенные на одних и тех же исполнителей.  Например,

Рисунок 11

image-11

Очевидно, РП отдает управление последовательностью и приоритетом задач консультантам.  Тогда, с точки зрения планирования, достаточно было бы одной задачи «Функциональный блок Контроль», назначенной на Емельянову и Тену.  Наличие пяти параллельных задач не имеет смысла.  Все ресурсы перегружены, трудоемкость и длительность задачи не оценена, приоритеты не понятны.

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

6. Выровнять ресурсы

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

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

В MS Project имеется функция выравнивания ресурсов.  Эта функция расставляет задачи с учетом связей между задачами и ограничения по максимальной загрузке каждого ресурса и приоритета (поле «Приоритет»).  Не всегда это приводит к нужному результату.  План становится слишком длинным, а ресурсы недогружены.  Задачи привязываются в плане к конкретным датам, что мешает их перепланировать.  Можно добиться более адекватного плана в ходе автоматического выравнивания с помощью пересмотра зависимостей и расстановкой приоритетов, но это очень кропотливый и трудоемкий процесс.

Альтернатива — это ручное выравнивание с помощью установки последовательности задач, выполняемых одним ресурсом. Это возможно, если план не очень сложный.

Например, модифицируем предыдущий пример:

Рисунок 12

image-12

В данном примере считается, что А.Тен участвует в доработке всех документов, и два документа пишет самостоятельно. Мы точно не знаем, как будет построена их совместная работа, но предполагаем в среднем он будет на 30% отвлечен на документы А.Емельянова.  Поэтому собственные задачи, где он занят на 70% больше по длительности, и оцениваются в 5 рабочих дней.  Кроме того, мы добавили буфер, предполагая, что часть задач могут занять больше времени, чем мы предполагаем.

Было бы более правильно вообще разделить задачи между двумя участниками и избавиться от параллельного выполнения задач А.Теном, но в данном случае это сделать сложно.  Поэтому приходится идти на нарушение правил, которые мы сами для себя установили выше.  Тем не менее, такой план лучше, т.к. помогает контролировать выполнение задач не в конце 14 рабочих дней, которые мы отвели на проектирования функционального блока «Контроль», а уже через 3 дня после начала работы.  Кроме того, это дисциплинирует исполнителя с первого дня, у которого нет 14 дней в запасе, а есть целевой срок 3 дня, когда нужно закончить первый документ.

7. Исключить жесткую привязку задач к датам

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

Привязка к датам оправдана, если определяется внешними по отношению к плану условиями.  Например, зафиксированная дата начала испытаний; контрольная точка, которая определяется внешним проектом; несдвигаемое событие.  Во всех остальных случаях нужно избегать ограничений.  Если их избежать не удается, то лучше использовать мягкие ограничения: «Начало не позднее», «Начало не ранее» и т.п.  Это позволяет автоматически двигать задачи вслед за теми, от которых они зависят.

8. Выявить критический путь

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

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

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

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

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

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

Рисунок 13

image-13

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

Такой способ планирования хорошо сочетается с методикой планирования «от конца проекта».

9. Добавить временные буферы в график

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

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

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

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

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

Рисунок 14

image-14

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

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

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

Подробнее об этом методе построения графика проекта можно прочитать в книге Э.Голдратта «Критическая цепь», которая написана в форме бизнес-романа, легко читается и действует крайне вдохновляюще.

10. Проанализировать график

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

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

10.1. Сокращение сроков

Рассмотрим пример:

Рисунок 15

image-15

Посмотрим, нельзя ли сократить этот график.  Самые длинные задачи — номер 17 и 21.  18 и 15 дней — слишком длинные задачи для того, чтобы их можно было эффективно контролировать.

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

Рисунок 16

image-16

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

10.2. Риски, связанные с графиком

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

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

Заключение

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

График проекта становится реальным инструментом управления в руках руководителя проекта, если график составлен с умом и следуя определенным стандартам.  Владение инструментом и методами позволяет управлять сроками проекта гораздо эффективнее, с меньшими трудозатратами времени.

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

Добавить комментарий