Документирование длительности проекта
Команда проекта была оформлена прошлой статьёй, а пока она формируется, мы разберёмся, как документировать сроки проекта, т.е. его длительность. Для этого нам понадобятся результаты документирования объёмов работ, несколько экспертов по технологии исполнения задуманного и приложение типа Microsoft Project.
Документирование длительности проекта - это частный случай планирования сроков проекта и разработки графика. Напомню, что общее управление проектами я стараюсь выносить за рамки этого цикла статей, и описываю только состав и правила заполнения документов для управления проектами. В общем процессы разработки расписания описаны в Practice Standard for Scheduling, а мы задокументируем это!
На данный момент у нас уже есть WBS (после документирования объёмов работ проекта), поэтому переносим её в MS Project (или подобный инструмент) и получаем отличную структурированную основу графика верхнего уровня (т.е. начинаем с первого способа). Далее, нужно каждый элемент WBS декомпозировать на мелкие элементы. И для нас нет никакой разницы, каким способом мы будем это делать. Можем для подпроектов использовать графики из прошлых проектов (способ 3), для конструктивов - шаблоны и нормативы (способ 4), а каждую фазу детализировать снизу-вверх (способ 2). Главное - в результате своей детализации дойти до отдельных работ и получить предварительный Список операций проекта.
Но как понять нормально мы детализировали или продолжать дальше дробить задачи? Давай разберём, что такое "работа".
Как квант в физике - неделимая порция какой-либо величины, так и работа - это неделимая часть проекта. Для неё сохраняется чёткое правило - она выполняется одним исполнителем в один период управления.
В свою очередь, размер "исполняющей бригады" и длительность управленческого периода зависят от масштаба проекта. Если проект на годы и в него вовлечено сотни человек, то исполнителем может быть целый департамент компании в лице его руководителя, а управленческий период длинной в квартал. Если проект маленький, то и исполнителем является 1 человек, а период - 1 неделя.
Работа, конечно, может начаться в одном периоде, а закончится в следующем. Но она не может длиться два и более периодов. Так же придерживаемся правила одного исполнителя, чтоб избежать коллективной безответственности. Смотрим на работы длиннее нашего управленческого периода и с количеством исполнителей более одного и продолжаем декомпозицию.
Понятно, что для слишком отдалённых во времени работ мы не сможем это сделать здесь и сейчас. А это и не требуется. Декомпозируйте методом набегающей волны. Можете спланировать работы на месяц-два? Планируйте! Остальные спланируете в течение этого месяца.
Кроме того, поддержание равномерного периода управления - это своего рода тактовый генератор проекта. К нему, например, привязываются вехи проекта, и я не рекомендую закладывать больше двух вех в один период или выполнять проект без вех дольше двух периодов. К нему же привязывается финансирование проекта, регулярность поставок, выделение ресурсов и пр. И в этом нет ничего странного и сложного, поскольку всё наше рабочее время состоит из таких периодов - неделя, декада, месяц, квартал... Выбирайте любой период, в зависимости от масштаба нашего проекта.
Итак, у нас есть перечень работ и есть ресурсы (подробнее в статье "Документирование команды проекта"). Теперь нужно определить длительности работ, расставить эти работы в логической последовательности и задокументировать связи между ними. Все работы в рамках проекта должны быть взаимосвязаны и представлены в виде сетевой диаграммы. Тогда легко определяется критический путь проекта и его общая длительность.
Конечно же, график подготовленный в такой последовательности (WBS - Список операций - Ресурсы - Длительности - Связи) далеко не всегда соответствует нашим ограничениям по срокам и загрузке ресурсов. Поэтому нужно "подчистить" свою работу.
Такая ситуация встречается сплошь и рядом. Эксперты собрались, "нагенерировали" задач, предоставили какие-то куски графика, указали основные взаимосвязи, прикинули ресурсы и разошлись. Планировщик оформил всё это в одном графике, неясности уточнил у экспертов, и добился приемлемых сроков, применив методы сжатия расписания.
И вроде бы, и диаграмма Гантта есть, и эксперты кивают головой (по крайнем мере каждый подтверждает свою часть графика), но как проверить, всё это в сборе взлетит или не взлетит?
Итак, хитрость. Нужно просто построить S-кривую по созданному графику. Как строить кривую, смотрите в микро-видео-уроке.
Смотрим на полученную S-кривую. На что она больше похожа?
В следующей статье я расскажу, как документировать бюджет проекта.
Документирование длительности проекта - это частный случай планирования сроков проекта и разработки графика. Напомню, что общее управление проектами я стараюсь выносить за рамки этого цикла статей, и описываю только состав и правила заполнения документов для управления проектами. В общем процессы разработки расписания описаны в Practice Standard for Scheduling, а мы задокументируем это!
Созидание графика
Есть 4 основных способа наполнения графика проекта:- Разработка "сверху-вниз" или от общего к частному. Т.е. мы сначала разбиваем проект на крупные блоки, затем детализируем эти блоки пока не дойдём до отдельных работ.
- Разработка "снизу-вверх" или от частного к общему. Т.е. сначала генерируется большое количество задач, которые нужно сделать, а потом они собираются в группы, подпроекты и кластера.
- Использование готового графика подобного проекта и адаптация его под нужны и условия нашего проекта.
- Использование шаблонов графиков и отраслевых нормативов.
На данный момент у нас уже есть WBS (после документирования объёмов работ проекта), поэтому переносим её в MS Project (или подобный инструмент) и получаем отличную структурированную основу графика верхнего уровня (т.е. начинаем с первого способа). Далее, нужно каждый элемент WBS декомпозировать на мелкие элементы. И для нас нет никакой разницы, каким способом мы будем это делать. Можем для подпроектов использовать графики из прошлых проектов (способ 3), для конструктивов - шаблоны и нормативы (способ 4), а каждую фазу детализировать снизу-вверх (способ 2). Главное - в результате своей детализации дойти до отдельных работ и получить предварительный Список операций проекта.
Но как понять нормально мы детализировали или продолжать дальше дробить задачи? Давай разберём, что такое "работа".
Как квант в физике - неделимая порция какой-либо величины, так и работа - это неделимая часть проекта. Для неё сохраняется чёткое правило - она выполняется одним исполнителем в один период управления.
В свою очередь, размер "исполняющей бригады" и длительность управленческого периода зависят от масштаба проекта. Если проект на годы и в него вовлечено сотни человек, то исполнителем может быть целый департамент компании в лице его руководителя, а управленческий период длинной в квартал. Если проект маленький, то и исполнителем является 1 человек, а период - 1 неделя.
Работа, конечно, может начаться в одном периоде, а закончится в следующем. Но она не может длиться два и более периодов. Так же придерживаемся правила одного исполнителя, чтоб избежать коллективной безответственности. Смотрим на работы длиннее нашего управленческого периода и с количеством исполнителей более одного и продолжаем декомпозицию.
Понятно, что для слишком отдалённых во времени работ мы не сможем это сделать здесь и сейчас. А это и не требуется. Декомпозируйте методом набегающей волны. Можете спланировать работы на месяц-два? Планируйте! Остальные спланируете в течение этого месяца.
Кроме того, поддержание равномерного периода управления - это своего рода тактовый генератор проекта. К нему, например, привязываются вехи проекта, и я не рекомендую закладывать больше двух вех в один период или выполнять проект без вех дольше двух периодов. К нему же привязывается финансирование проекта, регулярность поставок, выделение ресурсов и пр. И в этом нет ничего странного и сложного, поскольку всё наше рабочее время состоит из таких периодов - неделя, декада, месяц, квартал... Выбирайте любой период, в зависимости от масштаба нашего проекта.
Итак, у нас есть перечень работ и есть ресурсы (подробнее в статье "Документирование команды проекта"). Теперь нужно определить длительности работ, расставить эти работы в логической последовательности и задокументировать связи между ними. Все работы в рамках проекта должны быть взаимосвязаны и представлены в виде сетевой диаграммы. Тогда легко определяется критический путь проекта и его общая длительность.
Шаблоны документов для разработки расписания:
|
Прибрать за собой
Я не буду здесь рассказывать о всех способах сжатия и оптимизации расписания. Эти способы хорошо описаны в том же Practice Standard for Scheduling, в PMBOK или в любой другой литературе по управлению проектами. Я здесь расскажу об одной хитрости, как проверить качество разработки графика самим оформителем этого документа. Особенно это актуально, когда этот оформитель хорошо знает инструмент документирования (MS Project), но ничего не смыслит в технологии исполнения робот проекта.Такая ситуация встречается сплошь и рядом. Эксперты собрались, "нагенерировали" задач, предоставили какие-то куски графика, указали основные взаимосвязи, прикинули ресурсы и разошлись. Планировщик оформил всё это в одном графике, неясности уточнил у экспертов, и добился приемлемых сроков, применив методы сжатия расписания.
И вроде бы, и диаграмма Гантта есть, и эксперты кивают головой (по крайнем мере каждый подтверждает свою часть графика), но как проверить, всё это в сборе взлетит или не взлетит?
Итак, хитрость. Нужно просто построить S-кривую по созданному графику. Как строить кривую, смотрите в микро-видео-уроке.
- Если на наклонённую букву S (вариант I), то расписание составлено правильно. У нас есть:
- не очень активное начало (когда все участники ещё собираются мыслями и очень высока вероятность изменений, но изменений ещё пока на бумаге, а не на объекте);
- быстрая реализация основной части работ;
- и снова не очень активное планируемое завершение, которым мы сможем воспользоваться, если что-то пойдёт не так в основной части.
- Если вариант II, то мы спланировали аврал. Т.е. в начале есть время на раскачку, но в конце нет времени на непредвиденные ситуации.
- Если вариант III, то мы спланировали провал. В проекте не предусмотрено время на спокойную подготовку. Все средства и ресурсы с ходу кидаются "в бой". А мы помним закон Мэрфи "Если что-то может пойти не так, оно обязательно пойдет не так. Если всё идеально спланировано и ничего не может пойти не так, то появится что-то, что обязательно пойдет не так". Но на переделку этого "не так" уже ресурсов может не хватить.
- Ну, и вариант IV, хорош своей равномерностью, но не лишён проблем вариантов II и III, хотя, конечно, не так ярко как в этих вариантах.
Шаблоны документов расписания проекта:
|
Итого
С точки зрения документирования, итог планирования длительности проекта выглядит следующим образом:- WBS, Список операций и Требования к ресурсам, полученные на этапах документирования объёмов работ и документирования команды, и дающие нам возможность приступить к разработке расписания проекта.
- Оценка длительности операций и Последовательность операций в виде представлений «PA_PERT Entry Sheet» и «Сетевая диаграмма» в файле MS Project «ISO21500-5TIM1-Расписание».
- Расписание проекта, которое объединяет операций проекта, длительности, зависимости и другую информацию о планировании.
- Шаблоны всех этих и других документов по управлению сроками проекта можно получить/полистать здесь:
- ОСУП.Сроки.Комплект по PMBOK (5th edition).
- ИСО21500:Сроки по ISO 21500:2012.
- Полный пакет шаблонов, созданных на основе PMBOK (5-й редакции) можно получить здесь: ОСУП.Комплект.v5
- Полный пакет шаблонов, созданных на основе ISO 21500:2012 можно получить здесь: ИСО21500:Комплект
- Все примеры и шаблоны документов портала PMDoc, связанные с управлением сроками различных проектов, можно получить здесь: Сроки проекта.
В следующей статье я расскажу, как документировать бюджет проекта.
Оставьте комментарий