Мы продолжаем наш цикл о типичных ошибках в календарном планировании. Наш сегодняшний рассказ – о том, насколько важно помнить об итеративности планирования и постоянно возвращаться к нему в течение жизненного цикла проекта. (Те, кто пропустил первую главу – о сознательном обмане в календарном планировании – могут прочитать ее здесь).
Ошибка №2. Игнорирование жизненного цикла проекта
Вторая ошибка, распространенная в календарном планировании, заключается в следующем: менеджеры проектов часто забывают, что планирование – это итеративная функция, что к планированию необходимо возвращаться в ходе реализации проекта постоянно и корректировать планы в соответствии с вновь возникающими обстоятельствами. Более того, об этой особенности жизненного цикла проекта необходимо информировать заказчика. Ведь, как правило, заказчик требует детальный календарный план еще до вхождения в проект – для того, чтобы решить, запускать проект или нет. При этом на самом деле детальный календарный план может появиться только после того, как пройден этап концепции, на этапе разработки.
Менеджер проекта должен работать со своим заказчиком – научить его мыслить в категориях точности оценок. Проект – это мероприятие, сопряженное со случайностями, неопределенностью. Соответственно, точные цифры проекта мы узнаем только в момент завершения проекта. В любой другой момент в процессе реализации проекта цифры будут неточными. Об этом нужно прямым текстом сообщать заказчику: сроки, которые мы обещаем, не являются окончательными.
Погрешность должна уменьшаться по мере приближения к завершению проекта. Если вы меня спросите: «Сколько нужно времени для внедрения системы управления проектами в моей компании, где работает столько-то человек?», и я навскидку отвечу: «Мы попробуем уложиться в 12 месяцев», вы не должны быть на меня в претензии, если внедрение в итоге займет 24 месяца. Потому что я потратил на анализ информации несколько секунд, не делая расчетов, не привлекая экспертов, а используя только аналоговую оценку: «Я внедрял управление проектами в похожей компании, где работает примерно столько же человек, и это заняло у меня 12 месяцев». Оценка, которую я дал в данном случае – это грубый порядок величины. Отклонение на 100 и даже на 200% – нормально на начальных этапах концепции.
В другой ситуации, если на подготовку ответа я потрачу неделю – посоветуюсь с экспертами, набросаю укрупненный календарный план, и дам ответ – 15 месяцев, а внедрение займет, например, 18 месяцев, вы тоже не должны на меня обижаться. Это порядок величины, и в данном случае отклонение на 70-75% является совершенно адекватным ситуации.
В третьей ситуации, когда проект находится в фазе разработки, когда уже получены предложения подрядчиков, желательно довести точность оценки до 30-40%. Это бюджетная оценка.
Самая главная цифра, к которой мы все стремимся, и которую незрелый заказчик, к сожалению, требует в первый день проекта, может быть получена только перед переходом в фазу реализации. Это точная оценка.
Парадокс заключается в том, что это тоже оценка неточная. Здесь погрешность может составлять 10%. Мы призываем менеджеров проекта использовать эти термины – грубый порядок величины, порядок величины, бюджетная оценка, точная оценка – каждый раз, когда они общаются с заказчиками: заказчик должен точно понимать, чего и когда он может ожидать. В американской ассоциации стоимостного инжиниринга AACE точность оценки разбивают на 5 классов точности: «бюджет проекта по классу точности 5» означает, что оценка является очень приблизительной, «бюджет проекта по классу точности 2» означает, что погрешность есть, а «бюджет проекта по классу точности 1» означает, что погрешность составляет не более 5-10%. Управление проектами нуждается в подобной классификации, и менеджеры проектов должны использовать соответствующие термины, осуществляя календарное планирование.
Михаил Дубовик,
Управляющий партнер, Директор Учебно-консультационного Центра, Сертифицированный специалист по управлению проектами (категория D в системе сертификации IPMA), Сертифицированный профессионал в области управления проектами PMP (PMI).
Статья подготовлена по материалам семинара «Управление сроками проекта: учимся на чужих ошибках» 14.12.2016