Девять рисков, которые могут погубить все
ваши проекты

На всех этапах реализации проекта существуют угрозы, которые могут привести к его провалу. Неприятности могут поджидать любой проект. Китайский философ Конфуций говорил: «Того, кто не задумывается о далеких трудностях, непременно поджидают близкие неприятности». Это значит, что планирование, хоть оно и непопулярно сегодня на рынке, приносит свои результаты, а понимание моделей и типов риска может сэкономить время и ресурсы бизнеса.

Модель швейцарского сыра

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

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

Модель «галстук-бабочка»

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

Модель галстук-бабочка широко распространена в России, даже используется в национальном стандарте ГОСТ Р ИСО 31000.

Для проекта это выглядит так: с одной стороны — «дерево угроз», описывающее, что может пойти не так. С другой стороны, ограничения, которые существуют у проекта и фиксируются на его старте: сроки, бюджет, удовлетворенность заказчика, надежность и производительность системы. По соблюдению этих ограничений определяется успех: если во все ограничения уложились, то проект можно считать успешным.

Угроза может привести к некоторому происшествию, которое не позволит нам вписаться в ограничения проекта.

Например, один из наиболее распространенных рисков для всех ИТ проектов — задержка принятия ключевых решений (допустим, согласования технического задания на систему). Причиной может быть отпуск ключевых сотрудников, которые должны согласовать ТЗ.

Получается цепочка: ключевых сотрудников нет, техническое задание вовремя не согласовано, обязательства заказчика не выполнены, сроки увеличиваются. Когда после продолжительного времени техническое задание согласовано, компания начинает ускорять другие процессы в этой цепочке действий, чтобы все-таки успеть.

Но если мы в рамках выстраивания системы управления проектом введем обязательное требование согласовывать отпуск с проектным менеджером, возникнет преграда. Она вполне может быть и дырявой, ведь высоко стоящие в иерархии компании сотрудники могут просто проигнорировать правило.

Другая частая проблема с техническим заданием — перегрузка ключевых сотрудников, которые рассматривают и согласовывают проект с операционной работой. Риск этот настолько распространенный, что его нужно вводить в список обязательных к отработке везде, где участники проектной команды не располагают 100% времени на проект.

Типовые риски

Есть много реестров типовых рисков, но спустя 20 лет работы в этой области я позволю себе выделить девять основных ситуаций и угроз, которые губят проект. Они объединяются в три группы.

1. Определение проекта

Проект не продуман, не проработан, не согласован ключевыми участниками, не зафиксирован в ряде ответов на ключевые вопросы:

Зачем нужен проект? Нельзя понять цели проекта и эффекты от его реализации в компании.

Как выполнять проект? Любой проект можно выполнять множеством разных способов с использованием абсолютно разных подходов. Например, менять требования к качеству и охвату, выполнять какие-то работы быстрее или медленнее, что-то последовательно, что-то параллельно. А можно не тратить время на размышления, а переходить к активным действиям в спешке. К примеру, в апреле 2015 года в Москве решили, что ко дню города в сентябре нужно обустроить почти полсотни центральных улиц. На тщательное планирование, проработку деталей времени не оставалось. Проектирование шло параллельно со стройкой, что привело к мощному транспортному коллапсу, острому негативу жителей и большому количеству технических ошибок.

Что будет результатом проекта? Если ответа на этот вопрос нет, непонятно, как конкретно должен выглядеть финальный продукт, нет его единого продуманного, проработанного, зафиксированного образа. Если говорить о проектах организационных изменений в компании, непонимание финального продукта — обычное дело. «Давайте изменим корпоративную культуру на более гибкую и открытую?» Часто на это предложение отвечают: «Да, отличная идея!» Но как посчитать что культура изменилась, как измерить результат?

2. Команда проекта

Кто и что должен сделать для получения результатов? Риск неправильного ответа на этот вопрос часто может быть связан с предыдущей угрозой. Если непонятно, что нужно сделать, то сложно сказать, кто и что для этого должен сделать именно сегодня, именно здесь. Стратегия в этой ситуации у большинства сотрудников — «сидим и ждем, пока кто-то скажет». Неактивность, неготовность брать на себя ответственность и идти вперед без команды — одна из больших проблем российских сотрудников.

Еще один риск: члены команды не могут выполнить задачи проекта. Исполнители не имеют достаточной компетенции, их поставили на проект без понимания возможностей. Эта проблема знакома многим, кто делал один из самых простых (на самом деле нет) проектов — ремонт в собственной квартире. «Чертовы бракоделы!» — один из самых мягких вариантов того, что звучит в таком случае.

Или еще один вариант проблемы: члены команды не хотят выполнять задачи проекта. Сотрудники компетентны, но они не понимают, почему им нужно заниматься задачами проекта, особенно если у них есть основная работа.

3. Принятие решений

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

Принятие решений блокируется конфликтами между топ-менеджерами, подразделениями, членами команды. Наша «византийская» система управления сама по себе порождает эти конфликты в большом количестве.

Ключевые решения по проекту часто и неуправляемо меняются. Изменения — это нормально. Ненормально, если они неуправляемые. К сожалению, это очень частое явление, особенно относительно рамок проекта. Есть даже специальный термин — scope creep, то есть неконтролируемое расползание границ проекта. Проблемы происходят, не только когда меняются рамки проекта. Любые ключевые параметры должны меняться управляемо и организованно.

Что нужно делать с этими рисками? Могу сослаться на свою статью «Победа над хаосом: как можно эффективно управлять проектами в России». Нужно выстроить систему управления, отталкиваясь от тех угроз, которые видны для проекта, выбрав наиболее важные элементы системы управления проектом.

Разберем, например, четвертый риск — ситуацию, когда неясно, кто и что должен сделать для получения результатов. Выберем несколько ломтиков сыра — элементов системы управления проектом, которые помогут с ним бороться.

Стартовое совещание по проекту. Все участники проекта информируются о том, кто, что и когда должен сделать, какая у каждого из участников ответственность. После собрания уже никто из ключевых лиц не может сказать: «Что это за проект? Впервые о нем слышу! Не должен я ничего делать».

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

Дорожная карта или RoadMap — это высокоуровневый план, включающий ключевые блоки работы и ключевые контрольные точки. У каждой контрольной точки должен быть ответственный.

Регулярные встречи рабочей группы. Если кто-то из членов проектной команды не понимает, что ему конкретно сейчас нужно делать для достижения целей проекта, то на встречах он должен будет об этом сказать. Формат таких встреч вполне определенный: каждый рассказывает, что он делал на прошлой неделе, что планирует делать на этой, какие есть проблемы и барьеры, мешающие работе.

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

Матрица распределения ответственности фиксирует распределение ответственности за ключевые работы и результаты проекта между участниками. Матрица позволяет просто и наглядно увидеть, кто и за что отвечает.

Этот список можно расширять. Подчеркну, что каждый из элементов по отдельности проблему не решит, но они вместе вполне могут стать непроницаемой стеной на пути рисков. Не швейцарским сыром, а нашим плотным пошехонским, в котором, как известно, дырки совсем маленькие.

Подумайте о своем проекте (насколько для него характерны девять перечисленных выше рисков?) и помните, что «с нами такого случиться не может» — самая популярная фраза, которую произносят перед очередным провалом.