8 октября
КАК НАЛАДИТЬ НЕТВОРКИНГ И УВЕРЕННО ЗАЯВЛЯТЬ О СЕБЕ: воркшоп по самопрезентации от команды "Про бизнес", 25 октября
1 | 3 | 1 |
Почему при словах «мы начинаем новый проект» внутренний голос часто говорит: «и снова сорвем сроки»? Есть простое объяснение. Большинство проектов действительно срывают плановые сроки.
Посмотрите на эти таблицы.
Статистика успешности ИТ-проектов в мире
Сроки, бюджеты и реализация требований в категории «спорных» ИТ-проектов
Из 43% проектов, которые в 2012 году признали «спорными», проблемы со сроками испытали 74% проектов. Перемножив два числа, получаем, что в 32% от общего числа ИТ-проектов были сорваны сроки. Плюс еще 18% «провальных», в которых наверняка были проблемы со сроками. Получается, что в 50% случаев ИТ-проекты не завершаются в плановый срок.
Если верить этому исследованию, в России в 2007 году в срок выполнялось только 4% ИТ-проектов. Если бы подобная статистика была по ИТ-проектам в Беларуси, то, я уверен, она бы не сильно отличалась. И вряд ли ситуация радикально улучшилась за последние семь лет.
Что же происходит? Оказывается, у нас вообще плохо обстоит дело с прогнозами, особенно долгосрочными. Об этом пишут когнитивные психологи, например, Д.Канеман.
Проекты обычно длятся от полугода до нескольких десятилетий, и чем масштабнее с точки зрения трудоемкости проект, тем ниже вероятность, что мы угадаем фактический срок его реализации. Кроме плохих прогнозов мы еще часто игнорируем и давно проверенные инструменты «управления проектами», что усугубляет ситуацию.
Итак, каковы причины срыва сроков проектов? На мой взгляд, они следующие:
Для оценки проектов на старте можно использовать метод аналогов. Но в Беларуси есть проблема: никто не занимается сбором и публикацией статистики по реализованным проектам. Почему? Государственным органам это не нужно, а частные компании пока не понимают значимости такой статистики и, скорей всего, не готовы делиться достоверной информацией о выполненных проектах. А, представьте, как облегчилась бы участь руководителя проекта, если бы он имел возможность изучить опыт ста похожих проектов и узнать в какой диапазон по срокам и бюджету они уложились!
Статистика The Standish Group явно демонстрирует нам зависимость успеха от масштаба проекта. Если намечается ИТ-мегапроект, я рекомендую разбить его на небольшие проекты и управлять ими как программой проектов. По небольшому проекту и прогноз сроков окажется более достоверным.
Я рекомендую выделить сбор и анализ требований к продуктам в отдельный проект. Не для всех проектов этот вариант будет верным (есть подходы к управлению проектами, которые рекомендуют сбор и анализ требований проводить параллельно с разработкой продукта). Понятно, что в процессе реализации требования могут измениться. Но если они были хорошо проработаны, то, скорее всего, изменятся на 10-20% по отношению к первоначальным, а не на 50-70%.
Ресурсное планирование предполагает, что длительность задач в сетевом графике рассчитывается на основании трудозатрат по задаче, ресурсов, назначенных на задачу, и «% доступности» этих ресурсов. Зачастую руководители проектов даже не проверяют адекватность сроков работ в плане с учетом имеющихся ресурсов. По сути, они составляют график работ, исходя из предположения, что ресурсов будет достаточно для выполнения задач в плановый срок.
Оценив продолжительность задач проекта с учетом имеющихся ресурсов и, построив сетевой график, руководитель проекта может получить прогноз сроков, используя такие подходы, как метод критического пути и метод критической цепочки. Метод критической цепочки является, на мой взгляд, более прогрессивным, хотя требует ряда организационных изменений, на которые пойдет не любая компания.
Понимая то, что требования по ходу реализации проекта будут меняться, руководителю проекта вместе с заказчиком следует выстроить процедуру ранжирования требований и определить, без каких из них продукт проекта невозможно будет использовать (must have), а какие являются желательными (nice to have). Если вдруг сроки будут затягиваться, команда проекта сможет подготовить работающий продукт, включающий ключевые требования, и передать его в эксплуатацию, а остальные требования (nice to have) можно реализовать на этапе промышленной эксплуатации продукта.
Дату завершения проекта, которая рассчитана без учета имеющихся в проекте рисков, называют «нанопроцентной датой». Потому что вероятность завершения проекта именно в эту дату составляет примерно один нанопроцент…
Даже хороший план может привести к провалу, если не выстроена адекватная система контроля хода работ по проекту. Чаще всего руководители проекта получают информацию о ходе работ в виде отчета по статусам задач. Что-то типа:
0% – задача не начата
50% – в работе
100% – закончена
Мало того, информация о выполнении работ собирается не каждый день, а раз в неделю (или еще реже). Я считаю, что для большинства проектов такой уровень контроля недостаточен. Мне, как руководителю проекта, хочется каждый день иметь понимание, какой объем работ по проекту уже сделан, а какой еще остался. И делать прогнозы о завершении проекта в срок.
В управлении проектами уже давно существует методика контроля проекта, которая удовлетворяет моим требованиям – это методика освоенного объема. Правда, она предполагает использование «% физического выполнения объемов работ» либо «% завершения по трудозатратам» по каждой задаче проекта.
Приведу пример: задача запланирована на 10 человеко-часов. Исполнитель сегодня потратил на нее 6 человеко-часов, каков «% завершения задачи»?
Можно подумать, что задача завершена на 60% (6 часов из 10 уже потрачено), но что если это не так и исполнителю нужно еще 8 часов, чтобы получить результат по задаче?
В этом случае % завершения = 43% (6/(6+8) *100% = 43%).
Имея данные о фактически потраченном и оставшемся времени на задачу, руководитель проекта каждый день обладает адекватной информацией по прогнозам завершения проекта в плановые сроки.
Для использования этой методики нам придется внедрить в своем проекте отчеты о фактически потраченном и оставшемся времени по задачам. Это будет сделать непросто, но уж если мы это сделаем, то заодно решим проблему отсутствия статистики – у нас начнет накапливаться информация по фактическим трудозатратам в разрезе похожих работ.
Она проявляется в затягивании принятия решений по важным вопросам. В проекте приходится принимать тысячи решений, и, по мнению The Standish Group, в 20% случаев для принятия решений нам нужен заказчик проекта. И если решения будут приниматься дольше запланированных сроков, это, понятное дело, будет влиять на общий срок проекта.
На мой взгляд, они следующие:
1. Оценка объемов работ на старте проекта методом аналогов.
2. Небольшой размер проекта.
3. Сбор и анализ требований до старта проекта, уточнение оценки объемов работ проекта на основании требований.
4. Использование ресурсного планирования.
5. Использование методов критического пути и критической цепочки для определения сроков проекта.
6. Управление приоритетами требований и изменениями требований по ходу проекта.
7. Пристальное внимание работе с рисками.
8. Контроль проекта с помощью метода освоенного объема.
9. Назначение в проект квалифицированного и мотивированного заказчика проекта (или его представителя).
Стоит прочесть:
Удачи в управлении сроками!
8 октября
КАК НАЛАДИТЬ НЕТВОРКИНГ И УВЕРЕННО ЗАЯВЛЯТЬ О СЕБЕ: воркшоп по самопрезентации от команды "Про бизнес", 25 октября
7 октября
Суперакция на размещение рекламы на Про бизнес до 31 октября — не пропустите!
4 октября
Сотрудники банка пришли на работу вместе с животными, а клиенты поддержали благотворительную акцию Pet friendly
3 октября
«Айгенис» представляет интересы «Активлизинг» как эмитента облигаций на фондовом рынке Беларуси
2 октября
Банковское кредитование и альтернативные инструменты: все возможности финансовой поддержки бизнеса на одной площадке Ярмарки Финансирования
1 октября
Инвесторы, стартапы и скейлапы вновь встретятся на eXit 2.0: что обещает участникам обновленный формат?
30 сентября
Новый уровень защиты: подписка Kaspersky Plus теперь и для домашнего интернета от А1
26 сентября
А1 выходит на рынок виртуального хостинга и предлагает доступное решение для бизнеса