Что такое резерв менеджера проекта pmr

02.07.2011 Практические инструменты управления рисками проекта

Автор: Виктор Степанов

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

Когда один из вас падает, он падает за тех, кто идет позади, предупреждая о камне преткновения. Он падает и за тех, кто идет впереди; за тех, которые, хотя и шагают быстрее и увереннее, но не убрали камень.

Тема управления рисками всегда была и остается самой «вкусной» в проектном менеджменте. Это объяснимо: каждый руководитель проекта хотел бы безопасно провести корабль проекта между мелями и рифами проектных рисков. Однако реакция на публикации на тему управления проектными рисками бывает двоякой. Прочитав одни статьи, проект-менеджеры восклицают: «Ну, это банально! Мы и так занимаемся этим каждый день (а толку мало)!». Прочитав другие (более обстоятельные) материалы, те же руководители проектов жалуются на сложность методичного подхода к риск-менеджменту и неприменимость его в небольших проектах.

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

Из истории вопроса

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

С тех пор PMBoK обновлялся каждые четыре года, и к 2004 году список процессов был дополнен стартовым процессом «планированием управления рисками». Оценка риска была разбита на два процесса: качественный и количественный анализ риска.

Редакция 2004 года существенно продвинула методологию управления проектными рисками. Соответствующий раздел PMBoK’а был дополнен доступными методическими примерами и диаграммами, а также хорошим «арсеналом». Проект-менеджерам стали доступны такие инструменты, как план управления рисками, иерархическая структура рисков (ИСРс), матрица вероятности и последствий, мозговой штурм, метод Делфи, идентификация основной причины, SWOT-анализ, анализ допущений, диаграммы влияния и причинно-следственных связей, реестр рисков и другие. То, что раньше скромно именовалось «мерами реагирования на риск», отныне стало «стратегиями реагирования на риски», классификацию которых полезно знать «назубок»: уклонение, передача, снижение (для реагирования на угрозы); использование, совместное использование, усиление (для реагирования на благоприятные возможности); принятие (общая для угроз и возможностей стратегия), а также механизм реагирования на непредвиденные обстоятельства (план «Б»).

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

А где возьмешь?! или Откуда берутся риски в проектах

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

На этапе идентификации рисков полезно вернуться к понятию окружения проекта (статья Виктора Степанова «Проектный кастинг. Распределяем роли». Журнал «Финансовый директор» № 01/2009). Мы выделяли людей и факторы, способствующие или мешающие достижению целей проекта. Это и есть основные источники рисков. А значит, необходимо подумать, какие риски исходят от заказчика или спонсора проекта, от команды проекта, поставщиков, лицензоров, научно-технического прогресса, экологии и так далее (см. Рис. 1).

Рисунок 1. Пример иерархической структуры рисков по источникам возникновения

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

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

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

Метрика риска = Влияние риска х Вероятность риска

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

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

Таблица 1. Таблица качественной оценки рисков проекта

Источник

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

Создание резервов на случай непредвиденных обстоятельств

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

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

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

На практике непредвиденные обстоятельства составляют от 1 до 10% в проектах, аналогичных предыдущим.

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

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

Резервы управления выделяют на риски, связанные с проектом в целом.

Сметные резервы

Эти резервы выделяются на конкретные пакеты работ или сегменты проекта, выбранные из основной сметы и структуры распределения работы по этапам.

Сметные резервы используются для выявленных рисков с малой вероятностью возникновения.

Примерами таких рисков, покрывающихся за счёт сметных резервов, являются небольшие изменения в дизайне и ошибки в расчетах времени и затрат.

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

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

Если риска удается избежать, фонды возвращаются в резерв управления.

Резервы управления

Эти резервные фонды необходимы для покрытия крупных непредвиденных и потенциальных рисков и поэтому применяются к проекту в целом.

Резервы управления организуют после того, как организованы сметные резервы и выделены фонды.

Они не зависят от сметных резервов и контролируются управляющим проектом и «владельцем» проекта.

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

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

Поэтому технические резервы находятся внутри резервов управления и контролируются «владельцем» или верхним эшелоном управления.

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

В табл. 5.3 показаны расчеты для фонда непредвиденных обстоятельств, сделанные для гипотетического проекта.

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

Таблица 5.3. Расчет фонда непредвиденных обстоятельств (тыс. долл.)

Наименование операции	Основная смета	Сметный резерв	Проектная смета
Дизайн	500	15	515
Код	900	80	980
Испытание	20	2	22
Всего	1420	97	1517
Резерв управления	—	—	50
Итого	1420	97	1567

Ответственность за проектные риски

Одним из основных способов контролировать затраты на риски является письменное подтверждение ответственности за них.

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

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

В табл. 5.4 указаны самые распространенные категории рисков, типичные для проекта владелец/подрядчик; существуют также специфические проектные риски, но они не включены в эту таблицу.

Разделение ответственности может являться лучшим способом снизить риск.

Изменение методов управления контролем

Справиться с изменениями в проекте и проконтролировать их оказывается трудной задачей для большинства управляющих проектом.

Большинство изменений можно разделить на три категории:

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

На практике большинство систем контроля над изменениями призваны выполнять следующие функции;

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

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

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

Одним из ключевых моментов успеха в процессе контроля над внесением изменений является составление официального документа.

Система контроля над внесением изменений дает следующие преимущества:

Контроль над проектом во многом зависит от непрерывности процесса контроля над изменениями.

Выводы

Все управленцы понимают, что риски являются неотъемлемой частью проекта.

Ответственность за риски должна быть четко определена и документально оформлена.

Сметные резервы связаны с распределением работы по этапам и информация должна быть доведена до сведения проектной команды.

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

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

Источник

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

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

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

РИСКИ ПРОЕКТА НА ЭТАПАХ ЖИЗНЕННОГО ЦИКЛА

Жизненный цикл проекта по внедрению программ 1С состоит из нескольких этапов, на каждом из которых присутствуют свои риски. Также существуют общие риски всего проекта.

К общим проектным рискам обычно относятся:

риски в виде отсутствия поддержки со стороны руководства заказчика;

отсутствие четкого разделения ответственности между проектными командами заказчика и исполнителя, а также внутри самой проектной команды;

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

отсутствие соответствующей компетенции у персонала;

предоставление неполноценной или несогласованной информации;

недоступность технической информации для исполнителя и прочее.

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

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

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

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

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

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

РИСК-МЕНЕДЖМЕНТ ПРОЕКТА

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

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

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

Управление рисками проекта можно разделить на 3 части:

Идентификация, анализ и оценка рисков проекта

Определение мероприятий по управлению рисками

Контроль и мониторинг рисков проекта

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

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

Перед стартом проекта проводится работа по идентификации возможных и существующих рисков. Процесс идентификации представляет собой поиск всех возможных рисков, по итогам которого мы должны найти ответы на вопрос: «Что может пойти не так?» (для негативных рисков). Но при поиске ответов на вопрос: «Что может пойти не по плану?» можно найти и позитивные риски.

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

Оценка рисков проекта и идентификация проводится для составления плана реагирования на риски. Оптимально управлять одновременно не более 10 рисками.

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

Такое ограничение говорит о том, что, как и у треугольника, нельзя изменить одну сторону, не задев как минимум ещё одну. Изменение одного параметра управления проектом влияет и на другие параметры.

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

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

Исходя из логики определения риска проектов можно выделить следующее:

Риск имеет как негативную, так и позитивную сторону. Дело в том, что при переводе с английского слово «риск» имеет значение «шанс».

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

Риск влияет на проект. То есть если какое-то событие (например, засуха на другом материке) не влияет на цели и параметры проекта, то это не является риском.

Любой риск имеет два обязательных параметра: влияние и вероятность возникновения.

При расчетах величины риска значения влияния и вероятности возникновения определяются по шкале от 0 до 1:

0 – известно, что событие определенно не произойдет

1 – известно, что событие определенно произойдет.

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

В процессе расчета величин риска определяются стратегии ликвидации рисков. При этом можно использовать следующие мероприятия по реагированию на риски:

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

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

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

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

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

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

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

Источник