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