Неприятности могут поджидать любой проект. Китайский философ Кунь-фу-цзы, известный нам больше, как Конфуций говорил: «Того, кто не задумывается о далеких трудностях, непременно поджидают близкие неприятности». Это значит, что планирование, хоть это и не популярно сегодня на рынке, приносит свои результаты, а понимание моделей и типов риска, может сэкономить время и ресурсы бизнеса.
Модель швейцарского сыра
Еще ее называют моделью кумулятивного, т.е. накопленного действия. В бизнес эта модель попала из авиации. Ее суть – ставить на пути вероятного происшествия как можно больше преград (ломтиков сыра). Если бы ломтики были сплошные и непроницаемые, то происшествия бы не происходили. Но ломтики, к сожалению, не сплошные – в них есть дырки- отдельные упущения и ошибки в работе (швейцарский сыр как раз содержит много дырок, отсюда и название). Такие упущения существуют в любой системе и на любом уровне.
Для каждой новой преграды (ломтика сыра), они расположены в разных местах – если проблема прошла через одну преграду, она будет остановлена следующей – это останавливает развитие нежелательного явления. Такая система преград защищает работу от масштабных происшествий, которые будет сложно или невозможно устранить. Происшествие станет возможным, если только все пробелы выстроятся в ряд. Чтобы этого не произошло, в авиации, например, задействуют много «листов сыра» – пред и послеполетные проверки, замены агрегатов, обучения, тренировки и еще много другого.
Модель Галстук-бабочка
Несколько измененная модель швейцарского сыра. В центре находится событие, которое компания хочет предотвратить. Она может
предпринять предупреждающие меры, и предусмотреть план уменьшения ущерба, если событие все-таки произойдет.
Модель галстук-бабочка широко распространена в России, даже используется в национальном стандарте ГОСТ Р ИСО 31000.
Для проекта это выглядит так: с одной стороны – «дерево угроз», что может пойти не так. С другой, ограничения, которые существуют у проекта и фиксируются на его старте: сроки, бюджет, удовлетворенность заказчика, надежность и производительность системы. По соблюдению этих ограничений определяется успех, если во все ограничения уложились, то проект можно считать успешным.
Угроза может привести к некоторому происшествию, которое не позволит нам вписаться в ограничения проекта.
Например, один из наиболее распространенных рисков для всех ИТ проектов – задержка принятия ключевых решений, например согласования технического задания на систему. Причиной может быть отпуск ключевых сотрудников, которые должны согласовать ТЗ.
Получается цепочка – ключевых сотрудников нет, техническое задание вовремя не согласовано, обязательства заказчика не выполнены, сроки увеличиваются. Когда после продолжительного времени техническое задание согласовано, компания начинает ускорять другие процессы в этой цепи действий, чтобы все-таки успеть.
Но если мы в рамках выстраивания системы управления проектом введем обязательное требование – согласовывать отпуск с проектным менеджером, возникнет преграда. Она может вполне быть и дырявой – высокопоставленные сотрудники компании могут просто дружелюбно проигнорировать это правило.
Другая распространенная проблема с техническим заданием – перегрузка ключевых сотрудников, которые рассматривают и согласовывают проект с операционной работой. Риск настолько распространенный, что его нужно вводить в список обязательных к отработке в любом корпоративном ИТ и везде, где участники проектной команды не располагают 100% времени на проект.
Типовые риски
Есть много реестров типовых рисков, но спустя 20 лет работы в этой области я выделяю 9 основных ситуаций и угроз, которые губят проект. Они объединяются в три группы.
1. Определение проекта
При определении проекта не продуман, не проработан, не согласован ключевыми участниками и не зафиксирован в каком-то виде ряд ответов на ключевые вопросы:
ЗАЧЕМнужен проект? Нельзя понять цели проекта и эффекты от его реализации в компании. В феврале 2018 года консалтинговая компания Resulting IT опубликовала исследование по внедрению системы SAP ERP. В опросе приняли участия представители 105 компаний, использующих софт немецкого вендора. 77% руководителей не смогли распознать преимущества при внедрении софта SAP, и ответили, что таковых не было. Примерно половина опрошенных считают, что выполненные SAP-проекты оказались не связанными с их бизнес-стратегиями, а такое внедрение стоит миллионы и миллионы долларов.
КАК выполнять проект? Любой проект можно выполнять множеством разных способов, с использованием абсолютно разных подходов. Например, менять требования к качеству и охвату, выполнять какие-то работы быстрее или медленнее, что-то последовательно, что-то параллельно. А можно не тратить время на размышления, а переходить к активным действиям в спешке. В апреле 2015 года решили, что ко дню города в сентябре нужно обустроить почти полсотни центральных улиц – московский городской проект «Моя улица». На тщательное планирование, проработку деталей времени не оставалось. Проектирование шло параллельно со стройкой, что привело к мощному транспортному коллапсу, острому негативу жителей и большому количеству технических ошибок. На Мясницкой улице, например, забыли сделать ливневую канализацию и уже в начале сентября ее затопило. Москве еще повезло – первоначальный план был охватить разом 150 улиц.
ЧТО будет результатом проекта? Непонятно, как конкретно должен выглядеть финальный продукт, нет единого продуманного, проработанного, зафиксированного образа этого продукта. Такая ситуация не слишком характерна для строительных и инжиниринговых проектов: строгие нормативные документы запрещают строить без документации, описывающей продукт. Они требуют четко определить будет у тебя двухэтажный коттедж или пятиэтажная гостиница и какими они будут. Бывают любопытные ситуации, например, стадион «Зенит Арена», стоимость которого была увеличена уже в процессе более чем на 700% из-за многочисленных изменений требований, а также все тот же проект «Моя улица» очень показателен. Если говорить о проектах организационных изменений в компании, непонимание финального продукта – обычное дело. «Давайте изменим корпоративную культуру на более гибкую и открытую! Да, отличная идея!». А как посчитать что культура изменилась, как измерить результат? «Там разберемся и вообще это скучно – давайте не будем о грустном».
2. Команда проекта
Не ясно, КТО и ЧТО должен сделать для получения результатов. Это часто может быть связано с предыдущей угрозой. Если непонятно, что нужно сделать, то сложно сказать, кто и что для этого должен сделать именно сегодня, именно здесь. Стратегия в этой ситуации у большинства сотрудников – сидим и ждем пока кто-то скажет. Неактивность, не готовность брать на себя ответственность и идти вперед без команды одна из больших проблем российских сотрудников.
Члены команды НЕ МОГУТ выполнить задачи проекта. Исполнители не имеют достаточной компетенции, их поставили на проект без понимания возможностей. Эта проблема знакома многим, кто делал один из самых простых (на самом деле нет) проектов – ремонт в собственной квартире. «Чертовы бракоделы!» – один из самых мягких вариантов того, что звучит в таком случае.
Члены команды НЕ ХОТЯТ выполнять задачи проекта. Сотрудники компетентны, но они не понимают, почему им нужно заниматься задачами проекта, особенно, если у них есть основная работа. Я уже приводил выше пример с согласованием технического задания: «Некогда – у нас своя основная работа есть».
3. Принятие решений
Руководство ЗАТЯГИВАЕТ процесс принятия решений. Одно из самых распространенных явление. Ясна проблема, ясно что ее нужно решать, даже ясно как, но решения не принимается. Характерен пример одного из крупных российских государственных институтов развития, финансирующий несколько десятков крупных инновационных проектов. В марте руководитель дочернего фонда, отвечающего за финансирование проектов, подает заявление об увольнении, нового не назначают. В мае внезапно (на самом деле нет – их ждали с февраля) приходят деньги, которые нужно довести до проектов. Внезапно (на самом деле нет), выясняется, что сделать это без генерального директора невозможно. Начинается гиперактивная работа по поиску и согласованию кандидатуры гендиректора, его оформлению и срочному проведению платежей. Две недели все причастные «тушат пожар». Их текущая работа почти полностью останавливается. В итоге, проекты получают финансирование с задержкой в месяц, а запланированные проекты института развития массово переносятся.
Принятие решений БЛОКИРУЕТСЯКОНФЛИКТАМИ между топ-менеджерами, подразделениями, членами команды. Наша «византийская» система управления сама по себе порождает эти конфликты в большом количестве. В моей практике работы в крупной российской компании был случай, когда решение о запуске проекта переносилось шесть раз из-за конфликта двух топ-менеджеров. Один принципиально не хотел одобрять проект своего «врага».
Ключевые решения по проекту часто и НЕУПРАВЛЯЕМО МЕНЯЮТСЯ. Изменения – это нормально. Ненормально, если они неуправляемые. К сожалению, это очень частое явление, особенно относительно рамок проекта. Есть даже специальный термин – scope creep – неконтролируемое расползание границ проекта. Проблемы происходят не только когда меняются рамки проекта. Любые ключевые параметры должны меняться управляемо и организованно. Например, проект строительства «Зенит Арены» создавался на основе договоренностей, а не документов, когда менялся курс рубля, губернатор планы и задумки, снова нужно было передоговариваться.
Что нужно делать с этими рисками? Могу сослаться на свою недавнюю статью в Harvard Business Review – «Победа над хаосом: как можно эффективно управлять проектами в России». Нужно выстроить систему управления, отталкиваясь от тех угроз, которые видны для проекта, выбрав наиболее важные элементы системы управления проектом.
Разберем, например, четвертый риск: не ясно кто и что должен сделать для получения результатов. Выберем несколько ломтиков сыра – элементов системы управления проектом, которые помогут с ним бороться:
Стартовое совещание по проекту. Все участники проекта информируются о том, кто, что и когда должен сделать, какая у каждого из участников ответственность. После собрания уже никто из ключевых лиц не может сказать: «Что это за проект? Впервые о нем слышу! Не должен я ничего делать».
Документ, запускающий проект (Устав, Приказ о запуске проекта, Запрос на проект). Он фиксирует основные параметры проекта и обязательства проектной команды. После его утверждения становится понятно, что нужно сделать в рамках проекта, кто этим будет заниматься.
Дорожная карта или RoadMap – высокоуровневый план, включающий ключевые блоки работы и ключевые контрольные точки. У каждой контрольной точки должен быть ответственный.
Регулярные встречи рабочей группы – если кто-то из членов проектной команды не понимает, что ему конкретно сейчас нужно делать для достижения целей проекта, то на встречах он должен будет об этом сказать. Ведь формат встречи вполне определенный: каждый рассказывает, что он делал на прошлой неделе, что планирует делать на этой неделе, какие есть проблемы и барьеры, мешающие работе.
Рабочий список задач проекта – кто и что должен делать в ближайшее время для получения запланированных результатов.
Матрица распределения ответственности. Фиксирует распределение ответственности за ключевые работы и результаты проекта между участниками. Матрица позволят просто и наглядно увидеть кто и за что отвечает.
Этот список можно еще расширять. Подчеркну, что каждый из элементов по отдельности проблему не решит, но они вместе вполне могут стать непроницаемой стеной на пути рисков. Не швейцарским сыром, а нашим плотным, пошехонским (в пошехонском сыре дырки совсем маленькие).
Подумайте о своем проекте – насколько для него характеры девять перечисленных выше рисков. Они типовые, стандартные, очень и очень распространенные. Не отмахивайтесь от них «с ходу» – вспомните, что «с нами такого случиться не может» — это фраза номер один в списке знаменитых последних слов.