Вовремя и в рамках бюджета - Лоуренс Лич

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

В работе «Нормирование размера буферов времени и затрат: как справиться с расхождениями между планом и фактом» (Schedule and Cost Buffer Sizing: How to Account for the Bias between Project Performance and Your Model) [9] я подробно описываю два типа неопределенности, с которыми необходимо считаться:

1) вызванные особыми причинами отклонения, которые просто суммируются;

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

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

М.Р. Виджер и А.В. Карк [10], проведя недавно исследование проектов по разработке программного обеспечения, заметили:

«Среди изученных нами был ряд крупномасштабных проектов длительностью более четырех лет с трудозатратами более чем 100 человеко-лет. И во всех без исключения случаях плановые показатели расходов были чрезвычайно занижены».

Они приводят следующие причины.

• В крупных системах с появлением нового элемента все усложняется в геометрической (а не линейной) прогрессии.

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

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

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

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

Принципы проведения оценки затрат должны быть указаны в описании пакетов работ. Это чрезвычайно важно для планирования контрактов с возмещением затрат и многих правительственных проектов. Зачастую технические специалисты испытывают трудности с формулировкой принципов собственных подсчетов. Оценить количество необходимых ресурсов — не проблема. А вот объяснить, как они получили ту или иную цифру, никак не получается. Все сводится к маловразумительному объяснению в духе «это экспертная оценка», «на основании имеющегося опыта». Для начала можно спросить, на каких предположениях и допущениях строится оценка.

Профессиональный оценщик без труда продемонстрирует вам принципы получения оценки. Обычно даже не приходится специально просить. Оценщик ссылается на руководства, конкретные случаи из практики, приводит данные от поставщиков или дает иные обоснования своим выводам. Как правило, несложно объяснить, откуда берется цифра по затратам на оборудование (например, 500 футов 4-дюймовых труб по $1,85 за фут — по данным о смете на водопровод, полученным Джимом А. от Джо 15 марта 1996 года). Про составление смет в строительстве, программировании и других специальных областях написаны целые тома. Итак, главная мысль в том, чтобы можно было определить, на чем основана оценка. Тогда впоследствии при необходимости внесения изменений сразу будет видно, что в нее входило, а что нет.

План управления проектом, он же план проекта или рабочий план, объединяет в себе все описанные выше компоненты в формате, удобном и доступном для восприятия всем участникам проекта. Это — основа для обмена информацией в рамках проекта. РМВОК приводит следующий перечень задач, которые решает план управления проектом:

• задает направление для проектных работ;

• фиксирует исходные установки, легшие в основу плана;

• содержит задокументированные результаты выбора при наличии различных вариантов;

• служит основой для общения между сторонами в проекте;

• определяет основные моменты для проведения анализа со стороны руководства (суть, содержание, сроки);

• служит основой для оценки хода реализации и контроля за проектом.

В крупных проектах план может включать в себя (непосредственно или в виде ссылки) также другие компоненты:

• предметные планы, например по качеству, безопасности, поставкам, обеспечению персоналом, защите окружающей среды, системному проектированию;

• рекомендации по обмену информацией в проекте, правила отчетности, распространения и согласования документации;

• рабочие процедуры;

• спецификации и стандарты;

• процедуры управления изменениями.

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

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

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

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

• определиться с выставлением счетов клиентам, если запрос на изменения шел с их стороны;

• регистрировать изменения;

• отслеживать ход проекта в сравнении с первоначальным — базовым планом.

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