5.6Формальное закрытие проекта
Сравним формальное закрытие проекта с проектом "без конца".
Проект с формальным завершением обладает очень высокой предсказуемостью и управляемостью.
Можно достаточно точно определить бюджет и сроки проекта. Формальный проект повышает ответственность сторон, все ожидания и соглашения документированы.
Проект без формального ведения обычно мало управляем по срокам и бюджету. Если формализованный проект подвержен значительному риску на этапе постановки, то неформальный проект, в силу неопределенности задач, подвержен риску на всем протяжении.
Тем не менее, многие предпочитают неформальное ведение проектов. Этот объясняется влиянием политических рисков. Формальный проект позволяет установить ответственность, и эта ответственность часто пугает как исполнителя проекта, так и заказчика. За неудачу формального проекта несут ответственность в равной степени и Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя ответственность, причем эта ответственность носит личный характер.
Обычно ситуация безответственности не устраивает только топ-менеджеров, именно они и могут своим волевым решением привести ситуацию в норму. Оптимально, если это происходит до начала проекта, а не по ходу его.
В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об измеряемых критериях завершения проекта.
5.7Закрытие и оценка проекта
Менеджер поставил в план разработку документа, описывающего контрольные тесты.
Далее в соответствии с тестами продукт был приведен в порядок и в срок сдан заказчику.
К
ак
видно по рисунку, проект примерно в 2
раза превысил ожидаемую себестоимость.
Тем не менее, следует отметить, что в условиях нашего примера проект был для менеджера новым и подвергался влиянию политических рисков. Достигнутый результат в данных условиях можно считать хорошим (нормальным). Данный вывод подтверждается и статистикой Standish Group: 53% проектов завершаются успешно, но с превышение бюджета в 1,9 раза.
5.8Анализ статистики
После завершения проекта необходимо вычислить статистические показатели для последующего прогнозирования сроков: соотношение стадий, типовые длительности, стоимости и т.д.
Именно поэтому важно разделить план на технологические стадии, состав которых независит от вида проекта.
5.9Что показывает статистика?
Приведем типичные статистические показатели Канера-Фолка и прокомментируем их относительно нашего примера.
Продукт получается в среднем через 8 внутренних и 3 внешних версии. Из этого следует, что стоит планировать 8 версий, и, скорее всего, потребуется несколько проектов. Об этом мы уже говорили выше.
Для разработки ПО характерны следующие статистические показатели соотношения технологических стадий:
Разработка - 37% Сопровождение - 63%
Этап разработки разделяется на стадии со следующими пропорциями:
Постановка - 34% Кодирование - 21% Тестирование - 45%
Если рассмотреть наш пример, то мы увидим, что данная статистика работает. Однако если мы посмотрим на первоначальный план, то увидим несоответствие трудоемкости стадий плана средним статистическим показателям.
Совет. Проверяйте план на соответствие статистике!