Assessing IT Project Success: Perception vs. Reality
Разбор статьи ACM Queue о пересмотре критериев успеха IT-проектов: от project triangle к клиентской ценности и подтвержденным бизнес-выгодам.
Практика чтения для этого источника ещё не опубликована
Ниже доступен готовый редакционный brief из прежнего каталога. Он даёт контекст, но не засчитывается как lab.
Открыть оригиналГотовый редакционный разбор
Он сохранён из прежней версии каталога и расположен после самостоятельной практики, чтобы не подменять чтение оригинала готовым пересказом.
Primary Source
Assessing IT Project Success: Perception vs. Reality
ACM Queue: исследование о пересмотре критериев успеха IT-проектов.
Primary Source
Assessing IT Project Success: Perception vs. Reality
ACM Queue: исследование о пересмотре критериев успеха IT-проектов.
Статья из ACM Queue ставит под сомнение привычный тезис о «массовом провале IT-проектов». Авторы показывают, что при более широких критериях многие проекты демонстрируют устойчивый успех, особенно если смотреть на результат для клиента и подтвержденные выгоды после завершения.
Для исторического контекста часто цитируют The CHAOS Report (1994), где успех трактовался главным образом через project triangle.
Основа главы
Пост в tg-канале #2838
Краткий разбор исследования и его практических выводов.
Основа главы
Пост в tg-канале #2838
Краткий разбор исследования и его практических выводов.
Как меняется понимание успеха
Классический подход
Успех = проект завершен в срок, в бюджет и с исходным scope.
Расширенный подход
Успех = выполнение ограничений проекта + реальный эффект и удовлетворенность ключевых сторон.
Дополнительные критерии из исследования
- Level of global success achieved.
- Level of compliance with scope, time, and cost.
- Level of vendor (supplier) satisfaction.
- Level of client satisfaction.
- Deliverables impact.
- Achievement of benefits verified in the project.
Методология исследования
Выборка
~200 анкет
Опытные менеджеры IT-проектов из разных отраслей и регионов.
Инструмент оценки
Шкала Лайкерта
Детализированная анкета сочетала субъективные и объективные критерии.
Ограничение по времени
> 6 месяцев после завершения
Чтобы оценить устойчивость результата на постпроектной стадии.
Post-project сигналы, которые дополнительно проверяли
- Использование результатов проекта на постпроектной стадии.
- Найм клиентом специалистов для поддержки/эксплуатации решения.
- Новые контракты с тем же подрядчиком.
- Готовность клиента рекомендовать подрядчика.
Основные результаты
90.16%
Проекты выше среднего уровня успеха
61.66%
Проекты в двух верхних уровнях успеха
~200
Заполненные анкеты
Вопреки популярной риторике о системных провалах, большая часть проектов в выборке показала высокий уровень успеха по глобальной оценке и по расширенным критериям.
Удовлетворенность клиента
ρ = 0.714
Достижение выгод для клиента
ρ = 0.751
Удовлетворенность подрядчика
ρ = 0.653
Сильная связь глобального успеха с клиентской ценностью подтверждает, что ориентация на outcomes для клиента является ключевым индикатором результативности проекта.
Практический контур для management
- Оценивать успех проекта не только по срокам/бюджету/scope, но и по проверяемым бизнес-выгодам.
- Считать post-project сигналы частью финальной оценки результата.
- Собирать оценку с разных сторон: клиент, подрядчик, конечные пользователи, спонсоры.
- Смещать фокус управления от «доставили вовремя» к «получили полезный и устойчивый outcome».
В прикладной интерпретации это хорошо ложится на продуктовый подход: проект завершает delivery-фазу, а реальный успех проявляется в том, как созданный продукт работает для бизнеса и пользователей после релиза.
Связанные главы
DevOps Metrics. Your biggest mistake might be collecting the wrong data
Почему управленческие выводы страдают, если измерять только удобные метрики.
Как собираются отчеты DORA
Разбор survey-методологии, валидности конструктов и causal inference.
Measuring Productivity: All Models are Wrong But Some are Useful
Практика многомерных моделей вместо одного KPI.