Оценка значимости рисков
Проект обычно подвержен очень большому количеству рисков, запланировать мероприятия по борьбе со всеми практически невозможно. Что же делать? Следует обратиться к статистике. Нужно посчитать, какие виды рисков вызывают наибольшее количество проблем. На рисунке приведен график дефектов продукции в зависимости от видов дефектов.
График дефектов продукции в зависимости от видов дефектов
Видно, что работает правило 80/20. Примерно 20% рисков создают 80% угрозы. Именно на них следует обращать основные усилия. В технологичных проектах обычно риски предотвращаются обучением, контролем и поддержанием качества (тестированием).
Для того, чтобы эффективно бороться с рисками, нужно вести статистический учет возникающих проблем по видам рисков. В данном качестве может быть использована система учета дефектов продукции. В случае если статистика отсутствует как класс, рекомендуется обратиться к экспертам (компании или внешним)
Кроме негативных рисков, необходимо также учитывать положительные возможности, которые могут возникнуть при исполнении проекта
Методы вычисления реальных сроков задач
Риск проекта – это неопределенное событие или условие, которое в случае наступления может повлиять на показатели проекта.
Исследования показали, что вероятность успешной реализации проекта, параметры которого определены на базе того, как бывает обычно, колеблется в диапазоне 20-38%, поэтому учет рисков и неопределенностей имеет огромное значение на всех стадиях управления проектом.
Для моделирования рисков в проекте необходимо разработка трех версий реализации проекта:
• оптимистическую, базирующуюся на оптимистических оценках параметров проекта и включающую наиболее вероятные события риска (вероятность наступления которых выше 90%);
• наиболее вероятную, включающую просто вероятные события риска (вероятность наступления которых выше 50%) и обычные оценки параметров проекта;
• пессимистическую, включающую отобранные при качественном анализе значимые события риска (вероятность наступления которых ниже 50%) и пессимистические оценки параметров проекта.
Так как это часто бывает оценки сотрудников недостоверны, и узнать полный состав работ невозможно.
Выходом является использование статистических методов прогнозирования. Рассмотрим типовые приемы:
1. В Microsoft Project просто добавляют 30% к общей длительности плановых задач (Buffer time в 30%). Этот резерв расходуется на покрытие рисков.
2. Метод Load Factor (или на сколько умножить слова ответственного за определение сроков), рекомендуемый группой XP. Статистический анализ проектов в малых группах разработки показал, что можно достаточно точно узнать реальный срок задачи, просто умножив слова исполнителям на некий коэффициент. Вот ориентировочные значения коэффициента:
• умножить на 2 - оптимистичная оценка;
• умножить на пи - нормальный проект;
• умножить на 4-5 - применение нестандартных технологий.
3. Схема PERT вычисления реального срока. Часто бывает, что разные оценки дают разные сроки; в этом случае можно применить метод расчет реального срока по следующей формуле:
• Реальный_Срок=(Оптимистичный_Срок+4*Ожидаемый_Срок+Пессимистичный_Срок)/6.
Коэффициенты в данной формуле (4 и 6) получены путем анализа статистики большого количества проектов. Следует отметить, что схема PERT эффективна только в том случае, если действительно имеются различные оценки. Если менеджер хочет через PERT просто убедить себя, что его решение единственно правильно, то подгонка статистики не даст ничего, кроме положительного ответа.
Метод PERT никогда не рассматривался как профессиональный метод анализа воздействия рисков. Этот метод хорош только для очень грубой прикидки возможного влияния рисков. Для чистовых расчетов во всем мире пользуются Монте-Карло. В PMBOK 4й редакции PMI указал, что PERT обычно дает серьезные ошибки по проекту в целом, а также часто занижает сроки.
Кроме указанных теоретических ограничений PERT также имеет ограничения по реализации в Microsoft Project. Метод не умеет оптимизировать бюджеты, а также в документации Microsoft Project указано на ограничения по результатам для суммарного уровня: « Анализ по методу PERT, выполняемый приложением Microsoft Project, фокусируется на уровне задачи. Данные суммарного уровня и общие данные о проекте недостоверны для анализа с помощью приложения Microsoft Project».
Итог по основным недостаткам PERT:
1. Низкая точность расчетов PERT.
2. Недостоверность результата при смене весовых коэффициентов.
3. Типично занижение сроков PERT, т.к. PERT отточен для вероятности всего 50% для выполнения проекта. Такой уровень риска обычно неприемлем.
4. PERT в MS Project не умеет оптимизировать бюджеты, только сроки.
5. Реализация метода PERT в MS Project ограниченная, корректные результаты только на уровне задач.
В Microsoft Project 2010 метод расчета PERT не используется.
6. Методика Монте Карло. Системы моделирования рисков на базе Монте Карло более точны чем PERT (точность выше примерно на 10%), плюс такие средства позволяют задавать уровень риска в проекте. Примером такого средства для Microsoft Project является Turbo Risk Manager, который мы рассмотрим ниже.
Приведенные статические коэффициенты являются лишь ориентировочными. Необходимо накапливать свою собственную статистику по ведению проектов для того, чтобы получить специфические для данной технологии и данных исполнителей калибровочные коэффициенты