Top 20 bad practice в оценках проектов
или как методология оценок сначала убивает продажи, а потом проекты

В последнее время вокруг меня красной линией крутится одна тема - оценка проектов.
Методологии оценки всегда были моим самым любимым доменом в управленческих фреймворках. Мне по-настоящему, до мурашек, нравилось разбираться в деталях стандартов, логике гайдлайнов, скрытых допущениях и границах применимости. Я отношу себя к специалистам, владеющим методологиями оценки на экспертном уровне сразу в трех подходах - PMI, PRINCE2 и Agile.
Agile в этой тройке стоит немного отдельно. В реальности он чаще отвечает за оценки внутри проекта - для команд, спринтов и продуктовой разработки.
А вот когда речь заходит о продажах, контрактах, обязательствах, деньгах и сроках, почти всегда приходится опираться на логику PMI или PRINCE2, даже если дальше проект живет в Agile.
И вот самый частый сценарий, который я наблюдаю годами.
Методология оценки сначала мешает конверсии продаж, а затем превращается в самосбывающееся пророчество. Возникает замкнутый loop:
- мы составляем оценку, где большая часть зашита в мертвых процентах
- без управления рисками
- без нормальной WBS
- без разделения вероятности, риска и структуры работ

Оценки раздуваются до таких размеров, что проекты продаются раз в спас.
Мы разучиваемся попадать в меньшие оценки, потому что продаем только те проекты, которые по структуре и так имеют максимальную вероятность успеха.
А потом, через некоторое время, перестаем попадать даже в них.
Вернуть управляемость в оценки - одна из самых масштабных и сложных задач трансформации PMO.
Она требует переборки почти всей цепочки продакшена. И, как в случае с внедрением производственной системы Toyota, никогда не встречает поддержки внутри трансформируемой организации. Это всегда путь через слом привычных ролей, власти и иллюзий контроля.

Ниже - 20 bad practice, которые чаще всего делают оценки неуправляемыми.

1. Путать классы оценок
Иметь данные, достаточные для оценки уровня Class 2, а пытаться продавать точность уровня Class 4.
Или наоборот - брать на себя обязательства, имея на руках только ROM.

2. Использовать методологию оценки как алиби, а не как инструмент
Когда сложность модели и количество коэффициентов нужны не для управления неопределенностью, а чтобы объяснить, почему проект нельзя сделать иначе.
Оценка перестает быть способом принять решение и становится способом ничего не решать.

3. Продавать одну цифру вместо диапазона
Оценка - это распределение вероятностей, а не число.
Одна цифра всегда ложь. Просто иногда удобная. И не только в продаже, но и в получении ее от исполнителя.

4. Путать вероятность с риском
P80 - это не contingency. Это уровень уверенности, а не запас на события.

5. Считать, что three-point "учел все риски"
O и P учитывают вариативность выполнения задач. Проектные риски туда не входят.

6. Делать contingency равной tolerance
Когда управленческая граница подменяется математикой рисков, эскалация всегда происходит слишком поздно.

7. Отсутствие tolerance как таковой
Если границы допустимых отклонений не зафиксированы заранее, проект узнает о проблеме в последний момент.

8. Расширять add-ons за счет выдуманных SDLC фаз
Чего я только не видел:
- заложенные проценты на коммуникации при уже учтенном часе PM
- QA включен, но поверх добавляется "фаза балансировки кода" как риск
- аналитик и архитектор в оценке есть, но отдельно добавляется процент на изменение требований
Это не зрелая оценка. Это раздувание без ответственности.

9. Закладывать коммуникации сквозным процентом на весь проект
Коммуникации - это режим работы ролей, а не отдельный scope.
Сквозной процент почти всегда дает двойной счет.

10. Путать add-ons и риски
QA, PM, analysis - это структура работ. Риски начинаются после того, как структура учтена и не подменяют ее.

11. Использовать add-ons вплоть до Class 1
Когда на уровне детальной оценки большая часть расчетов ложится не на scope, а на коэффициенты, сопоставимые с Class 4 или 5, оценка перестает быть инженерной.