Андрей Пушников —
руководитель проектов,
консалтинговая группа «Борлас»

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

Дровосек с тупым топором

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

Чтобы реально управлять рисками в проекте, необходимо преодолеть внутренние и внешние сложности. С одной стороны, это внутренняя корпоративная культура исполнителя проекта (консалтинговой компании), частью которой является управление рисками. Менеджера проекта нельзя заставить управлять рисками. Если попытаться это сделать, он будет добросовестно заполнять нужные формы и шаблоны, то есть выполнять работу, не имеющую к управлению рисками никакого отношения. Простым критерием для проверки может служить вопрос: есть ли у менеджера проекта бюджет на риски? Корпоративную культуру управления рисками можно только вырастить, создавая для этого условия и проводя соответствующее обучение.

С другой стороны, проект ведется у заказчика, который попросту может быть не готов к управлению рисками («У нас это не принято...»; «Если мы скажем правду, то проект будет закрыт...»; «Нам приказали завершить этот проект к 1 апреля — мы так и сделаем...»). Причём то, что с точки зрения исполнителя является риском, заказчик может рассматривать как благоприятную возможность. И наоборот.

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

Наиболее важные риски

Из опыта ведения проектов по внедрению ERP-систем могу особо выделить следующие риски.

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

Лучший способ предотвращения этого риска — следовать принципу «нет спонсора — нет старта проекта». Трудность в том, что выясняется это, как правило, уже после того, как проект начался.

Риск 2: несоответствие типа контракта и типа проекта. Есть два крайних варианта — контракты типа Time&Material и контракты FixPrice. Первый вариант все риски переносит на заказчика, второй — на исполнителя. И в том и в другом случае какая-то одна сторона оказывается в проигрыше.

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

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

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

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

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

Риск 4: недостаточное вовлечение персонала заказчика в проектную команду. Это также в большей степени риск исполнителя. В крупном проекте по внедрению ERP-системы на одного человека от консалтинговой компании приходится от трёх до семи собственных специалистов заказчика (количество зависит от масштаба проекта). Это происходит не только потому, что стоимость консультантов высока. В ходе проекта необходимо передать знания специалистам заказчика, чтобы они в дальнейшем могли поддерживать и развивать внедряемую систему.

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

Риск 5: недостатки календарного планирования. Для внедрения крупных информационных систем разработано большое количество методологий. Таким образом, создается ощущение, что пользуясь проверенными методологиями, можно разработать детальный план, включающий все задачи проекта, и точно оценить его трудоемкость и длительность. В реальности дело обстоит совершенно иначе.
В проектах по внедрению информационных систем в принципе невозможно заранее запланировать все задачи. Что-нибудь обязательно пойдет не так. Менеджеры проектов часто либо смотрят на ситуацию слишком оптимистично, либо находятся под сильным давлением со стороны заказчика. Заказчик же просто не понимает таких слов, как резерв на риски, оптимистичный или пессимистичный план. Если менеджер проекта в качестве оценки срока достижения результата называет диапазон времени, то заказчик воспринимает только нижнюю границу данного диапазона, и этот срок становится директивной датой. Как правило, это приводит к постоянному смещению обещанных, но не реалистичных сроков.

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

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