Почему резерв в 20% не спасает IT-проекты: что исследование "тяжёлых хвостов" говорит об оценке стоимости проектов

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

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

Это исследование помогает понять, почему стандартные резервы часто не работают и каким образом необходимо подходить к оценке и управлению рисками.

Что исследовали авторы

Исследователи проанализировали 5392 IT-проекта различного масштаба и назначения. Их интересовал не средний перерасход бюджета, а распределение отклонений от первоначальных оценок.

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

Таким образом, достаточно добавить к бюджету разумный резерв (например 15-20%) и большая часть рисков была бы покрыта.

Однако данные показали совершенно другую картину. Авторы обнаружили, что распределение перерасходов имеет так называемый «тяжелый хвост». Это означает, что вероятность очень больших отклонений намного выше, чем предполагают традиционные методы планирования. 

Иными словами, проекты с перерасходом в 100%, 200% или даже 400% встречаются значительно чаще, чем ожидают менеджеры и заказчики.

Что такое тяжелый хвост

Представим себе распределение по росту людей. Люди ростом 170-190 см встречаются часто. Люди ростом 210 см встречаются редко. Люди ростом 250 см практически не встречаются вообще.

Такое распределение имеет тонкий хвост: вероятность экстремальных значений быстро стремится к нулю.

С проектами все оказывается иначе. Если один проект превысил бюджет на 30%, другой на 50%, а третий на 70%, то может показаться, что перерасход в 300% практически невозможен. Но данные показывают обратное: чем сложнее система, тем чаще возникают экстремальные события. Для таких распределений характерно наличие тяжелого хвоста, т.е. области, где вероятность крупных отклонений снижается значительно медленнее, чем ожидается. 

Рисунок 1. Вероятностное распределение перерасхода средств (фактическая стоимость, деленная на оценочную стоимость) для 4677 ИТ-проектов.

 

Следствие этого факта крайне важно: Средний перерасход перестает быть надежным ориентиром для управления рисками.

Основную опасность создают не десятки небольших отклонений, а несколько редких, но очень крупных перерасходов. Именно они способны полностью изменить экономику проекта.

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

Одной из наиболее интересных частей исследования стала попытка объяснить механизм возникновения крупных перерасходов. Для этого авторы использовали известную модель лесного пожара.

Представьте себе лес, состоящий из большого количества деревьев. Периодически возникает искра (напрмер, из-за молний). В большинстве случаев загорается одно дерево или небольшой участок леса. В таком случае ущерб оказывается минимальным.

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

Однако можно определить статистические закономерности возникновения крупных пожаров. Изначально большинство проблем оказываются локальными:

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

Но зачастую локальная проблема затрагивает множество зависимостей одновременно. Тогда запускается цепная реакция:

  • пересматриваются требования;
  • меняется архитектура, подходы;
  • появляются дополнительные интеграции;
  • растет объем тестирования;
  • увеличивается количество дефектов;
  • смещаются сроки других команд.

Небольшая проблема начинает распространяться по системе подобно лесному пожару. Именно такие события формируют тяжелый хвост распределения.

Какие проекты наиболее подвержены тяжелым хвостам

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

  • крупные корпоративные информационные системы;
  • программы цифровой трансформации;
  • проекты с большим количеством интеграций;
  • проекты модернизации устаревших систем;
  • платформенные продукты с несколькими командами разработки;
  • государственные и банковские IT-проекты;
  • проекты, в которых принимает участие несколько команд (подрядчики, субподрядчики).

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

Почему резерв в 20% часто не работает

Во многих организациях существует простое правило: "Добавим к оценке 20% запаса и будем считать риски покрытыми". Этот подход основан на предположении, что ошибки оценки распределяются относительно равномерно.

Но если распределение имеет тяжелый хвост, ситуация меняется. Представим проект стоимостью 1 миллион рублей. Резерв в 20% увеличивает бюджет до 1,2 миллиона. Если фактический перерасход составит 10% или 15%, резерв действительно поможет.

Но если проект попадет в область тяжелого хвоста и перерасход составит 80%, 150% или 300%, такой резерв окажется практически бесполезным из-за самой нелинейной природы риска увеличению сроков и бюджета проекта.

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

Что это означает для оценки проектов

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

  • что произойдет при благоприятном развитии событий?
  • что произойдет при реалистичном сценарии?
  • что произойдет при возникновении ключевых рисков?
  • какие факторы способны вызвать каскадный рост трудоемкости?
  • а что если в проекте есть зависимости, способные изменить на проекте буквально все?
  • какова вероятность, что функциональные и нефункциональные требования проекта истолкованы неправильно?

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

Как помогает сценарный анализ

Сценарный анализ позволяет моделировать различные варианты развития проекта еще до начала работ. Например, можно оценить влияние:

  • изменения требований;
  • нехватки ключевых специалистов;
  • проблем интеграции;
  • низкого качества исходных данных;
  • технического долга;
  • зависимости от внешних подрядчиков;
  • различные способы реализации проекта.

Каждый такой фактор способен увеличивать трудоемкость проекта на определенную величину.

Вместо единственной оценки организация получает несколько сценариев:

  • оптимистичный;
  • базовый;
  • консервативный;
  • стрессовый.

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

Практические рекомендации

Исследование показывает, что крупные перерасходы не являются редкими исключениями. Они представляют собой естественное свойство сложных систем.

Поэтому при оценке проектов рекомендуется:

  1. Не ограничиваться одной итоговой цифрой оценки;
  2. Анализировать диапазон возможных значений стоимости и сроков;
  3. Выявлять факторы, способные вызвать каскадное увеличение трудоемкости;
  4. Использовать сценарный анализ вместо фиксированных резервов;
  5. Использовать специализированные инструменты для оценки трудоемкости и стоимости ИТ проектов;
  6. Уделять особое внимание крупным интеграционным и трансформационным проектам;
  7. Рассматривать риски как часть модели оценки, а не как отдельное приложение к проекту;
  8. Выявлять триггеры “лесного пожара”, следить за их показателями.

Заключение

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

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

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