2 кейса, которые показывают, к чему приводит игнорирование рисков проекта

Многие опытные бизнесмены, начиная новый проект, проигрывают в уме катастрофические ситуации, которые могут произойти. И это правильно: тот, кто предупрежден, тот вооружен. Но, к сожалению, учитываются далеко не все риски. К чему это может привести, рассказывает наш эксперт Максим Якубович.

То, чем занимаются люди, когда думают о потенциальных проблемах в новом проекте и о том, как сегодня снизить их влияние, называется «управлением рисками».

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

Однако часто руководители и заказчики проектов не замечают «внутренних» рисков проекта, возникающих внутри компании, для которой делается проект. Повлиять на вероятность возникновения этих рисков, как правило, можно и нужно.

Лет десять назад, когда я впервые начал руководить проектами, меня сильно удивило отношение заказчиков проекта к теме управления рисками.

«Ты какой-то пессимист. Как ты стал руководителем проекта?», – услышал я в ответ на просьбу изучить реестр рисков по проекту от заказчика. Как оказалось позже, по завершению проекта, большая часть описанных рисков «выстрелила», т.к. заказчик не позволил провести для них антирисковые мероприятия и даже заложить резервы времени и денег. И только после анализа усвоенных уроков по проекту он сказал примерно следующее: «Вот теперь я понимаю, зачем заниматься рисками».

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

Т. ДеМарко и Т. Листер в своей книге «Вальсируя с медведями» ввели хороший термин «нанопроцентная дата» (они еще называют ее дата N). Это дата завершения проекта, которая рассчитана без учета имеющихся в проекте рисков, и вероятность завершения проекта именно в эту дату составляет примерно один нанопроцент (десять в минус девятой степени).

Теперь разберемся с тем, что такое риск? Мне больше всего нравится следующее определение: риск – это потенциальная проблема в будущем. То есть эта проблема еще не случилась (ее возникновение имеет некоторую вероятность), но если она случится, то окажет серьезное влияние на проект.

Насколько сильное влияние на проект может оказать слабое управление рисками?

Кейс из книги Д.Канемана «Думай медленно, решай быстро»

«В июле 1997 года строительство нового здания парламента Шотландии в Эдинбурге было предварительно оценено в 40 миллионов фунтов стерлингов. К июню 1999 года бюджет перевалил за 100 миллионов. В апреле 2000 года законодатели установили предел в 195 миллионов, а к ноябрю 2001 года потребовали перерасчета. Была названа последняя цена в 241 миллион фунтов. В 2001 году она дважды менялась, достигнув 294,6 миллиона, а в 2003 году выросла до 375,8 миллиона фунтов. Наконец, в 2004 году строительство было завершено, и, согласно последней смете, затраты составили около 431 миллиона».

Изменение прогноза по бюджету проекта строительства здания парламента в Эдинбурге

Среди причин, по которым затраты на строительство выросли с 40 млн до 431 млн фунтов стерлингов, некоторые аналитики приводят следующие:

• политики недооценили реальную трудоемкость проекта
• менеджер проекта неумело руководил им
• архитекторы меняли планы

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

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

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

Кейс из белорусской практики

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

1. Не существовало ни одного документа, который бы описывал новую бизнес-модель.

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

3. Программный продукт еще не был готов к вводу в промышленную эксплуатацию, а для работы с ним уже были подобраны сотрудники, которые получали зарплату. (Хочу отметить, что бизнес-модель была сильно завязана на программный продукт, и зарабатывать деньги без него было невозможно).

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

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

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

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

1. Детальная проработка бизнес-модели и ее фиксация на бумаге.

2. Сбор и анализ требований к программному продукту, автоматизирующему работу в новой бизнес-модели.

3. Использование одной из существующих методологий управления проектами для планирования и контроля проекта, внесения изменений в ход проекта для реализации всех целей проекта в срок и в рамках бюджета.

4. Проработка критериев отбора поставщика услуг по разработке программного продукта. Выбор поставщика на основании критериев. Выстраивание процессов участия в планировании работ поставщика, контроль его работ.

5. Использование журнала функциональности продукта и подходов к приоритезации требований, чтобы реализовать в первую очередь те требования, без которых продукт нельзя было вводить в промышленную эксплуатацию.

Почему же во многих проектах руководители не работают с рисками?

Топ-4 причин, которые я слышу:

1. Все риски проекта не предусмотришь. Это напрасная трата времени.

2. Лучше тушить пожары, чем искры. Тот, кто борется с пожаром, получает награду. Тот, кто погасил искру, в лучшем случае удостоится одобряющего кивка босса.

3. Плохие мысли притягивают плохие события. Лучше не думать о плохом.

4. Если заниматься поиском рисков, то их можно увидеть столько, что и проект делать не захочется.

Все эти причины соответствуют нашему характеру и ментальности. В этом мы сильно похожи.

Недавно у меня состоялся разговор с профессионалом в области управления рисками, который учился на моем семинаре. Мы говорили о том, какие более сложные методики управления рисками, нежели предложенные в Своде знаний по управлению проектами PMBOK, можно использовать. Знаете, какой был вывод из нашей беседы? Даже тот подход, который предлагает PMBOK, даст значительное повышение точности планирования сроков и бюджета проекта.

Если команда проекта идентифицирует 20-30 рисков и продумает мероприятия по работе с ними – это уже даст более точный план по срокам и бюджету, и позволит руководителю проекта управлять «проактивно», а не заниматься бесконечным «тушением пожаров».

По мнению некоторых профессионалов в области управления проектами, умение работать с рисками – один из главных навыков PM.

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