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

Альтернативой формальному завершению проекта является бесконечное движение в сторону ожиданий. Рассмотрим, что может получиться в данном случае:

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

2) Существуют рамки возможностей технологии. Например, ожидания пользователей по скорости работы программы, может быть невозможно не удовлетворить с помощью современных технологий.

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

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

Формальное закрытие проекта

Сравним формальное закрытие проекта с проектом "без конца".

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

Можно достаточно точно определить бюджет и сроки проекта. Формальный проект повышает ответственность сторон, все ожидания и соглашения документированы.

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

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

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

В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об измеряемых критериях завершения проекта.

Закрытие и оценка проекта

Менеджер поставил в план разработку документа, описывающего контрольные тесты.

Далее в соответствии с тестами продукт был приведен в порядок и в срок сдан заказчику.

Как видно по рисунку, проект примерно в 2 раза превысил ожидаемую себестоимость.

Тем не менее, следует отметить, что в условиях нашего примера проект был для менеджера новым и подвергался влиянию политических рисков. Достигнутый результат в данных условиях можно считать хорошим (нормальным). Данный вывод подтверждается и статистикой Standish Group: 53% проектов завершаются успешно, но с превышение бюджета в 1,9 раза.

Анализ статистики

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

Именно поэтому важно разделить план на технологические стадии, состав которых независит от вида проекта.

Что показывает статистика?

Приведем типичные статистические показатели Канера-Фолка и прокомментируем их относительно нашего примера.

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

Для разработки ПО характерны следующие статистические показатели соотношения технологических стадий:

Разработка - 37%
Сопровождение - 63%

Этап разработки разделяется на стадии со следующими пропорциями:

Постановка - 34%
Кодирование - 21%
Тестирование - 45%

Если рассмотреть наш пример, то мы увидим, что данная статистика работает. Однако если мы посмотрим на первоначальный план, то увидим несоответствие трудоемкости стадий плана средним статистическим показателям.

Совет. Проверяйте план на соответствие статистике!