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

По сложившейся традиции успешным ИТ-проектом считается тот, который был выполнен в срок, в рамках бюджета и в соответствии с техническим описанием. Как показывает практика, воплотить данный стандарт — дело непростое. Согласно продолжительному исследованию, проведенному консультационным агентством The Standish Group в 2004 году, из нескольких тысяч изученных ИТ-проектов только 29% можно назвать успешными.

Очевидно, что критерии оценки успешности ИТ-проектов должны быть пересмотрены. Начиная с 1999 года, в рамках дипломной практики студентами-выпускниками, защищавшими степень магистра наук в области управления ИТ в Школе коммерции Макинтайра при университете штата Вирджиния, были проведены 72 исследования в 57 компаниях. Эти исследования показали, что даже проекты, которые соответствуют всем традиционным критериям успеха — время, бюджет и техническое описание, — могут в конечном итоге оказаться обреченными на провал. Дело в том, что далеко не все так называемые успешные проекты соответствуют ожиданиям и требованиям конечных пользователей, кроме того, они могут не приносить компании никакой пользы.

Когда успех оборачивается неудачей

Можно еще сказать «неудавшийся успех»… Например, компания, работающая в области недвижимости, успешно завершила двухгодичный проект по разработке CRM-системы на основе технологии Lotus Notes. В итоге эта система должна была создать стратегическое преимущество в сфере лизинга свободных площадей. Система полностью соответствовала техническому описанию, однако вписать ее бизнес-процессы компании не удалось. Вот как говорит об этом технический директор компании: «Для удовлетворительной работы данного приложения требуется 100-процентное задействование человеческих ресурсов, в противном случае его эффективность снижается до нуля».

Точно так же проекты, которые по традиционным стандартам оцениваются как несостоятельные, могут оказаться вполне успешными, поскольку в конечном итоге разработанная система может принести неожиданную пользу компании или полюбиться ее непосредственным пользователям. Например, в компании, работающей на рынке финансовых услуг, новая система, используемая для быстрой разработки, проверки, развития и оценки новых стратегий в области налогообложения, в итоге обошлась в два раза дороже, чем это было запланировано (ее конечная стоимость составила 5,7 млн. долл.). Однако реализация данного проекта привела спустя 13 месяцев к полному преобразованию бизнес-процесса — он стал более гибким, — а сам проект был признан одним из крупнейших достижений ИТ-отдела. При этом расходы компании сократились на 33 млн. долл., а увеличение мощностей привело к 50-процентному увеличению результативности при оценке конкурентных стратегий в области налогообложения.

Новый критерий успеха

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

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

Польза. Проект приводит к повышению производительности и росту эффективности деятельности компании (общие параметры, включающие NPV — метод чистой приведенной стоимости, IRR — метод внутренней доходности, EVA — метод экономической добавленной стоимости, а также сбалансированную систему показателей деятельности).

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

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

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

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

Преимущества ретроспективного анализа

Правильно проведенный ретроспективный анализ имеет ряд преимуществ. Подробные обзоры позволяют участникам процесса выйти за рамки своих собственных ощущений и более объективно взглянуть на проект. Таким образом, проект, который был «ночным кошмаром» для уработавшегося вконец менеджера, может, в конечном итоге, принести компании немалую пользу. Кроме того, подобные анализы создают основу для усовершенствования процессов, методик и общей культуры, чего не происходит, если каждый проект рассматривается отдельно. В этом случае уроки предыдущих проектов забываются или игнорируются. Анализ завершенных проектов дает реальные данные по объему инвестирования, человеческих и временных затрат, необходимых для
успешного завершения проекта. Что, в свою очередь, позволяет провести более объективную оценку и планирование последующих проектов.

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

Ретроспективный анализ проекта позволяет изменить сроки проекта. Хотя, возможно, перейти на новый тип мышления будет непросто. При оценке проектов менеджеры должны найти компромисс между критериями оценки процесса (время, стоимости и технические условия) и результата (применение, обучение и польза для компании). Таким образом, устав проекта должен содержать общие показатели успеха, в текущих отчетах должны приводиться показатели реализации в режиме реального времени, а ретроспективный анализ должен отражать фактические результаты, в том числе оценку успешности проекта с точки зрения участников процесса.

ИТ-подразделению приходится постоянно сражаться с неуменьшающимся количеством провалившихся проектов. При этом ключ к увеличению показателя успешности проектов практически у них в руках. Просто нужно время от времени посматривать в зеркало заднего вида.

R. RYAN NELSON. Tracks in the Snow. CIO MAGAZINE. SEPTEMBER 1, 2006