О чем эта работа?
- 31% проектов завершаются провалом
- 53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза
- только 16% проектов укладываются в срок и бюджетДанные от консалтинговой компании Standish Group
Данная статья служит ответом на следующие вопросы:
-
Как добиться управляемости проектов?
-
Как оценить реальную стоимость проекта?
-
Как оценить реальный риск проекта?
-
Как эффективно использовать MS Project 2000 в проектах?
Менеджеров всегда волнуют проблемы контроля над деятельностью подразделения, улучшения прогнозирования, выполнения задачи в рамках бюджета и сроков, снижения рисков.
В качестве средства решения данных проблем были разработаны методики ведения деятельности с точки зрения проектов. Для проектных методик управления были разработаны различные средства автоматизации.
В данной работе мы рассмотрим методику ведения проектов в группе от 2 до 10 человек. Такая численность группы была выбрана потому, что таков типовой размер рабочей группы в средней российской компании. В качестве инструмента автоматизации ведения проектов используется MS Project 2000.
Наша методика построена на анализе сквозного примера ведения проекта по внедрению некого программного продукта. Внедренческий проект был выбран в качестве примера в связи с тем, что что у нас имеется богатый опыт ведения проектов такого типа. Внедрением ПО (программного обеспечения) вынуждена заниматься любая организация, поэтому частные особенности ведения таких проектов могут оказаться полезны всем. Сама методика ведения проектов не ориентирована на конкретный вид проектов и может быть использована для других видов работ.
Проекты по внедрению ПО интересны также тем, что, как правило, очень рискованны. Вероятность выполнить проект, уложившись в бюджет и сроки по мировой статистике от Standish Group не превышает 31%. Поэтому мы сможем достаточно подробно рассмотреть вопросы управления рисками в малых проектах.
Меня критикуют
В таких разделах я буду приводить сделанные возражения экспертов и комментировать их сам.
Замечание 1. "Это еще не методика - просто некоторые советы по составлению расписания и обсуждение типичных проблем. Движение в нужном направлении, но начальные шаги. В целом - приятное впечатление."
Все верно, работа посвящена начальному обучению проектным методикам и обсуждению тонких мест полезных и экспертам. По своему опыту, я заметил, что наиболее легко усваивается материал в виде живых примеров, а не сверхподробных указаний. Кроме того, я намерено пропустил некоторые моменты проектного менеджмента, на которых обычно не возникает проблем, и наоборот очень подробно остановился на частностях, которые могут быть причинами серьезных трудностей. Если быть формально точным, это скорее полезные методические рекомендации, а не полноценная методика как PMBOK. Я намеренно по ходу примера "заставляю" менеджера делать ошибки, т.к. именно по последствиям ошибок легче запоминаются необходимые требования к проектному управлению. Кроме того, менеджеры совершают те или иные ошибки в управление почти всегда и их больше интересует как исправить ошибку, а не только как надо было сделать до начала работы.
Замечание 2. Что-то не видно определения проекта, что вы понимаете под проектом?
Вопрос-ловушка. Как гласит PMBOK "Проект - это мероприятие, которое имеет уникальный результат и ограничено временными рамками. Что не попадает под данное определение - операционная деятельность". Тонкость вот в чем, даже операционную деятельность можно рассматривать как проект, например, квартальный план работ производственного цеха серийной продукции. Временем ограничено? Да. Уникальность результата есть? Есть, т.к. результат уникален по временной характеристике его достижения. Польза от рассмотрения операционной деятельности в виде проекта есть? Есть, используя данный подход можно внедрить средства проектного планирования и добиться большей управляемости квартальных работ.
Введение. Краткая теория управления проектами
Как уже упоминалось, мы рассмотрим общую методику ведения малых проектов, поэтому, прежде всего, сделаем краткий обзор элементов теории управления проектами. Обзору теории ведения проектов посвящен данный раздел.
Приведем список литературы, на которой базируется наша методика. Далее мы будем ссылаться на данные документы и публикации.
ISO 9000 (стандарты, регламентирующие проектную деятельность и поддержание качества)
PMI Standards. A guide to the project management body of knowledge (набор полноценных методик по ведению проектов)
SEI. The Capability Maturity Model (стандарт регламентирующий требования к софтверным проектам)
В. Куперштейн. Современные информационные технологии в делопроизводстве и управлении (описание работы с MS Project с точки зрения пользователя)
Стандартный подход к проектному управлению состоит из следующих этапов:
-
Постановка задачи (фиксация цели проекта).
- Планирование (выработка плана и бюджета).
- Контроль и анализ исполнения, коррекция планов.
- Закрытие проекта по формальной процедуре и анализ статистики .
Во многих случаях под проектным управлением понимают только планирование, при этом, как правило, упускаются из вида документированная постановка цели и управление отслеживанием проекта (project tracking). Неудивительно, что по статистике такие проекты, как правило, значительно превышают запланированные бюджет и сроки, а также достигают не тех результатов, которые были запланированы.
Меня критикуют
Замечание 1. Не только в этом дело, не все ограничиваются планированием
Все верно, причин возможного кризиса больше, о них ниже.
Этап планирования является одним из самых важных. На этом этапе определяются задачи, бюджет и сроки проекта. Довольно часто планирование понимают только как составление графика работ, упуская из вида управление ресурсами, составление бюджета и т. д.
Полноценная техника планирования включает в себя следующие этапы:
-
Определение целей проекта и их описание. Довольно часто проекты начинаются без четкой цели.
- Определение технологических стадий. Для проекта должна быть выбрана технология реализации, определяющая стадии развития проекта. Одной из типичных ошибок планирования является несоответствие плана технологическому циклу.
- Для технологических стадий необходимо определить список задач, указать их взаимосвязи (последовательность) и прогнозируемую длительность (зависит от назначенных ресурсов).
- Необходимо согласовать вопрос о выделяемых проекту ресурсах. Следует отметить, что все ресурсы компании должны распределяться централизованно. Довольно часто возникает ошибка планирования, связанная с тем, что некоторые дефицитные ресурсы используются одновременно в двух разных проектах в одно и тоже время.
- График работ в таких системах, как MS Project, получается автоматически, если определены задачи и ресурсы.
- Если определить расценки на ресурсы, бюджет может быть получен также автоматически. Одна из типичных ошибок заключается в том, что бюджет назначают не обращая внимание на прогнозируемую себестоимость проекта.
- Письменное задание, бюджет и график работ образуют формальный документ "План проекта". Довольно часто перед началом проекта некоторые из указанных документов отсутствуют, последствия этого мы рассмотрим ниже.
Меня критикуют
Замечание 1. График работ требует обязательного управления ресурсами. Выделение ресурсов должно соответствовать уже составленному графику работ - сначала исходя из ролей.
Это верно, но многие начинают использовать системы планирования просто для составления графика работ без указания ресурсов или вместо ресурсов указывая ответственных лиц за задачи (не одно и тоже). С точки зрения PMI это криминал, но с точки зрения планирования небольшого проекта иногда удобно. Поэтому я намеренно не акцентируюсь на управление ресурсами на первых шагах примера.
Замечание 2. План проекта включает и другие разделы - например, регламент управления, документооборот, анализ рисков и пр. План проекта требует большого количества обязательных формальных документов.
Все так. Но мы рассматриваем небольшие проекты, где выработка отдельных документов может быть сравнима с трудоемкостью самого проекта, поэтому я преднамеренно иду на упрощения.
Замечание 3. Разработка графика работ итеративный процесс - первоначальный график неоднократно корректируется с переназначениями ресурсов, если сроки не устраивают. Уже на этой стадии необходим анализ рисков
Как я уже отмечал, данная работа построена на рассмотрении примера, где менеджер делает ошибки по ходу планирования. Последствия отсутствия в плане антирисковых мероприятий мы увидим ниже.