8 (800) 500-61-51, 8 (495) 260-28-08 Будни с 9:00 до 18:00 по мск 127473, г. Москва, ул. Селезневская, д.34

Заказать звонок

Дочерняя компания 1С

Сколько дат завершения ERP-проекта в голове у менеджера?

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

И это не разовые ошибки, а статистика подавляющего большинства проектов. Почему так происходит и к каким последствиям это приводит?
Ответ на первый вопрос: дело не только в чрезмерном оптимизме. Есть более весомая причина: руководители проектов вполне справедливо уверены, что если назвать сотрудникам на проекте более позднюю дату (например, вместо «оптимистичного» февраля обозначить с запасом апрель) – они будут только рады ориентироваться на апрель и никогда не закончат работы раньше. А так, если всем сказали, что проект должен быть реализован к февралю, то есть хотя бы небольшой шанс… Может быть к этой дате они мобилизуются… На деле, мобилизуются ли сотрудники или нет – такой подход ошибочный в любом случае.

Он не влечет проблем только в том случае, если к завершению проекта не привязано никаких мероприятий. То есть если реальная дата выполнения работ не критична для Заказчика. Но так бывает редко…

Один из недавних примеров наших проектов: консолидация учета по группе предприятий. Три завода организационно объединялись в одну структуру. И к 1 июля их операции должны были поддерживаться новой автоматизированной системой, иначе управление объединенной бизнес-единицей будет просто невозможно. А это привело бы к серьезнейшим убыткам. Разумеется, как на любом другом проекте автоматизации – не обошлось без реализовавшихся рисков. Возникали проблемы с субподрядчиком, пользователи не успели вовремя ввести начальные остатки и т.д.

Риски не повлекли катастрофы, в том числе благодаря наличию резерва: во всех внутренних планах завершение работ у нас было намечено на середину мая. Таким образом, до 1 июля мы имели в запасе две недели на решение непредвиденно возникших проблем и на запуск системы к требуемому сроку.

Посмотрим на график вероятности завершения проекта в срок в зависимости от даты (график базируется на выкладках Де Марко, о котором упоминалось ранее).

datmen

Выполнить проект к дате N (которую всем назвали как плановую дату окончания работ) в реальной жизни фактически невозможно. Это было бы достижимо только в том случае, если автоматизация пойдет по идеальному пути: не случится ни одного неблагоприятного события, все предположения по требованиям к системе окажутся абсолютно верными, все экспертные оценки трудозатрат будут точными и т.д. К сожалению, мы живем не в идеальном мире. И на практике наиболее вероятной датой сдачи проекта будет дата Д2 (которая, по статистическим данным, примерно на 50% дальше от начала координат относительно N).

Примерно такая же ситуация возникает, если попытаться рассчитать сколько времени ехать из пункта А в пункт Б, между которыми 100 ум, если средняя скорость по шоссе равна 100 км/ч (приблизительно). 1час ? Конечно нет. Что с этим делать? Декларировать всем участникам «правильную» дату Д2? Но в начале статьи упоминалось достаточно обоснованное мнение менеджеров, что в этом случае сотрудники будут стремиться выполнить работу к этой Д2 (а не дате N), а возникающие неопределенности и непредвиденные обстоятельства сдвинут срок еще на 50% – в еще более отдаленное будущее. Вывод достаточно очевиден: нужно отказаться от плохой привычки хвататься за первую названную дату, как за единственную.

Менеджер должен оперировать несколькими датами. Первая из них ставится как целевая для рабочей группы проекта, вторая – как реальная дата сдачи проекта для заказчика. Это не значит, что надо заведомо скрывать информацию от сотрудников на проекте (или еще хуже – вводить их в заблуждение). Речь не об этом, просто мотивация рабочей группы должна быть ориентирована на максимально возможное соблюдение срока, близкого к дате N. В то время как взаимосвязанные с результатом проекта стратегические мероприятия можно планировать только после Д2. То есть Заказчику не должно быть дела до даты N и ориентироваться на нее Заказчику ни в коем случае не следует.

[evc_social_likes]

01.09.2013
^