Инструмент в помощь Менеджерам IT-проектов для прогнозирования сроков выполнения проектов по ключевым рискам.
Это инструмент для демонстрации влияния рисков проекта на сроки его завершения.
Учитываются 5 неуправляемых рисков из-за которых происходит большинство расхождений между планом проекта и реальностью. Отчасти описанные проблемы решаются гибкими методололгиями, однако, и они не избавляют руководителя от управления рисками.
Главная особенность этих рисков - повторяемость от проекта к проекту и игнорирование менеджерами.
Математическая модель расчетов описана Томом Де Марко и Тимоти Листером в книге «Вальсируя с Медведями», заслужившей признания мирового сообщества руководителей проектов. Читать на bookmate.
В расчетах применяется моделирование методом Монте-Карло с N = 50 000. При моделировании используются коэффициенты полученные авторами книги опытным путем, крайне советую поиграть с ними, для понимания влияние рисков на изменнеие вероятной даты завершения проекта.
Этот инструмент предназначен НЕ для оценки длительности и стоимости проекта, а для определения необходимого запаса времени на преодоление влияния описанных рисков. Кроме того, для определения оптимистичной даты завершения проекта придется воспользоваться опытом и знанием в проектном управлении.
Выполните каждый шаг и получите наиболее вероятные сроки завершения вашего проекта.
Установите дату начала проекта и спрогнозируйте дату завершения, представив, что рисков не существует и вы самый везучий человек на свете.
Из-за следующих 5 проблем происходит большинство расхождений между планом и реальностью, потому, что они практически не зависят от трудолюбия, компетенций и опыта.
Отметьте риски, которые хотите учитывать в расчетах.
Для каждого выбранного риска установите:
Главный из пяти рисков по степени влияния на расхождение плана проекта и реального исполнения. 50% проектов проваливаются из-за ошибок допущенных при планировании.
Заложить некоторый резерв времени на случай ошибок планирования и возникновения непредвиденных обстоятельств и привлекать разработчиков к оценке сроков.
Если ничего больше не известно о проекте или компании, то можно с уверенностью утверждать, что первоначальная оценка размера проекта вынудит перерасходовать запланированное время, по крайней мере, на 30%.
Изменение требований это - раздувание, поскольку даже удаление реализованного функционала требует дополнительной работы. В каждом проекте разумно ожидать изменения в требованиях и управлять изменениями.
Подсказка: 0% не будет правильным выбором вероятного значения, но часто при планировании нового проекта не учитываются риски на изменение требований.
В гибким методологиях проблема решается регулярным обсуждением с клиентом смены сроков и функционала на каждом этапе сотрудничества. Вместо подавления изменений со стороны заказчика используется расстановка приоритетов.
Люди иногда уходят во время проекта и, чтобы принять во внимание этот фактор, учитывайте некий буфер для сдерживания риска.
Подсказка: вероятное значение придуманное генератором случайных числе намного лучше, чем 0, до сих пор принимавшийся по умолчанию в гипотезах по управлению проектами.
Развивать общение между членами команды, чтобы потеря одного из сотрудников не оказалась критичной.
Создать для сотрудников комфортную среду, чтобы не было желания ее покинуть.
Этот риск относится к краху процесса переговоров по установлению требований, которые идут в начале любого проекта. Если он реализуется, т.е. стороны не договорились между собой о требованиях, то проект закрывается.
Подсказка: установите вероятность наступления риска.
Используйте выделенного менеджера или руковоителя для разрешения противоречий и конфликтов между сторонами.
Закон Паркинсона гласит, что «Работа заполняет время, отпущенное на неё». Следствие из этого закона: команда разработчиков активизируется только к концу срока сдачи проекта, а в остальное время работает в полсилы.
Подсказка: этот фактор, как правило, сбалансирован, т.е. одинакова вероятность как позитивных, так и негативных изменений производительности. Наихудшее и наилучшее значения задержки равны по модулю.
Разбейте проект на короткие этапы, постоянно вызывая ощущение скорого дедлайна.