Почему это пособие прочли 5000 менеджеров в России?
- 31% проектов завершаются провалом
- 53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза
- только 16% проектов укладываются в срок и бюджет
Данные от консалтинговой компании Standish Group
Это пособие не полная методика по управлению проектами и не учебник по всем функциям MS Project. Таких книг достаточно. Очень часто мне приходилось наблюдать почти шоковое состояние менеджеров, которые были незнакомы ранее с Microsoft Project и теорией управления проектами от PMI и решили изучить их по книгам. Перед менеджером стояла задача прочесть минимум две большие книги, т.е. более 1000 страниц. Самое интересное, даже потратив массу времени на это чтение менеджер оказывался почти беспомощным в реальной ситуации применения MS Project.
Дело в том, что книги не учат практическому применению инструментов по управлению проектами в реальных бизнес-ситуациях. Недостаток большинства книг и учебников по MS Project в том, что там просто рассматриваются все подряд функции, при этом нет сквозных практических примеров и анализа типовых ошибок.
Очень и очень редко в книгах есть полные (сквозные) примеры. Как правило, примеры заканчиваются демонстрацией какой-то функции и менеджер не видит как повлияет его действие через несколько шагов планирования и отслеживания проекта.
Еще интересное наблюдение состоит в том, что в 90% случаев менеджеры вынуждены использовать не какие-то сложнейшие приемы управления, а выполнять самые простые, если не сказать банальнее действия. Именно кажущаяся проста и приводит к таким печальным последствиям о которых сказано в эпиграфе. Как правило, в обычных книгах шлифовке и повторению самых важных и вроде бы «простых» навыков работы не уделяется достаточно места, обычно авторы ставят себе цель охватить кратким описанием все несколько тысяч функций встроенных в Microsoft Project.
Мне как профессиональному методисту по образованию было понятно, что требуется принципиально новый дидактический материал, который рассматривал применение MS Project методом сквозного примера и с разбором различных проблемных ситуаций. Такой прием быстрого введения очень популярен на Западе и известен как Overview.
Это позволяет очень быстро освоить продукт и закрепить навыки его практического применения по основным функциям.
В данной работе мне согласился помочь очень известный эксперт, в тот момент директор Московского отделения PMI, Владимир Либерзон. Его комментарии отмечены как «Комментирует Владимир Либерзон». В таких разделах вы можете ознакомится с нашей дискуссией по каждой части работы.
Данная работа уникально тем, что по сути сделана экспертами, которые находятся в острой конкурентной борьбе. Я занимаюсь внедрением корпоративной версии Microsoft Project и вероятно являюсь одним из самых публичных экспертов по данной системе, а Владимир Либерзон предлагает свой продукт Spider Project. Тем не менее, нам удалось отложить конкуренцию на время и сделать достаточно популярную работу по быстрому введению в управление проектами с помощью Microsoft Project. С момента первой публикации в Интернете с работой познакомилось более 5000 менеджеров из России.
Периодически некоторые части работы приходилось переделывать в связи с устареванием материала. Вы читаете 3е издание.
В данной работе рассматривается как пример проект по разработке программного обеспечения. Внедрение информационных систем очень рисковый вид проекта, поэтому выбор примера связан именно с этим, чтобы продемонстрировать практическую работу с рисками.
Стандартный ход проекта
Стандартный подход к проектному управлению состоит из следующих этапов:
1) Постановка задачи (фиксация цели проекта).
2) Планирование (выработка плана и бюджета).
3) Контроль и анализ исполнения, коррекция планов.
4) Закрытие проекта по формальной процедуре и анализ статистики .
В большинстве случаев под проектным управлением понимают только планирование, при этом, как правило, упускаются из вида документированная постановка цели и управление отслеживанием проекта. Неудивительно, что по статистике такие проекты, как правило, значительно превышают запланированные бюджет и сроки, а также достигают не тех результатов, которые были запланированы.
Постановка задачи
Проект должен начинаться с формулировки цели. При этом цель должна быть зафиксирована письменно в виде измеряемых показателей.
Документ "Постановка задачи" должен отвечать на следующие вопросы:
1) В какие сроки должна быть достигнута цель?
2) Какие условия достижения цели есть в наличии (бюджет, ресурсы, технология)?
3) Каким способом измерить достижение цели?
4) Как распределены обязанности в проекте (кто за что отвечает)?
5) Согласен ли инвестор (заказчик) с определением цели и условиями ее достижения?
В нашем примере цель проекта заключается в адаптации и внедрении некой системы документооборота. В нашем случае задание было письменным, не был определен только способ измерения того, что цель достигнута; последствия этого мы увидим далее.
Список этапов
Перейдем непосредственно к нашему примеру. Менеджер получил постановку задачи на адаптацию и внедрение некого продукта Web Work Flow. Менеджер запускает Microsoft Project и приступает к планированию.
После запуска MS Project менеджер сразу видит список для ввода задач. Слева находятся переключатели видов списков.
В самом начале составления плана менеджер вводит список этапов, соответствующих технологии внедрения.
Совет. Включите Summary Task (Сводная Задача) для того, чтобы видеть обобщенную статистику по проекту (общая длительность, трудоемкость, стоимость и т.д.).
Список задач
Ориентируясь на письменное задание, менеджер назначил задачи для всех технологических этапов.
Последовательность задач
Ориентируясь на приоритеты задач и особенности технологии, менеджер назначил последовательность задач. MS Project выделил красным цветом критический путь проекта, т.е. те задачи, которые определяют его длительность. Чтобы сократить критический путь, менеджер попробовал начать следующую технологическую стадию до завершения предыдущей.
Советы и комментарии.
1) Точный срок следует указывать только для задачи "Начало проекта", все остальные сроки должны быть относительными. Таким образом, вы всегда можете легко перенести проект на другую дату, все сроки пересчитаются автоматически.
2) Все технологические этапы следует завершать контрольными точками. Дело в том, что по технологии некий законченный результат может быть получен только в определенное время, и именно в данный момент следует провести контрольный осмотр проекта. Жестко и подневно контролировать исполнение отдельных задач часто не имеет смысла, т.к. исполнителям обычно приходится исполнять задачи не в том порядке, как указано в плане. Все это не значит, что подневная отчетность не нужна, она нужна в виде отчетов о затратах рабочего времени, о чем речь пойдет далее.
3) Без нужды не используете связи между задачами разного уровня. В этом случае один технологический этап привязывается к внутренней структуре другого этапа. Это сковывает свободу модификации планов в рамках отдельных этапов. Если используются связи только на одном уровне (задача-задача, этап-этап), вы можете без затруднений изменить состав и последовательность задач внутри некого этапа.
4) Сокращение критического пути проекта за счет преждевременного начала задач очень рискованно. Сокращайте критический путь за счет подготовительных работ (обучение, моделирование и т.д.). В нашем случае можно одновременно с постановочными работами запланировать прототипирование, и за счет этого сократить кодирование и общую продолжительность проекта. Сокращение критического пути проекта фактически всегда приводит к увеличению затрат на подготовительные работы. Иными словами, сокращение длительности проекта, как правило, приводит к повышению его себестоимости или рисков.
Ресурсы
После определения состава задач и их сроков менеджер назначает ресурсы для каждой задачи.
В результате после указания ресурсов менеджер автоматически получает график работ.
Совет. Если нужно производить учет административных расходов, т.е. затрат на управление проектом, можно использовать следующий прием. Нужно указать в MS Project менеджера в качестве ресурса на весь технологический этап. Соответственно продолжительности этапа будет производиться учет административных расходов по трудоемкости и себестоимости. Если менеджер ведет одновременно несколько проектов, можно указать процент нагрузки менеджера по данному проекту.
Расценки на ресурсы
Часто после получения графика работ планирование заканчивается, однако в том случае, если необходимо еще утвердить бюджет проекта, требуется назначить расценки на ресурсы.
Советы.
1) Наличие перегрузки (overtime) - это, скорее всего, ошибка планирования, связанная с тем, что вы поставили одному исполнителю две задачи одновременно.
2) Для планирования наиболее удобна повременная система начисления затрат. Это позволяет избежать сложных торгов со специалистами, работающим по подряду, относительно стоимости работ. Достаточно один раз согласовать стоимость человеко-часа, далее вопрос заключается только в обсуждении трудоемкости.
3) 
Рекомендуем использовать подневные ставки для ресурсов. Это позволяет избежать ошибок в округлениях.
4) В MS Project возможно использование материальных ресурсов. MS Project может запоминать инвентарные номера, что очень удобно для учета. Повременную амортизацию ОС можно учитывать через параметр Std. Rate ("затраты по времени использования"). Списание на манер МБП можно учитывать через параметр Cost/Use ("единовременные затраты на использование"). В нашем примере для проекта требуется закупка сервера, по применяемой нами учетной политике затраты на сервер целиком списываются в проект.
План с бюджетом
После назначения расценок на ресурсы менеджер автоматически получил план с бюджетом.
Из этого документа видны следующие основные параметры проекта:
- Длительность
- Трудоемкость
- Себестоимость
- Сроки
- Исполнители и ответственные лица
Совет. Данные по трудоемкости (Work) и себестоимости можно использовать для ценообразования проекта. В нашем случае можно умножить трудоемкость на выходную цену человеко-месяца и получить внешнюю цену проекта.
Риски и косвенные работы
В нашем примере сложилась следующая ситуация: не успел проект начаться, как менеджер обнаружил, что его сотрудники не могут сразу приступить к работе, т.к. проект построен на новых технологиях и их необходимо изучить. Проанализировав ситуацию, менеджер планирует обучение и снова проходит процедуру утверждения бюджета и сроков.
Таких переутверждений бюджета и сроков можно делать бесконечно много, если не проанализировать причины подобных проблем. Они гораздо глубже конкретного недостатка квалификации персонала. Дело в том, что большинство прямых работ, следующих напрямую из задач проекта, порождает большое количество косвенных, которые связаны с их выполнением. Проблема заключается в том, что точно оценить состав и трудоемкость косвенных работ невозможно. Можно дать лишь статистические оценки. С другой стороны, косвенные работы часто обусловлены влиянием рисков на проект.
Для того чтобы косвенные работы не развалили проект, можно дать следующие рекомендации:
1) Планируйте обучение и качество. Это предотвращает типичные технологические риски.
2) Исследуйте риски и планируйте действия по их предупреждению. Об этом мы расскажем далее.
Управление рисками по PMI
Рассмотрим теорию управления рисками.
По теории нужно выполнять следующие действия:
1) Определение рисков. Необходимо провести анализ проекта с целью идентификации причин рисков.
2) Исследование рисков. Необходимо четко определить риск, его последствия и вероятность, выработать стратегию его предупреждения.
3) Исполнение плана с отслеживанием рисков. Необходимо планирование антирисковых мероприятий и поиск новых рисков.
Теоретические советы, как видим, достаточно общие, но из них следует важный вывод: план может и должен подвергаться изменениями в результате поиска и устранения рисков.
Согласование и отчет
После утверждения нового плана обучение прошло успешно и в сроки закончилось необходимой сертификацией. Сотрудник успешно преступил к выполнению первой задачи. Однако в день ее завершения он сообщил, что "задача готова на 90% и требуется еще 1 день". На следующий день он ответил то же самое.
На рисунке показан вид просмотра проекта Tracking Gantt, на котором видно отличие первоначального плана от фактического исполнения.
Что можно сказать о сложившейся ситуации? Постоянное утверждение исполнителей, что задача готова на "90% и нужно еще чуть-чуть" - верный признак проваленной задачи.
В нашем случае менеджер понял это, вызвал сотрудника на откровенную беседу и стал выяснять глубинные причины срыва сроков. Они оказались следующими:
1) Сотрудник заявил, что не участвовал в принятии решения относительно сроков по данной задаче. Это решение единолично принял менеджер, хотя срок явно занижен.
2) 
Беседа показала, что сам сотрудник слабо ориентируется в реальных сроках задач. Это нормально, только менеджер концентрируется на сроках и перспективах. Сотрудника обычно волнуют локальные проблемы буквально в рамках нескольких рабочих часов.
3) Обсуждение показывает, что отчет о выполнении задачи в процентах ни о чем не говорит. Представления о процентах субъективно. Более важна информация о реальных затратах времени по проекту. Совершенные затраты рабочего времени - это уже статистика для принятия решений.
Проблемы и решения
Каковы выходы из сложившейся ситуации?
1) Срок должен определяться в первую очередь исполнителем. Исполнитель, как правило - самый опытный эксперт в задачах данного рода. Не следует опасаться, что исполнитель сильно завысит сроки, скорее срок будет занижен. Дело в том, что исполнители очень редко учитывают в своих оценках необходимость косвенных работ.
2) В план могут быть приняты только сроки, согласованные между менеджером и сотрудником. Это позволяет разделить ответственность между ними и избежать ошибок при оценке сроков. В Microsoft Project встроена система рассылки сообщений TeamAssign через e-mail или Web. Данное сообщение является мини-контрактом относительно задачи между исполнителем и менеджером.
3) Для накопления достоверной статистики о реальных трудозатратах необходимо вести учет рабочего времени по проектам. Правильные контрольные вопросы о состоянии задачи (Team Status) следующие:
- на что уже было потрачено время (work complete)?
- сколько еще нужно времени (remain work)?
Microsoft Project позволяет через почту или браузер автоматизировать отчетность исполнителей о затратах рабочего времени и их прогнозах. Информация, предоставляемая ими, отображается в плане. Менеджер, сравнивая план и факт (об этом подробнее ниже), может судить об успешности хода проекта по срокам и затратам.
Калибровка сроков
Как это часто и бывает на практике, обсчет реалистичных сроков для проекта менеджер стал выполнять после его начала. Если проект для менеджера новый, то подобная ошибка почти неизбежна. 
Используя Load Factor, менеджер оценил пессимистичные сроки. В качестве ожидаемых сроков менеджер взял те, что получились путем согласования через Team Assign с исполнителями. За оптимистические взял свои первоначальные.
Методом PERT пересчитал ожидаемые сроки. На рисунке в колонке Work Variance видно, что по сравнению с планом была недооценка трудоемкости в 226 человеко-часов.
Советы.
1) Колонки Variance могут показать вам отличие состояния проекта от первоначального плана. Вы может добавить эти колонки в любой вид просмотра.
2) Используйте копирование через Clipboard колонок PERT-диаграммы, таким образом вы сэкономите время.
Измеряемая цель
В нашем примере проект подошел к концу, но проект завершить в срок не удается. Сотрудник пытается сдать проект, но вместо этого появляется новая задача от заказчика.
Подобная ситуация является типичным признаком потери контроля. Это понял и заказчик, назначив крайний срок сдачи (Dead Line). В MS Project существует средство для отметки Dead Line и оповещении о подходе к нему.
Рассмотрим причины потери контроля и способы его восстановления.
5.2 
Иллюзия простоты (80%/20%)
Следует помнить правило 80/20. Иными словами 80% работы делаются за 20% времени (см. рисунок). Как следствие, первые успехи могут вскружить голову и можно потерять ощущение реальности. Это является особенностью человеческой психологии и характерно для большинства людей. В этом заключается, однако, одна из причин заниженных исполнителями оценок сроков.
Менеджер должен помнить, что, возможно, потребуется провести значительные работы по поднятию качества до потребительского уровня.
В нашем случае менеджер зарезервировал необходимое время на обеспечение качества. Возникшие причины проблем носят политический характер. Рассмотрим их.
5.3 План и требования должны изменяться совместно
Если проанализировать ситуацию, видно, что фактически происходит изменение задания (задач) проекта в результате процедуры приемки. На рисунке приведен цикл изменения плана при корректировке задач по методике PMI.
Если задачи проекта не были документированы или если заказчик проекта настаивает на новых задачах без коррекции плана, то ситуация неуправляема. Скорее всего, проект пойдет на самотек, или Исполнитель откажется вести проект себе в убыток.
Требование и план неразрывны, это простое положение не так просто достигается на практике. Очень часто Заказчик только на сдаче проекта обнаруживает, что требования к проекту и его ожидания - несколько разные вещи. Часто Заказчик начинает настаивать именно на выполнении своих ожиданий.
В нашем случае причина в другом. Менеджер предусмотрел в плане работы по составлению задания и утвердил его у Заказчика. Заказчик был заранее предупрежден, что многие его ожидания в данном проекте реализованы не будут. Для правильного планирования необходимо завершить этап постановки задач. Это было сделано. Проблемы заключаются в другом.
Планирование итеративно, следующие стадии предсказуемы лишь статистически
Итак, в заключаются настоящие проблемы данного проекта? Заказчик раздражен постоянным удорожанием проекта и спорит о толковании пунктов задания. Таким образом, разделим мотив и формальную причину.
Как мы видели выше, менеджер (исполнитель) сделал много ошибок в процессе планирования. Однако нельзя сказать, что вся ответственность за это лежит на нем. Дело в том, что невозможно было точно предсказать сроки задач в конце проекта без завершения первых задач. Например, выработка требований может изменить оценку трудоемкости разработки.
Более правильным является разложить этот большой проект на несколько небольших, но с гарантированным получением результата. Проблема состоит в том, что Заказчик, как правило, хочет знать сроки и цену на все сразу, т.к. отдельный этап работ представляется менее ценным, чем весь проект.
Единственное, что может сделать опытный менеджер в данном случае, это четко спланировать ближайший этап, а остальные определить статистически. Как видно из выше изложенного, статистика с учетом косвенных работ поражает воображение своей трудоемкостью на фоне иллюзии простоты.
Заказчик, получив большие статистически оценки, требует составить план работ из конкретных задач и начинает убирать оттуда "завышенные" и "ненужные" работы.
Если это произошло, проект обречен на потерю контроля.
В нашем случае проблема заключалась в том, что менеджер пытался сделать все в рамках одного проекта и статистические оценки стал применять только уже по ходу проекта.
Формальное закрытие проекта
Сравним формальное закрытие проекта с проектом "без конца".
Проект с формальным завершением обладает очень высокой предсказуемостью и управляемостью.
Можно достаточно точно определить бюджет и сроки проекта. Формальный проект повышает ответственность сторон, все ожидания и соглашения документированы.
Проект без формального ведения обычно мало управляем по срокам и бюджету. Если формализованный проект подвержен значительному риску на этапе постановки, то неформальный проект, в силу неопределенности задач, подвержен риску на всем протяжении.
Тем не менее, многие предпочитают неформальное ведение проектов. Этот объясняется влиянием политических рисков. Формальный проект позволяет установить ответственность, и эта ответственность часто пугает как исполнителя проекта, так и заказчика. За неудачу формального проекта несут ответственность в равной степени и Исполнитель, и Заказчик. Оба подписались под требованиями к проекту и взяли на себя ответственность, причем эта ответственность носит личный характер.
Обычно ситуация безответственности не устраивает только топ-менеджеров, именно они и могут своим волевым решением привести ситуацию в норму. Оптимально, если это происходит до начала проекта, а не по ходу его.
В нашем случае, менеджер на встрече с топ-менежером заказчика добился решения об измеряемых критериях завершения проекта.
Закрытие и оценка проекта
Менеджер поставил в план разработку документа, описывающего контрольные тесты.
Далее в соответствии с тестами продукт был приведен в порядок и в срок сдан заказчику.
Как видно по рисунку, проект примерно в 2 раза превысил ожидаемую себестоимость.
Тем не менее, следует отметить, что в условиях нашего примера проект был для менеджера новым и подвергался влиянию политических рисков. Достигнутый результат в данных условиях можно считать хорошим (нормальным). Данный вывод подтверждается и статистикой Standish Group: 53% проектов завершаются успешно, но с превышение бюджета в 1,9 раза.
Анализ статистики
После завершения проекта необходимо вычислить статистические показатели для последующего прогнозирования сроков: соотношение стадий, типовые длительности, стоимости и т.д.
Именно поэтому важно разделить план на технологические стадии, состав которых независит от вида проекта.
Что показывает статистика?
Приведем типичные статистические показатели Канера-Фолка и прокомментируем их относительно нашего примера.
Продукт получается в среднем через 8 внутренних и 3 внешних версии. Из этого следует, что стоит планировать 8 версий, и, скорее всего, потребуется несколько проектов. Об этом мы уже говорили выше.
Для разработки ПО характерны следующие статистические показатели соотношения технологических стадий:
Разработка - 37%
Сопровождение - 63%
Этап разработки разделяется на стадии со следующими пропорциями:
Постановка - 34%
Кодирование - 21%
Тестирование - 45%
Если рассмотреть наш пример, то мы увидим, что данная статистика работает. Однако если мы посмотрим на первоначальный план, то увидим несоответствие трудоемкости стадий плана средним статистическим показателям.
Совет. Проверяйте план на соответствие статистике!
Почему это пособие прочли 5000 менеджеров в России?
- 31% проектов завершаются провалом
- 53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза
- только 16% проектов укладываются в срок и бюджет
Данные от консалтинговой компании Standish Group
Это пособие не полная методика по управлению проектами и не учебник по всем функциям MS Project. Таких книг достаточно. Очень часто мне приходилось наблюдать почти шоковое состояние менеджеров, которые были незнакомы ранее с Microsoft Project и теорией управления проектами от PMI и решили изучить их по книгам. Перед менеджером стояла задача прочесть минимум две большие книги, т.е. более 1000 страниц. Самое интересное, даже потратив массу времени на это чтение менеджер оказывался почти беспомощным в реальной ситуации применения MS Project.
Дело в том, что книги не учат практическому применению инструментов по управлению проектами в реальных бизнес-ситуациях. Недостаток большинства книг и учебников по MS Project в том, что там просто рассматриваются все подряд функции, при этом нет сквозных практических примеров и анализа типовых ошибок.
Очень и очень редко в книгах есть полные (сквозные) примеры. Как правило, примеры заканчиваются демонстрацией какой-то функции и менеджер не видит как повлияет его действие через несколько шагов планирования и отслеживания проекта.
Еще интересное наблюдение состоит в том, что в 90% случаев менеджеры вынуждены использовать не какие-то сложнейшие приемы управления, а выполнять самые простые, если не сказать банальнее действия. Именно кажущаяся проста и приводит к таким печальным последствиям о которых сказано в эпиграфе. Как правило, в обычных книгах шлифовке и повторению самых важных и вроде бы «простых» навыков работы не уделяется достаточно места, обычно авторы ставят себе цель охватить кратким описанием все несколько тысяч функций встроенных в Microsoft Project.
Мне как профессиональному методисту по образованию было понятно, что требуется принципиально новый дидактический материал, который рассматривал применение MS Project методом сквозного примера и с разбором различных проблемных ситуаций. Такой прием быстрого введения очень популярен на Западе и известен как Overview.
Это позволяет очень быстро освоить продукт и закрепить навыки его практического применения по основным функциям.
В данной работе мне согласился помочь очень известный эксперт, в тот момент директор Московского отделения PMI, Владимир Либерзон. Его комментарии отмечены как «Комментирует Владимир Либерзон». В таких разделах вы можете ознакомится с нашей дискуссией по каждой части работы.
Данная работа уникально тем, что по сути сделана экспертами, которые находятся в острой конкурентной борьбе. Я занимаюсь внедрением корпоративной версии Microsoft Project и вероятно являюсь одним из самых публичных экспертов по данной системе, а Владимир Либерзон предлагает свой продукт Spider Project. Тем не менее, нам удалось отложить конкуренцию на время и сделать достаточно популярную работу по быстрому введению в управление проектами с помощью Microsoft Project. С момента первой публикации в Интернете с работой познакомилось более 5000 менеджеров из России.
Периодически некоторые части работы приходилось переделывать в связи с устареванием материала. Вы читаете 3е издание.
В данной работе рассматривается как пример проект по разработке программного обеспечения. Внедрение информационных систем очень рисковый вид проекта, поэтому выбор примера связан именно с этим, чтобы продемонстрировать практическую работу с рисками.
Дата: 2018-12-28, просмотров: 431.
