В шапке
Почему проекты превышают плановые сроки

Почему проекты превышают плановые сроки

Привет всем!

Ранее я разместил в блоге статью об успешности ИТ-проектов. Не знаю, как вас, а меня статистика успешности ИТ-проектов от Standish Group не очень радует. Может, они что-то неправильно считают? Или мы, менеджеры проектов, что-то неправильно делаем? ….Я склоняюсь ко второй версии.

Если посмотреть данные по категории «спорных» проектов (статистику успешности смотрите здесь: http://project-management.zis.by/drugoe/vestibulum_iaculis.html), то мы увидим, что из 43% проектов, которые в 2012 году признали «спорными», проблемы со сроками испытали 74% проектов. Перемножив два числа, получаем, что в 32% от общего числа ИТ-проектов были сорваны сроки. Из таблицы видно, что срыв сроков - это самая распространенная причина, из-за которой проект не признали успешным. Если добавить к 32% проектов еще 18% «провальных», в которых наверняка были проблемы со сроками, то получится, что в 50% случаев ИТ-проекты не завершаются в плановый срок.

(с) The Standish Group. CHAOS MANIFESTO 2013

Если бы была подобная статистика по российским проектам, то я уверен, она оказалась бы не лучше. Откуда такая уверенность? А посмотрите на статистику опроса за 2007 год: http://www.cnews.ru/news/top/?2007/08/14/262491

Если верить этому исследованию, в России в 2007 году в срок выполнялось 4% ИТ-проектов. Не думаю, что ситуация радикально улучшилась за последние 7 лет!

Далее я изложу свою точку зрения на причины срывов сроков проектов, сформированную под воздействием рефлексии личного опыта управления проектами и информации из исследований по данной теме.

Самая серьезная причина превышения плановых сроков, на мой взгляд, – это неверная оценка на этапе инициации проекта. Почему так происходит? У людей плохо с прогнозами, особенно долгосрочными. В своей книге «Думай медленно…решай быстро» Д.Канеман приводит высказывание Филиппа Тетлока, психолога Пенсильванского университета: «Мы стремительно достигли той точки, когда ценность предсказаний, основанных на знаниях, становится крайне невысокой. В век чрезмерной специализации науки нет смысла полагать, что те, кто публикуется в ведущих изданиях – выдающиеся политологи, регионоведы, экономисты и так далее, – хоть сколько-нибудь превосходят обычных журналистов или просто вдумчивых читателей New York Times в том, что касается видения назревающих ситуаций». И далее Д.Канеман пишет: «Исследования подводят нас к неожиданному выводу: для максимального повышения прогностической точности конечные решения следует доверить формулам, особенно в «малодостоверных» областях». 

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

Что нам с этим делать и как повысить точность прогнозов при оценке проектов? Д. Канеман предлагает использовать для оценки информацию по другим проектам, сходным с тем, для которого строится прогноз.

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

А руководитель проекта, оценивая объемы работ, должен попытаться найти данные о фактической трудоемкости аналогичных задач в схожих проектах и использовать их как базу для оценивания объемов работ. Чем больше аналогичных проектов с аналогичными задачами он найдет, тем лучше.

Какими могут быть причины неправильного планирования сроков? Выделим следующие:

1.    Размер проекта.

Статистика The Standish Group явно демонстрирует нам зависимость успеха от масштаба проекта. Если намечается ИТ-мегапроект, я рекомендую разбить его на небольшие проекты и управлять ими как программой проектов (об этом я уже писал в заметке http://project-management.zis.by/drugoe/vestibulum_iaculis.html). По небольшому проекту и прогноз сроков окажется более достоверным.

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

Для решения этой проблемы я рекомендую выделить сбор и анализ требований к продуктам в отдельный проект. Понятно, что в процессе реализации требования могут измениться. Но если они были хорошо проработаны, то, скорее всего, изменятся на 10-20% по отношению к первоначальным, а не на 50-70%. Для сбора требований руководитель проекта может использовать не только популярные методы интервью и анкетирования, но и более сложные, такие как QFD (Quality Function Deployment) и прототипирование. Первый подход позволяет максимально точно спроектировать требования к продукту, используя «голос потребителя» и специальные инструменты для ранжирования требований, а второй – получать быструю обратную связь от заказчика проекта по поводу реализации требований через прототип. Имея требования к продуктам проекта, можно создать полный список работ и провести оценку их трудоемкости.

3.    Руководители проектов часто не используют ресурсное планирование.

Ресурсное планирование предполагает, что длительность задач в сетевом графике рассчитывается на основании трудозатрат по задаче, ресурсов, назначенных на задачу, и «% доступности» этих ресурсов. Зачастую руководители проектов даже не проверяют адекватность сроков работ в плане с учетом имеющихся ресурсов. По сути, они составляют график работ, исходя из предположения, что ресурсов будет достаточно для выполнения задач в плановый срок. Да, применение ресурсного планирования усложняет процесс планирования сроков, но делает план по срокам гораздо более адекватным.

4.    Слабое использование методов сетевого планирования

Оценив продолжительность задач проекта с учетом имеющихся ресурсов, и построив сетевой график, руководитель проекта может получить прогноз сроков проекта, используя такие подходы, как метод критического пути и метод критической цепочки. Стоит заметить, что оба подхода предусматривают определение длительности проекта на основании ресурсного критического пути и предполагают проверку сетевого графика на наличие перегрузок по ресурсам и выравнивание перегрузок. Метод критической цепочки является, на мой взгляд, более прогрессивным, хотя требует ряда организационных изменений, на которые пойдет не любая компания.  О методе критической цепочки хорошо написано в книге Л.Лича (http://www.labirint.ru/books/220188/)

5.    Изменения требований к продуктам проекта по ходу проекта.

Понимая то, что требования по ходу реализации проекта будут меняться, руководителю проекта вместе с заказчиком следует выстроить процедуру ранжирования требований и определить, без каких из них продукт проекта невозможно будет использовать (must have), а какие являются желательными (nice to have). Если вдруг сроки будут затягиваться, команда проекта сможет подготовить работающий продукт, включающий ключевые требования, и передать его в эксплуатацию, а остальные требования (nice to have) можно реализовать на этапе промышленной эксплуатации продукта.

Еще одно интересное наблюдение от The Standish Group – пользователи  часто используют лишь 20% от функционала программного продукта, а 50% – не используются почти никогда. Задача сбора, анализа и управления изменениями требований является едва ли не самой сложной в разработке программного продукта. Очевидно, что концентрация на 20% самых нужных требований даст 80% выгод от использования продукта.

Применить такую рекомендацию к строительным проектам невозможно. В данном случае для управления требованиями стоит рассмотреть возможность использовать технологии BIM (Building Information Modeling или Building Information Model) — информационное моделирование здания или информационную модель здания. На Западе уже несколько лет говорят и пишут  о результатах, которые дает этот подход. Подробнее прочесть можно тут: http://ru.wikipedia.org/wiki/BIM

6.    Недостаточный контроль над выполнением работ.

Даже хороший план может привести к провалу, если не выстроена адекватная система контроля хода работ по проекту. Чаще всего руководители проекта получают информацию о ходе работ в виде отчета по статусам задач. Что-то типа:

0% - задача не начата
50% - в работе
100% - закончена

Мало того, информация о выполнении работ собирается не каждый день, а раз в неделю (или еще реже). Я считаю, что для большинства проектов такой уровень контроля недостаточен. Мне, как руководителю проекта, хочется каждый день иметь понимание того, какой объем работ по проекту уже сделан, а какой еще остался. И делать прогнозы о завершении проекта в срок на основании оставшегося объема работ и данных о текущих темпах реализации работ.

В управлении проектами уже давно существует методика контроля проекта, которая удовлетворяет моим требованиям – это методика освоенного объема. Правда, она предполагает использование «% физического выполнения объемов работ» либо «% завершения по трудозатратам» по каждой задаче проекта. Приведу пример: Задача запланирована на 10 человеко-часов. Исполнитель сегодня потратил на нее 6 человеко-часов, каков «% завершения задачи»? Можно подумать, что задача завершена на 60% (6 часов из 10 уже потрачено), но что если это не так и исполнителю нужно еще 8 часов, чтобы получить результат по задаче? В этом случае % завершения = 43% (6/(6+8) *100 % = 43%). Имея данные о фактически потраченном и оставшемся времени на задачу, руководитель проекта каждый день обладает адекватной информацией по прогнозам завершения проекта в плановые сроки.

Методика освоенного объема основана на использовании трех показателей и ряда индикаторов, позволяющих понимать, успеваем ли мы сделать проект в срок и бюджет и каковы прогнозы стоимости проекта по завершению. Для использования этой методики нам придется внедрить в своем проекте отчеты о фактически потраченном и оставшемся времени по задачам. Это будет сделать непросто, но уж если мы это сделаем, то заодно решим проблему отсутствия статистики – у нас начнет накапливаться статистика по фактическим трудозатратам в разрезе похожих работ.

7.    Недостаточная вовлеченность заказчика проекта.

С точки зрения сроков проекта недостаточная вовлеченность заказчика проявляется в затягивании принятия решений по важным вопросам. В проекте приходится принимать тысячи решений, и, по мнению The Standish Group, в 20% случаев для принятия решений нам нужен заказчик проекта. И если решения будут приниматься дольше запланированных сроков, это, понятное дело, будет влиять на общий срок проекта. Но об этом я уже писал в заметке: http://project-management.zis.by/komanda-proekta/lorem_ipsum+.html

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

  1. Небольшой размер проекта.
  2. Сбор и анализ требований до старта проекта реализации продукта, оценка объемов работ проекта на основании требований.
  3. Использование ресурсного планирования, методов критического пути и критической цепочки для определения сроков проекта.
  4. Управление приоритетами требований и изменениями требований по ходу проекта.
  5. Контроль проекта с помощью метода освоенного объема.
  6. Назначение в проект квалифицированного и мотивированного заказчика.

Удачи вам в управлении сроками ваших проектов! Следующая тема для обсуждения - методы оценки проекта. До встречи! И, как всегда, жду ваших комментариев!


 

Комментарии (0)
Войти как