О том, почему бизнес-ценность и успешное завершение проекта - это не всегда одно и то же

Представьте себе компанию, которая реализует IT проекты по классическому waterfall. Бизнес придумывает идею, аналитики превращают ее в требования, разработчики реализуют функционал, а тестировщики его проверяют. При этом проекты бывают самые разные, от мелких правок на формах информационной системы до глобальной смены бизнес-процессов. 

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

Сразу становится понято, что оценивать будет непросто: 

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

Еще месяц уходит на проработку вопросов от разработки аналитикам, в итоге оценка все-таки подготовлена. 

После этого начинается важнейший с точки зрения проектного менеджмента процесс: разработка план-графика проекта. Задача не из легких: несколько команд разработки и тестирования, десятки участников, и жесткий дедлайн от бизнеса. План получается грандиозный: работы каждого участника расписаны на полгода вперед.
Дата выпуска назначена, поехали! 

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

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

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

И получается следующая ситуация:

с точки зрения проектного управления:

• проект выполнен
• цели проекта достигнуты
• все изменения в сроках и объеме работ "штатно" согласованы,
• качество соответствует нормам.

с точки зрения бизнеса:

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

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

Такой вот интересный пример применения предиктивной методологии к проекту с высокой степенью неопределенности. Я думаю, мы к нему еще вернемся, но уже в следующих статьях.