Пять критериев успешности ИТ проекта

I'm fine.I'm just not happy!Пример 1. Проект по разработке web-сайта для завода по производству мебели был завершен с опозданием на 2 месяца. Заказчик и руководство посчитали, что опоздание в 2 месяца в полугодовом проекте — достаточное основание для того, чтобы признать работу руководителя проекта неуспешной. С работы его, конечно, не уволили, но «осадочек остался».

Пример 2. Проект по созданию программного продукта для дистрибьюторской компании, создающий новый стандарт качества в обслуживании потребителей, идет второй год, хотя длительность проекта определили не более одного года. Тем не менее, Заказчик проекта считает, что проект будет определен как «успешный», даже несмотря на такое опоздание.

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

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

Как-то давно на заседании Совета Директоров  руководитель одного проекта попросил закрыть его проект со статусом «завершен успешно» (ну, хотел парень себе в резюме красивое словцо вставить). В итоге ему отказали, сославшись … на ошибку в каком-то из отчетов и опоздании проекта на месяц по независящим от руководителя проекта причинам. Но с того момента в Устав проекта я вставляю табличку «критерий успешности — способ проверки», чтобы исключить такие недоразумения.

Кстати, ранее я уже описывал алгоритм из шести шагов по закрытию проекта. Алгоритм касался всех типов проектов, а не только ИТ. Прочитать можно здесь «Шесть шагов закрытия проекта».

Теперь я приведу критерии успеха ИТ-проекта, которые часто применяю на практике:

#1 Реализованы ключевые функции системы

Это хороший критерий, который ориентирован на потребности заказчика получить качественный продукт. Как правило у заказчика есть какой-то основной бизнес-процесс, который он хочет автоматизировать (например, автоматизированный прием и регистрация звонков оператором call-центра). Здесь нужно перечислить функции, без которых запуск системы будет нецелесообразным. Вы посмотрите, что на самом деле только половина запрошенного функционала по-настоящему влияет на успех проекта.

В чем сложность написать «все функции системы реализованы»? Сложности нет, но опыт говорит, что такой «общий критерий» подходит только для небольших (до 3-4 месяцев) или типовых проектов. В маленьких проектах функциональность продукта можно подробно описать и позже проверить ее. А в типовых проектах вся функциональность по-умолчанию подробно описана и выверена. В противном случае, сдача «всей» функциональности может стать настоящей проблемой для вас как руководителя проекта.

Что же делать с остальной «неключевой» функциональностью? Не учитывать при оценке успешности ИТ-проекта? Да, не учитывать. Требование «Данные в отчете должны группироваться и выделяться цветом», безусловно, важно, но бизнес-ценности несет в себе мало. Но автоматический обмен данными между двумя системами — действительно ключевой функционал и в первую очередь спрашивать будут за его выполнение. Опытные руководители проектов знают это. Можно убедить заказчика на реализацию «фантиков» в следующем релизе или вообще их не делать.

Кстати, одна из причин популярности «гибких» методик управления проектами заключается в их итерациях, которые создают ценность для заказчика. Вот была статья на эту тему «Agile-принципы в проектах разработки программного обеспечения«.

#2 Дата ввода в эксплуатацию

Все заказчики требуют соблюдения сроков. Забегая вперед, скажу, что срок всегда (!) важнее денег, потому что время нельзя заработать, а можно только потратить.

время нельзя заработать, а можно только потратить

Заказчик любит устанавливать deadline и хочет, чтобы весь проект был завершен к такой-то дате. Здесь есть нюанс. Формулировкой «проект должен быть завершен к дд.мм.гггг» заказчик передает команде проекта все риски, связанные с нечеткой постановкой задачи, длительными согласованиями и принятием решений и т.п. Мой опыт говорит, что для Заказчика чаще важны одна или две контрольные вехи, чем срок завершения всего проекта. Поэтому в расписании проекта у меня вехи «система запущена в эксплуатацию» и «проект завершен» могут не совпадать друг с другом. Есть хороший пример на эту тему.

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

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

#3 Количество активных пользователей в системе

Очень хороший критерий, который позволяет проверить качество внедрения ИТ — системы.  Возможно кто-то удивится, но статистика моего опыта такова: только каждая третья информационная система по-настоящему востребована пользователями после внедрения. Сколько я видел случаев, когда после внедрения в систему входит всего 3-5 человек (при заявленных 10 и больше). Для того, чтобы проверить выполнение этого критерия потребуется провести аудит использования информационной системы, например, через месяц-два после сдачи проекта. Понятно, что это хлопотно, но зато критерий очень показательный.

У меня был такой случай, когда в одной крупной банковской группе 5000+ человек заявили о первом опыте в России по использованию инновационной информационной системы. Мне удалось напроситься в гости и лично посмотреть что и как. В итоге разочарование: количество активных пользователей составило 4 человека. Показательно, неправда ли?

#4 Бюджет проекта не превышен

Слабый критерий, который не всегда корректно характеризует успех проекта. В качестве интересного примера дам вам «негласный» вариант оценки успешности проекта с точки зрения бюджета: бюджет проекта должен быть использован на 99%!

бюджет проекта должен быть использован на 99%

Это связано с тем, что недоиспользование бюджета (очень большого бюджета) проекта говорит о том, что:

  • вы как руководитель проекта — лох плохой менеджер, так как не умеете планировать затраты. Этот «грешок» вам простят.
  • эти деньги могли бы быть реинвестированы в другой проект или просто лежать на депозите в банке (сейчас под 45% годовых!) с гораздо меньшим риском. Этот «промах» в крупной организации вам не простят. Отговорка, что вы сэкономили деньги в проекте, не сработает.

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

Соблюдение бюджета — хороший критерий, если в проекте участвует заемное финансирование.

#5 Совокупная эффективность основного и вспомогательного процессов

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

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

 

Надеюсь, что информации к размышлению у вас достаточно. Буду рад, если вы предложите иные критерии успеха ИТ-проекта, который вы использовали в своей карьере.

Желаю удачи.