Как прячутся за шумихой борьбы с «поддельными рисками»

Ранее я упоминал о типовой ошибке в ходе автоматизации: делать вид, что неопределенностей на проекте ERP не должно будет возникать. Однако не все руководители проектов прячут голову в песок, многие из них достаточно решительны, чтобы выявлять и ограничивать риски. И здесь иногда скрывается другая типовая ошибка: избирательная проектная близорукость.

Что это и о чем идет речь? Делая эту ошибку, менеджер выделяет для контроля малосущественные неопределенности и при этом игнорирует действительно значимые. То есть подыскивается, декларируется («пиарится») и успешно ограничивается “неправильный” риск – с которым справиться легче. А про потенциальные сложности, для контроля которых требуются большие усилия (или с которыми вообще непонятно, что делать) – забывают и оставляют в тени.

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

Далее эти проектные неопределенности успешно ограничивают. Самый радикальный и решительный способ: отказаться от рассмотрения малотиражного продукта в пользу более популяризованного. Снятие этого риска демонстрируют всем участникам проекта, таким образом, все успокаиваются и в дальнейшем пребывают в иллюзии, что теперь на проекте все под контролем. Но тем самым подменяется управление реальными угрозами проекту (самые распространенные риски: недооценка сроков, недооценка ресурсов, несоответствие типового решениям сложностям задачи и т.д).

Почему имеет место эта ошибка? Чаще всего, она совершается неосознанно. Действительно, легко и удобно забыть о том, что сложно поддается контролю, в то время как простые решения лежат на поверхности и бросаются в глаза. Кроме того, к сожалению, некоторые руководители проектов сознательно замалчивают реальные риски, подменяя их гораздо менее безопасными неопределенностями. Бытует мнение, что руководство предприятия-заказчика никогда не согласится ни какой проект автоматизации, если будет полностью в курсе всех возможных неопределенностей. И недобросовестные исполнители предпочитают развлекать и отвлекать заказчика, говоря «о чем-нибудь другом»…

Другая типичная ошибка: риск выявили, проанализировали, но не создав никакого плана действий по его ограничению – решили обозначить риск как невероятный. Чтобы иметь для самого себя оправдание бездействия в отношении этой выявленной проектной угрозы…

Возможный пример из партнерской практики: недопонимание требований к системе, их размытость и недостаточная конкретизация. На одном из проектов наших партнеров исполнитель предположил, что зафиксированные в ТЗ требования можно реализовать по-разному (формулировки спецификации это позволяют): более простым способом и очень-очень сложным, отличия же в результате при этом небольшие. Можно обозначить как риск – а нет ли какой-то вероятности, что заказчику критично важны эти небольшие отличия в результате и что доработки системы нужно реализовывать все-таки сверхсложным способом?

Начать работать с этой неопределенностью – это разворошить целый клубок проблем. Придется признать, что на предыдущем этапе составления ТЗ недостаточно специфицировали требования, так как в них есть вариативность. И если все же требуется сложный способ, то мы сильно выйдем за бюджет трудозатрат и тогда вообще непонятно, какие будут последствия. Вероятность критичности разницы в требованиях – мала. И очень заманчиво обозначить риск вместо «низковероятного» (но требующего проработки!) – как «абсолютно невероятный»!

Очевидно, простая декларация риска невероятным не делает его возникновение невозможным. Зато (и это менее очевидно) такая декларация часто делает совершенно невозможным дальнейший контроль риска.

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

[evc_social_likes]