Обычно после тщательной проработки сроков на основе достоверной статистики проект идет более-менее в графике до тех пор, пока не подходит к своему завершению, в этот момент на него начинают влиять новый вид риска-политический. Рассмотрим технику завершения проектов и некоторые корректирующие воздействия.
В нашем примере проект подошел к концу, но проект завершить в срок не удается. Сотрудник пытается сдать проект, но вместо этого появляется новая задача от заказчика.
Подобная ситуация является типичным признаком потери контроля. Это понял и заказчик, назначив крайний срок сдачи (Dead Line). В MS Project 2000 существует средство для отметки Dead Line и оповещении о подходе к нему.
Рассмотрим причины потери контроля и способы его восстановления.
Следует помнить правило 80/20. Иными словами 80% работы делаются за 20% времени (см. рисунок). Как следствие, первые успехи могут вскружить голову и можно потерять ощущение реальности. Это является особенностью человеческой психологии и характерно для большинства людей. В этом заключается, однако, одна из причин заниженных исполнителями оценок сроков.
Менеджер должен помнить, что, возможно, потребуется провести значительные работы по поднятию качества до потребительского уровня.
В нашем случае менеджер зарезервировал необходимое время на обеспечение качества. Возникшие причины проблем носят политический характер. Рассмотрим их.
Если проанализировать ситуацию, видно, что фактически происходит изменение задания (задач) проекта в результате процедуры приемки. На рисунке приведен цикл изменения плана при корректировке задач по методике PMI.
Если задачи проекта не были документированы или если заказчик проекта настаивает на новых задачах без коррекции плана, то ситуация неуправляема. Скорее всего, проект пойдет на самотек, или Исполнитель откажется вести проект себе в убыток.
Требование и план неразрывны, это простое положение не так просто достигается на практике. Очень часто Заказчик только на сдаче проекта обнаруживает, что требования к проекту и его ожидания - несколько разные вещи. Часто Заказчик начинает настаивать именно на выполнении своих ожиданий.
В нашем случае причина в другом. Менеджер предусмотрел в плане работы по составлению задания и утвердил его у Заказчика. Заказчик был заранее предупрежден, что многие его ожидания в данном проекте реализованы не будут. Для правильного планирования необходимо завершить этап постановки задач. Это было сделано. Проблемы заключаются в другом.
Меня
критикуют
Замечание
1. Необходимо изначально ставить измеримые
цели, чтобы избежать субъективизма при
оценке, исполнен проект полностью или нет.
С этим не спорю, я намерено пропустил этот шаг в начале своего примера, чтобы показать последствия данной ошибки и как можно ее постараться исправить по ходу дела.
Замечание
2. Если заказчик начинает настаивать на
выполнении своих ожиданий, нужно их
оформить как дополнительное соглашение к
Договору.
Если заказчик согласен, то проблем нет. Однако если есть возможность, заказчик воспользуется своим правом на трактовку неоднозначных описаний в задании. Это еще раз подтверждает необходимость измеряемых критериев приемки работ, как средство ухода от различных толкований задания и потенциального конфликта.
Итак, в заключаются настоящие проблемы данного проекта? Заказчик раздражен постоянным удорожанием проекта и спорит о толковании пунктов задания. Таким образом, разделим мотив и формальную причину.
Как мы видели выше, менеджер (исполнитель) сделал много ошибок в процессе планирования. Однако нельзя сказать, что вся ответственность за это лежит на нем. Дело в том, что невозможно было точно предсказать сроки задач в конце проекта без завершения первых задач. Например, выработка требований может изменить оценку трудоемкости разработки.
Более правильным является разложить этот большой проект на несколько небольших, но с гарантированным получением результата. Проблема состоит в том, что Заказчик, как правило, хочет знать сроки и цену на все сразу, т.к. отдельный этап работ представляется менее ценным, чем весь проект.
Единственное, что может сделать опытный менеджер в данном случае, это четко спланировать ближайший этап, а остальные определить статистически. Как видно из выше изложенного, статистика с учетом косвенных работ поражает воображение своей трудоемкостью на фоне иллюзии простоты.
Заказчик, получив большие статистически оценки, требует составить план работ из конкретных задач и начинает убирать оттуда "завышенные" и "ненужные" работы.
Если это произошло, проект обречен на потерю контроля.
В нашем случае проблема заключалась в том, что менеджер пытался сделать все в рамках одного проекта и статистические оценки стал применять только уже по ходу проекта.
Поговорим теперь о формальном завершении проекта. Чтобы не спорить о том, выполнено ли задание или нет, требуется определить измеряемые критерии достижения цели. В случае ПО это контрольные тесты. Измеряемые критерии позволяют формально завершить проект, разделив ожидания и требования.
Альтернативой формальному завершению проекта является бесконечное движение в сторону ожиданий. Рассмотрим, что может получиться в данном случае:
1) Ожидания по своей природе противоречивы, как и человеческие отношения. Многие желания логически несовместимы. Например, топ-менеджер хочет иметь больше аналитической статистики, а оператор хочет заполнять меньше аналитических полей. Удовлетворить оба эти ожидания логически невозможно, поэтому система, развивающаяся в данном направлении, может оказаться нерабочей из-за дефектов логики
2) Существуют рамки возможностей технологии. Например, ожидания пользователей по скорости работы программы, может быть невозможно не удовлетворить с помощью современных технологий.
3) Возможна и обратная ситуация, типичная для внутренних проектов компаний. Разработчики проекта увлечены технологией и математической логикой, при этом происходит потеря требований к ключевым ожиданиям заказчика. Результат получается, но не тот.
Успешное внедрение обычно происходит иначе. Проект обычно решает некий ограниченный круг согласованных задач. После их достижения формулируются новые задачи и выполняется новый проект. Таким образом, за несколько проектов все ключевые ожидания заказчика реализуются. При этом очевидно, что значительная часть ожиданий не будет реализована никогда. Однако заказчик получит не идеальный, но пригодный к эксплуатации продукт, возможно лучший продукт из возможных в данное время.
Сравним формальное закрытие проекта с проектом "без конца".
Проект с формальным завершением обладает очень высокой предсказуемостью и управляемостью.
Можно достаточно точно определить бюджет и сроки проекта. Формальный проект повышает ответственность сторон, все ожидания и соглашения документированы.
Проект без формального ведения обычно мало управляем по срокам и бюджету. Если формализованный проект подвержен значительному риску на этапе постановки, то неформальный проект, в силу неопределенности задач, подвержен риску на всем протяжении.
Тем не менее, многие предпочитают неформальное ведение проектов. Этот объясняется влиянием политических рисков. Формальный проект позволяет установить ответственность, и эта ответственность часто пугает как исполнителя проекта, так и заказчика. За неудачу формального проекта несут ответственность в равной степени и Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя ответственность, причем эта ответственность носит личный характер.
Обычно ситуация безответственности не устраивает только топ-менеджеров, именно они и могут своим волевым решением привести ситуацию в норму. Оптимально, если это происходит до начала проекта, а не по ходу его.
В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об измеряемых критериях завершения проекта.
Менеджер поставил в план разработку документа, описывающего контрольные тесты.
Далее в соответствии с тестами продукт был приведен в порядок и в срок сдан заказчику.
Как видно по рисунку, проект примерно в 2 раза превысил ожидаемую себестоимость.
Тем не менее, следует отметить, что в условиях нашего примера проект был для менеджера новым и подвергался влиянию политических рисков. Достигнутый результат в данных условиях можно считать хорошим (нормальным). Данный вывод подтверждается и статистикой Standish Group: 53% проектов завершаются успешно, но с превышение бюджета в 1,9 раза.
После завершения проекта необходимо вычислить статистические показатели для последующего прогнозирования сроков: соотношение стадий, типовые длительности, стоимости и т.д.
Именно поэтому важно разделить план на технологические стадии, состав которых не зависит от вида проекта.
Для получения сложной статистики (например, по персоналу) можно использовать связку MS Project и SQL Server. Это встроенная возможность MS Project 2000.
Приведем типичные статистические показатели Канера-Фолка и прокомментируем их относительно нашего примера.
Продукт получается в среднем через 8 внутренних и 3 внешних версии. Из этого следует, что стоит планировать 8 версий, и, скорее всего, потребуется несколько проектов. Об этом мы уже говорили выше.
Для разработки ПО характерны следующие статистические показатели соотношения технологических стадий:
Разработка
- 37%
Сопровождение - 63%
Этап разработки разделяется на стадии со следующими пропорциями:
Постановка
- 34%
Кодирование - 21%
Тестирование - 45%
Если рассмотреть наш пример, то мы увидим, что данная статистика работает. Однако если мы посмотрим на первоначальный план, то увидим несоответствие трудоемкости стадий плана средним статистическим показателям.
Совет. Проверяйте план на соответствие статистике!
Следует отметить, что мы рассмотрели только вопросы управления малой группой. Для внедрения технологии управления в масштабах предприятия нужно рассмотреть следующие вопросы:
1) MS Project Central как платформа группового управления
2) Межпроектное управление
3) Конфликты проектов по ресурсам и их предотвращение через Resource Pool
Данные вопросы мы рассмотрим в следующих статьях и специальных семинарах.
Управляемость
внедрения достигается формализаций и
автоматизацией проектной деятельности.
Для
достоверной оценки стоимости и рисков
необходимо иметь накопленную статистику по
различным параметрам процесса внедрения.
Чтобы накопить такую статистику,
необходимо провести достаточно много
проектов и замерить их фактические
параметры. Также следует учесть, что данная
статистика специфична и зависит от вида
внедрения, персонала, организационных
особенностей.
В
качестве эффективного средства
автоматизации ведения проектов можно
использовать MS Project 2000. Практика показывает,
что Microsoft Project способен вести учет проектной
информации, организовывать проектный
документооборот по принятию планов, а также
позволяет получить статистику для принятия
решений.
Общий
вывод. Проект, лишенный формального
управления, непредсказуем, однако
построение формализованного управления
проектами требует затрат времени и
ресурсов. Затраты эти достаточно велики.
Поэтому наиболее выгодный путь - это заказ
внедренческих услуг.
Меня
критикуют
Замечание
1. Большой
вопрос по поводу способности MS Project
вести полный проектный учет.
MS Project 2000 и MS Project 2002 Standard это действительно инструмент для небольших проектов, где не требуется сложное управление ресурсами. MS Project не содержит средств для управления сложными механизмами затрат, интеграции с бюджетированием и средств планирования многих внешних критериев проекта (например, для маркетингового проекта это план и факт продаж). Тем не менее данные ограничения часто не существенны для небольших проектов, если нужна система hi-end класса, тогда стоит обратить внимание на MS Project 2002 Professional.
Недостающую функциональность во многих случаях можно легко "допрограммировать" на Visual Basic и не покупая дорогую систему. Выбор проектной системы определяет соотношение цена/качество, где необходимый требования к качеству зависят от конкретной компании.
Замечание
2. Описанная
методика соответствует возможностям MS
Project,
но нуждается в некоторых коррективах (см.
другие замечания). В частности необходимо
планировать риски. Нужно все-таки
изначально описывать методику с учетом
того, что в организации это не первый и не
единственный проект.
Некоторое планирование рисков мы рассмотрели, возможно оно упрощенное, за полным вариантом следует обратится к PMBOK. Насчет межпроектного взаимодействия, данной проблеме будет посвящена отдельная методика, которая базируется на использовании MS Project Central Server 2000.
Моделирование рисковых сценариев доступно в MS Project 2002 Professional.