Менеджмент
25 августа 20149 на 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. Назначение в проект квалифицированного и мотивированного заказчика проекта (или его представителя).
Стоит прочесть:
- Лоуренс Лич, «Вовремя и в рамках бюджета: Управление проектами по методу критической цепи». Прекрасная книга, объясняющая все тонкости «метода критической цепи».
- Д.Канеман, «Думай медленно…решай быстро». Книга о том, как устроен наш мозг и как мы принимаем решения. Много интересной информации о наших стереотипах и ловушках мышления.
- Т. ДеМарко и Т. Листер, «Вальсируя с медведями». Пожалуй, лучшая книга на русском языке по управлению рисками в ИТ-проектах.
Удачи в управлении сроками!