Страницы

30 января 2015 г.

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

Команда проекта была оформлена прошлой статьёй, а пока она формируется, мы разберёмся, как документировать сроки проекта, т.е. его длительность. Для этого нам понадобятся результаты документирования объёмов работ, несколько экспертов по технологии исполнения задуманного и приложение типа Microsoft Project.
Документирование длительности проекта - это частный случай планирования сроков проекта и разработки графика. Напомню, что общее управление проектами я стараюсь выносить за рамки этого цикла статей, и описываю только состав и правила заполнения документов для управления проектами. В общем процессы разработки расписания описаны в 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-кривую. На что она больше похожа?

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

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

Итого

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


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

Комментариев нет:

Отправить комментарий