Вовремя и в рамках бюджета. Управление проектами по методу критической цепи - читать онлайн книгу. Автор: Лоуренс Лич cтр.№ 49

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

И наконец, мне не удалось найти ни одной книги, где бы давалось операциональное определение понятию «точность» именно с использованием амплитуды «плюс-минус 35%». Можно было бы предположить, что это величина стандартного отклонения, что это «граничная точка» или число с вероятностью 99%, если брать нормальное распределение, что, вероятно, будет неправомерно по отношению к оценке затрат. (Если не ошибаюсь, по данному определению точность составит плюс-минус 115%. Нет, ну минус-то уж точно быть не может!) Одинаковый ли смысл мы вкладываем в слово «точность»?

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

Исследования, проведенные крупными строительными фирмами, а также опыт управления проектами по методу критической цепи показали, что проекты, завершаемые вовремя, обычно практически не выходят за рамки планового бюджета. Это не относится к случаям, когда соблюдение сроков достигалось за счет больших переработок. Хотя ССРМ стабильно ведет к сокращению объемов сверхурочных работ при уменьшении общей длительности проекта: переработки допускаются только по тем операциям, которые влияют на своевременность завершения всего проекта. Когда проект идет с нарушением расписания и бюджета, как правило, это осознают тогда лишь, когда растраты (времени или денег) становится просто трудно не заметить. Обычно к тому моменту затрачено уже от половины до двух третей отпущенных по плану времени и средств. На этом этапе проектные расходы максимальны. И если пропорционально увеличить сроки, это вызовет огромный скачок в затратных статьях бюджета. Таким образом, при анализе состояния дел по проекту не следует соотносить напрямую перерасход средств с текущим выполнением графика.

Если для участников проекта характерны модели поведения, описанные в главе 2, положительные колебания проявить себя не смогут. Одна задержка на критической цепи — и сорван срок всего проекта. Кроме того, поскольку расходование средств идет по принципу «все или ничего», увеличение длительности работ приведет к превышению бюджета. Учитывая все вышесказанное, превышение будет значительным. Такие перерасходы не являются частью новой парадигмы управления проектами методом критической цепи, поскольку ССРМ искореняет причины превышения плановых показателей.

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

5.8. Буфер на затраты

Если затраты — значимая для вас категория, то в плане управления проектом должны быть указаны результаты их оценки, а также буфер на затраты. Размер буфера определяется с учетом рисков, определенных для данного проекта, и степени точности оценки. Если для вычисления расходов вы пользуетесь компьютерной программой, не забывайте, что каждая операция оценена с вероятностью 50/50%. Будьте готовы к тому, что в ходе проекта израсходуется немалая часть общего проектного резерва и буферов на слияние путей. Величину расходовании тоже нужно оценить. Это ваш «затратный буфер».

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

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

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

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

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

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

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

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

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

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

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

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

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

5.9. Оценка затрат

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