9 на 9. Почему срываются сроки проектов и как не срывать их

Почему при словах «мы начинаем новый проект» внутренний голос часто говорит: «и снова сорвем сроки»? Есть простое объяснение. Большинство проектов действительно срывают плановые сроки.

Посмотрите на эти таблицы.

Статистика успешности ИТ-проектов в мире

Сроки, бюджеты и реализация требований в категории «спорных» ИТ-проектов

Из 43% проектов, которые в 2012 году признали «спорными», проблемы со сроками испытали 74% проектов. Перемножив два числа, получаем, что в 32% от общего числа ИТ-проектов были сорваны сроки. Плюс еще 18% «провальных», в которых наверняка были проблемы со сроками. Получается, что в 50% случаев ИТ-проекты не завершаются в плановый срок.

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

Что же происходит? Оказывается, у нас вообще плохо обстоит дело с прогнозами, особенно долгосрочными. Об этом пишут когнитивные психологи, например, Д.Канеман.

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

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

1. Неверная оценка проектов на старте

Для оценки проектов на старте можно использовать метод аналогов. Но в Беларуси есть проблема: никто не занимается сбором и публикацией статистики по реализованным проектам. Почему? Государственным органам это не нужно, а частные компании пока не понимают значимости такой статистики и, скорей всего, не готовы делиться достоверной информацией о выполненных проектах. А, представьте, как облегчилась бы участь руководителя проекта, если бы он имел возможность изучить опыт ста похожих проектов и узнать в какой диапазон по срокам и бюджету они уложились!

2. Большой размер проекта

Статистика The Standish Group явно демонстрирует нам зависимость успеха от масштаба проекта. Если намечается ИТ-мегапроект, я рекомендую разбить его на небольшие проекты и управлять ими как программой проектов. По небольшому проекту и прогноз сроков окажется более достоверным.

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

Я рекомендую выделить сбор и анализ требований к продуктам в отдельный проект. Не для всех проектов этот вариант будет верным (есть подходы к управлению проектами, которые рекомендуют сбор и анализ требований проводить параллельно с разработкой продукта). Понятно, что в процессе реализации требования могут измениться. Но если они были хорошо проработаны, то, скорее всего, изменятся на 10-20% по отношению к первоначальным, а не на 50-70%.

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

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

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

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

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

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

7. Слабое внимание управлению рисками

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

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

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

0% – задача не начата

50% – в работе

100% – закончена

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

В управлении проектами уже давно существует методика контроля проекта, которая удовлетворяет моим требованиям – это методика освоенного объема. Правда, она предполагает использование «% физического выполнения объемов работ» либо «% завершения по трудозатратам» по каждой задаче проекта.

Приведу пример: задача запланирована на 10 человеко-часов. Исполнитель сегодня потратил на нее 6 человеко-часов, каков «% завершения задачи»?

Можно подумать, что задача завершена на 60% (6 часов из 10 уже потрачено), но что если это не так и исполнителю нужно еще 8 часов, чтобы получить результат по задаче?

В этом случае % завершения = 43% (6/(6+8) *100% = 43%).

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

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

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

Она проявляется в затягивании принятия решений по важным вопросам. В проекте приходится принимать тысячи решений, и, по мнению The Standish Group, в 20% случаев для принятия решений нам нужен заказчик проекта. И если решения будут приниматься дольше запланированных сроков, это, понятное дело, будет влиять на общий срок проекта.

Секреты выполнения проекта в срок

На мой взгляд, они следующие:

1. Оценка объемов работ на старте проекта методом аналогов.

2. Небольшой размер проекта.

3. Сбор и анализ требований до старта проекта, уточнение оценки объемов работ проекта на основании требований.

4. Использование ресурсного планирования.

5. Использование методов критического пути и критической цепочки для определения сроков проекта.

6. Управление приоритетами требований и изменениями требований по ходу проекта.

7. Пристальное внимание работе с рисками.

8. Контроль проекта с помощью метода освоенного объема.

9. Назначение в проект квалифицированного и мотивированного заказчика проекта (или его представителя).

Стоит прочесть:

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

Удачи в управлении сроками!