Есть довольно типичный сценарий. Бизнесу нужно изменение. Аналитик исследует задачу и формулирует требования. ИТ разрабатывает решение. Руководитель получает сообщение: готово. У каждого есть свой результат. А у проекта в целом — не всегда. Потому что между этими результатами остаются переходы: кто проверит решение с реальными пользователями; кто изменит инструкции и ответственность; кто обучит сотрудников; кто убедится, что старый порядок действительно прекратился; кто проверит эффект после запуска.

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

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