Избирательная проектная близорукость
Избирательная проектная близорукость — типовая ошибка, возникающая в ходе процесса автоматизации. Она проявляется в том, что менеджер проекта выделяет для контроля малосущественные неопределенности и при этом игнорирует действительно значимые. Подыскивается, декларируется («пиарится») и успешно ограничивается «неправильный» риск — риск, с которым легко справиться. Другие потенциальные проектные неопределенности, для контроля которых требуются большие усилия (или с которыми вообще непонятно, что делать) — забываются и оставляются в тени.
Например, заказчику или его возможному партнеру — исполнителю проекта очень просто озаботиться риском: «Опасно внедрять инновационный программный продукт, поскольку опасно быть не как все!». А вдруг возникнут сложности с дальнейшим его сопровождением? А вдруг на предыдущих нескольких десятках внедрений этот продукт ещё недостаточно обкатан? А вдруг...?
Далее подобного рода проектные «риски» успешно ограничиваются. Самый радикальный и решительный способ: отказаться от рассмотрения нового программного продукта в пользу более популярного, который «у всех на слуху». Снятие этого «риска» демонстрируется всем участникам проекта. Все успокаиваются и пребывают в иллюзии, что теперь на проекте все под контролем.
Таким образом, управление реальными угрозами проекту, самые распространенные из которых: недооценка сроков и ресурсов проекта, несоответствие типового решения сложностям решаемой задачи и т.д., подменяются проектной близорукостью.
Однако надо признать, что такая ошибка чаще всего совершается не по злому умыслу, а неосознанно. Действительно, удобно забыть о том, что с трудом контролируется, в то время как простые решения лежат на поверхности и бросаются в глаза. Кроме того, к сожалению, некоторые руководители проектов, выступающие в роли исполнителей, сознательно замалчивают реальные риски, подменяя их гораздо менее безопасными неопределенностями. К тому же, бытует мнение, что руководство предприятия-заказчика никогда не согласится ни на какую автоматизацию, если будет в курсе всех возможных неопределенностей проекта. И недобросовестные исполнители предпочитают развлекать и отвлекать заказчика, говоря «о чем-нибудь другом»... В таком отношении исполнителя к заказчику тоже проявляется проектная близорукость.
Признание риска невероятным
Другая типичная ошибка проекта автоматизации: риск выявили, проанализировали, но, не создав никакого плана действий по его ограничению, решили обозначить риск как невероятный. Чем не оправдание своего бездействия в отношении выявленной проектной угрозы?
Пример из практики. Недопонимание требований к системе автоматизации, их размытость и недостаточная конкретизация.
На одном из проектов исполнитель предположил, что зафиксированные в техническом задании требования можно реализовать разными способами (формулировки спецификации к проекту позволяли это сделать). Один из способов — простой, другой — очень сложный. Отличия же в результате при этом небольшие. Чтобы не тратить зря время, руководитель проекта от исполнителя дал указание своим программистам кодировать «простым способом» без долгих обсуждений с заказчиком, приняв за бесконечно малую вероятность необходимость сложного пути. Однако позже выяснилось, что эти минимальные различия в результате способов реализации для заказчика действительно были критично важны!
Очевидно, официальное заявление (декларация) исполнителя проекта о невероятности риска не делает его возникновение невозможным. Зато (и это менее очевидно) такая декларация часто делает совершенно невозможным дальнейший контроль риска, признанным невероятным.
Допустимые риски
Следует отметить, что на проекте возможно возникновение ряда неопределённостей, которые все-таки допускается проигнорировать. Во-первых, это те неопределённости, которые маловероятны и при этом их последствия незначительны.
Во-вторых, это неопределённости, последствия которых, наоборот, слишком значительны. При своей реализации они делают результат проекта уже не нужным ни для одной из сторон, ни для заказчика проекта, ни для его исполнителя. Да, такое тоже бывает.
Несколько дат завершения проекта
Ещё одна типовая ошибка, допускаемая многими руководителями проектов, заключается в неверной оценке сроков завершения проекта. Всегда существует несколько дат завершения проекта! Однако, определяя длительность этапа работ (или проекта в целом), менеджеры склонны утверждать самую раннюю из предполагаемых дат завершения как плановую. То есть именно на самый оптимистичный срок декларируется реальная сдача проекта. И это не разовая ошибка отдельных руководителей, а статистические данные подавляющего большинства проектов.
Причина этого кроется не только в чрезмерном оптимизме. Есть более весомые обстоятельства. Так, руководители проектов вполне справедливо считают и уверены в том, что если назвать сотрудникам более позднюю дату проекта (например, вместо «оптимистичного» февраля обозначить с запасом апрель), они будут только рады ориентироваться на апрель и никак не закончат работы раньше. Если же всем сказать, что проект должен быть завершён к февралю, то появится хотя бы небольшой шанс... Может быть, к этой дате они мобилизуются...
Однако в любом случае — мобилизуются сотрудники или нет, такой подход ошибочный. Он не повлечёт за собой проблем только тогда, когда к сроку завершению проекта не привязано никаких мероприятий, когда реальная дата окончания проектных работ абсолютно не критична для заказчика. Но так бывает редко...
Пример из практики. Автоматизация консолидации учета группы предприятий.
Три завода организационно объединялись в одну структуру. И к 1 июля их операции должны были поддерживаться новой автоматизированной системой, иначе управление объединенной бизнес-единицей будет просто невозможно, и это привело бы к серьезнейшим убыткам.
Разумеется, как на любом другом проекте автоматизации, не обошлось без реализовавшихся рисков. Возникали проблемы с субподрядчиком, пользователи не успели вовремя ввести начальные остатки и т.д. Риски не повлекли катастрофы, в том числе, и благодаря наличию резерва: во всех внутренних планах было намечено завершение работ на середину мая. Таким образом, до 1 июля имелся запас в две недели на решение непредвиденно возникших проблем и на запуск системы к требуемому сроку.
Выполнить проект к дате N (которую всем назвали как плановую дату окончания работ) в реальной жизни фактически невозможно (см. график).
График вероятности завершения проекта
Это было бы достижимо только в том случае, если автоматизация пойдет по идеальному пути: не случится ни одного неблагоприятного события, все предположения по требованиям к системе окажутся абсолютно верными, все экспертные оценки трудозатрат будут точными и т.д.
К сожалению, наш мир не идеален, и на практике наиболее вероятной датой сдачи проекта будет дата Д2 (которая, по статистическим данным, отстоит от даты N на величину примерно на половину срока от начала координат до даты Д2).
Что с этим делать? Декларировать ли всем участникам проекта «правильную» дату Д2? Но ведь существует достаточно обоснованное мнение менеджеров, что в этом случае сотрудники будут стремиться выполнить работу к дате Д2, а не к дате N. А возникающие неопределенности и непредвиденные обстоятельства сдвинут срок еще на 50% в будущее.
Ответ на эти вопросы очевиден: нужно отказаться от плохой привычки хвататься за первую названную дату, как за единственную. Менеджер должен оперировать несколькими датами. Первая из них ставится как целевая для рабочей группы проекта, вторая — как реальная дата сдачи проекта для заказчика. Это не означает, что надо заведомо скрывать информацию от сотрудников на проекте (или еще хуже — вводить их в заблуждение). Речь не об этом, просто мотивация рабочей группы должна быть ориентирована на максимально возможное соблюдение срока, близкого к дате N. В то время как взаимосвязанные с результатом проекта стратегические мероприятия можно планировать только после даты Д2.
В этом случае заказчика проекта не должна волновать дата N и ориентироваться на нее ему ни в коем случае не следует.
Чтобы оставить комментарий пожалуйста Авторизуйтесь