Управление ИТ-проектом.
Эффективная система «с нуля» в любой организации

Селиховкин Иван
Санкт-Петербург – 2010

Назад Содержание Вперёд

Глава X. Планируем и работаем с рисками

Входы:

• ИСР и ИСР-словарь
• Расписание
• Оценки предельной цены проекта
• Список ресурсов проекта

Что такое риски проекта?

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

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

Риск – это вероятностное событие, которое может оказать положительное или отрицательное влияние на проект.

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

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

Работу с рисками можно представить в виде набора последовательных процессов (шагов).

Шаг 1. Планирование управления рисками

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

Поэтому, подходы мы выработаем самостоятельно.

Шаг 2. Идентификация рисков

Кто выявляет риски?

Идентификация рисков отчасти схожа с процессом сбора требований (описанном в главе VI). Нам понадобится приложить массу усилий (а, порой, и фантазии), чтобы выявить и описать в формате таблицы все разнообразие «неопределенных» событий проекта.

Распространенный подход гласит- «к идентификации рисков привлекаются все».

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

Источники информации о рисках

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

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

Какая информация о рисках важна?

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

Как уже было сказано – информацию о рисках удобно хранить в формате таблицы. Назовем ее «реестр рисков». Один из возможных форматов документа представлен в Приложении 5.

Данную таблицу мы будем заполнять в течение управления рисками (вплоть до закрытия проекта).

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

Хозяин риска – персона, которой ПМ поручит обрабатывать риск (контролировать, что превентивные меры предприняты, а в случае наступления риска – реагировать на него).

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

На данном шаге «хозяин риска» может и не определиться. Самое главное – «накидать» максимально полный список самих рисков (и не забывать дополнять его в дальнейшем, возвращаясь к нему в ходе всего проекта).

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

Шаг 3. Качественный анализ

Риски собраны и внесены в реестр. Время приступить к их оценке и сортировке.

Качественный анализ – это субъективная оценка выявленных рисков. Мы должны определить – как сильно тот или иной риск угрожает проекту.

Один из самых широко распространенных способов – оценить каждый риск по двум параметрам «вероятность» и «влияние», задав для каждого значение из диапазона «высокое»/ «среднее» / «низкое».

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

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

Так, пожар в головном офисе нашей компании или внезапное увольнение спонсора может оказать сильнейшее влияние на проект, но вероятность таких событий по нашим оценкам – низка. Уровень риска «желтый». Пренебрегаем.

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

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

Шаг 4. Количественный анализ

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

Следует сразу оговориться – количественный анализ нужен не для всех рисков (а только для тех, уровень которых мы признали значимым).

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

Среди методов количественного анализа выделяют:

• Сбор экспертных мнений
• Анализ Монте-Карло (мы коротко говорили о нем в разделе, посвященном формированию расписания – глава VIII шаг 6)
• Оценку стоимости риска (оценивается как произведение количественной оценки вероятности риска на его влияние).

Остановимся подробнее на последнем методе.

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

Например, вы можете потратить 1500 долларов на лицензионный софт, и эту трату придется понести с вероятностью 100%. Или использовать «пиратское ПО» бесплатно, однако тогда с вероятностью 5% вас поймают и выпишут штраф на 100.000 долларов. Что предпочесть?

Сравниваем стоимость риска по каждому из сценариев:

Для сценария 1 = 1500 * 1 = 1500 долларов

Для сценария 2 = 100.000 * 0,05 = 5000 долларов.

Вывод – сценарий 1 выгоднее для проекта (т.к. его стоимость риска ниже).

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

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

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

Шаг 5. Планирование реагирования на риск

Определив самые значимые из выявленных на данный момент рисков, мы приступаем к построению планов. Наша задача – для каждого риска постараться найти ответы на два вопроса:

1. «Как изменить уровень риска на проекте (увеличить / уменьшить)?»
2. «Что делать, если мероприятия пункта 1 окажутся неэффективными, и риск все-таки произойдет?»

Содержимое пункта 1 будем называть «Планом А» (общепринятые названия – «план реагирования на непредвиденные ситуации» или contingency plan).

Содержимое пункта 2 назовем «Планом Б» (в методологиях он часто называется «планом отступления» или fallback plan).

Создаем «План А» (contingency plan)

Главный элемент «Плана А» для каждого риска – это стратегия. Выделяют четыре вида стратегии для положительных и отрицательных рисков:

Отрицательный риск	Положительный риск
Нивелирование	Использование
Ослабление	Усиление
Перенос	Разделение
Принятие

Стратегия «Нивелирование» / «Использование» устраняет корневую причину риска (или наоборот, гарантирует ее сохранение). Это самый лучший вид стратегии, если он приемлем по цене и прочим параметрам – стремитесь использовать именно его.

Пример для негативного риска: неопытный член команды может завалить работу. План А – заменить сотрудника на более опытного.

Пример для позитивного риска: закупаемое для проекта лицензионное ПО, может достаться нам со скидкой, если все закупки будут проведены до конца года. План А – провести закупки ПО до конца года.

Стратегия «Ослабление» / «Усиление» нацелена на изменение вероятности или влияния рисков.

Пример для негативного риска: неопытный член команды может завалить работу. План А – заранее провести тренинг для сотрудника.

Пример позитивного риска: закупаемое для проекта лицензионное ПО может достаться нам со скидкой, если все закупки будут проведены до конца года. План А – уведомить о возможных рисках заинтересованных и ответственных за закупки лиц.

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

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

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

Стратегия «Принятие» предполагает бездействие, «смирение» с обстоятельствами. Это наиболее пассивная из всех стратегий. Она может быть использована для неснижаемых рисков, предотвратить которые дороже, чем дождаться их наступления. Остерегайтесь применения такой стратегии, следите, чтобы такой тип реагирования применялся не более чем для 10% рисков на любом проекте, а по возможности – стремился к нулю.

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

Зафиксируйте выбранную стратегию в реестре – опишите ее вид и действия «Плана А». Определение вида стратегии очень важно для самоконтроля. Классифицируя намеченный «план действий» – проверьте себя. Зная, что наилучшим сценарием будет нивелирование / использование риска, а худшим – принятие, убедитесь, что выбран был действительно наилучший способ реагирования из доступных.

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

Общее правило – хозяином становится тот, кто находится «на передовой» (т.к. именно он будет проверять, что определенные действия в рамках Плана А выполнены).

В работе «хозяина» крайне важны правильно определенные «триггеры риска».

Триггеры риска – признаки, по которым «хозяин риска» поймет, что превентивные действия не сработали и пора «отступать» (использовать План Б). Это еще один резон не становиться хозяином всех рисков – пусть хозяином будет тот, кто первым заметит триггер.

Создаем «План Б» (fallback plan)

План Б будет использоваться «хозяевами рисков», если План А окажется недостаточно эффективен.

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

Заполняя данный раздел реестра, используйте эффективный прием: задавайтесь вопросом не «что делать, если…», а «что делать, КОГДА риск произойдет». Таким образом, можно сделать гипотетическую картинку на много ярче и реалистичнее.

Шаг 6. Изменяем планы и определяем резервы

Прорабатывая планы

Оба плана (в особенности «План А») в зависимости от выбранной стратегии – предполагают какие-то действия с нашей стороны.

Иногда, можно ограничиться внесением изменений в планы: корректировка расписания или состава работ сама по себе, порой, способна понизить уровень риска, скажем, с «красного» на «зеленый».

В других случаях потребуются определенные ресурсы – для найма сотрудников или проведения тренингов, для привлечения субподрядчиков и так далее. Для их обозначения обычно используется термин «резервы на непредвиденные случаи» (contingency reserves).

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

«Резервам на непредвиденные случаи» иногда противопоставляют «управленческие резервы» (они целиком планируются и распределяются спонсором проекта и ПМ не известны).

Обратите внимание – резервы не удорожают проект! Сумейте, при необходимости, донести до своего руководства.

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

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

И еще один совет – сформировав план управления рисками ,просмотрите его еще раз. Подумайте, не породили ли ваши запланированные действия в рамках «резервов на непредвиденные случаи» – дополнительных рисков (их принято называть вторичными). Если да – внесите их в реестр (как идентифицированные) и повторите процедуру. Чем полнее окажется реестр рисков, тем лучше для проекта.

Выходы:

• Реестр рисков
• Запросы на изменения

Назад Содержание Вперёд