Документирование длительности проекта

Команда проекта была оформлена прошлой статьёй, а пока она формируется, мы разберёмся, как документировать сроки проекта, т.е. его длительность. Для этого нам понадобятся результаты документирования объёмов работ, несколько экспертов по технологии исполнения задуманного и приложение типа Microsoft Project.

Подписывайтесь на группу PMDoc в Facebook, и обсуждайте с коллегами вопросы документирования проектов

Меня зовут Анатолий Савин. Я эксперт по документированию и автор тренинга «Документирование проектов». Я продолжаю цикл статей и видео-уроков по управленческому документированию проектов. Перед тобой четвёртая статья из этого цикла – «Документирование длительности проекта».

Документирование длительности проекта — это частный случай планирования сроков проекта и разработки графика. Напомню, что общее управление проектами я стараюсь выносить за рамки этого цикла статей, и описываю только состав и правила заполнения документов для управления проектами. В общем процессы разработки расписания описаны в Practice Standard for Scheduling, а мы задокументируем это!

Созидание графика

Есть 4 основных способа наполнения графика проекта:

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

Все эти способы легко комбинируются друг с другом. Вот мы и скомбинируем.

На данный момент у нас уже есть WBS (после документирования объёмов работ проекта), поэтому переносим её в MS Project (или подобный инструмент) и получаем отличную структурированную основу графика верхнего уровня (т.е. начинаем с первого способа). Далее, нужно каждый элемент WBS декомпозировать на мелкие элементы. И для нас нет никакой разницы, каким способом мы будем это делать. Можем для подпроектов использовать графики из прошлых проектов (способ 3), для конструктивов — шаблоны и нормативы (способ 4), а каждую фазу детализировать снизу-вверх (способ 2). Главное — в результате своей детализации дойти до отдельных работ и получить предварительный Список операций проекта.

Но как понять нормально мы детализировали или продолжать дальше дробить задачи? Давай разберём, что такое «работа».

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

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

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

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

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

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

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

Конечно же, график подготовленный в такой последовательности (WBSСписок операцийРесурсы — Длительности — Связи) далеко не всегда соответствует нашим ограничениям по срокам и загрузке ресурсов. Поэтому нужно «подчистить» свою работу.

Прибрать за собой

Я не буду здесь рассказывать о всех способах сжатия и оптимизации расписания. Эти способы хорошо описаны в том же Practice Standard for Scheduling, в PMBOK или в любой другой литературе по управлению проектами. Я здесь расскажу об одной хитрости, как проверить качество разработки графика самим оформителем этого документа. Особенно это актуально, когда этот оформитель хорошо знает инструмент документирования (MS Project), но ничего не смыслит в технологии исполнения робот проекта.

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

И вроде бы, и диаграмма Гантта есть, и эксперты кивают головой (по крайнем мере каждый подтверждает свою часть графика), но как проверить, всё это в сборе взлетит или не взлетит?

Итак, хитрость. Нужно просто построить S-кривую по созданному графику. Как строить кривую, смотрите в микро-видео-уроке.


Смотрим на полученную S-кривую. На что она больше похожа?
S-curves

  1. Если на наклонённую букву S (вариант I), то расписание составлено правильно. У нас есть:
    • не очень активное начало (когда все участники ещё собираются мыслями и очень высока вероятность изменений, но изменений ещё пока на бумаге, а не на объекте);
    • быстрая реализация основной части работ;
    • и снова не очень активное планируемое завершение, которым мы сможем воспользоваться, если что-то пойдёт не так в основной части.
  2. Если вариант II, то мы спланировали аврал. Т.е. в начале есть время на раскачку, но в конце нет времени на непредвиденные ситуации.
  3. Если вариант III, то мы спланировали провал. В проекте не предусмотрено время на спокойную подготовку. Все средства и ресурсы с ходу кидаются «в бой». А мы помним закон Мэрфи «Если что-то может пойти не так, оно обязательно пойдет не так. Если всё идеально спланировано и ничего не может пойти не так, то появится что-то, что обязательно пойдет не так». Но на переделку этого «не так» уже ресурсов может не хватить.
  4. Ну, и вариант IV, хорош своей равномерностью, но не лишён проблем вариантов II и III, хотя, конечно, не так ярко как в этих вариантах.

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

Шаблоны документов расписания проекта:

Итого

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

  1. WBS, Список операций и Требования к ресурсам, полученные на этапах документирования объёмов работ и документирования команды, и дающие нам возможность приступить к разработке расписания проекта.
  2. Оценка длительности операций и Последовательность операций в виде представлений «PA_PERT Entry Sheet» и «Сетевая диаграмма» в файле MS Project «ISO21500-5TIM1-Расписание».
  3. Расписание проекта, которое объединяет операций проекта, длительности, зависимости и другую информацию о планировании.

В следующей статье я расскажу, как документировать бюджет проекта.

Документирование длительности проекта: 2 комментария

  1. Andrew_Hnatyuk

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

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