Владимир Первушин - Практика управления инновационными проектами

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

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

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

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

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

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

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

• идентификацию рисков;

• оценку рисков;

• разработку реагирования;

• управление реагированием.

Процесс идентификации рисков позволяет определить события риска, которые могут повлиять на проект. Далее следует оценка рисков, в результате которой риски разделяются на две группы: риски, требующие реагирования, и риски, не требующие реагирования. Вторая группа рисков не должна исчезать из поля зрения менеджера: может так случиться, что риски из второй группы перейдут в первую. Третий процесс – разработка реагирования, в результате которого вырабатываются меры по обеспечению противодействия рискам. Эти три процесса относятся к группе процессов планирования, и их использование подробнее рассматривается в гл. 4, п. 4.11.

Процесс «Управление реагированием» осуществляется на стадии управления проектом и включается в тот момент, когда обнаружено наступление соответствующего рискового события.

Управление поставками проекта

Эта система управления отвечает за весь спектр работ с поставщиками и подрядчиками. Можно выделить две группы процессов: первая группа связана с организацией поиска и отбора подрядчиков, включая организацию тендеров, вторая – с управлением контрактами. Стандарт PMI определяет следующие основные процессы этой подсистемы управления:

• планирование закупок и приобретений;

• запрос информации у продавцов;

• выбор продавцов;

• планирование контрактов;

• администрирование контрактов;

• закрытие контрактов.

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

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

В управлении проектами выделяют пять групп процессов управления, которые существуют в любом проекте, т. е. не зависят от предметной области проекта: процессы инициации, планирования, исполнения, анализа и завершения (рис. 2.4). Все процессы управления, входящие в группы процессов, связаны своими входами и выходами, т. е. результат одного процесса является входом для другого.

Рис. 2.4. Взаимосвязи групп процессов управления

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