Анализ рисков бизнеса пример

Аннотация: Качественный анализ рисков. Количественный анализ рисков. Подтверждение содержания проекта.

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

Также при разработке плана учитывается опыт выполнения аналогичных проектов.

Качественный анализ рисков

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

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

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

Рис. 9.1. Отображение миграции риска А в матрице воздействия риска

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

Рис. 9.2. Пример отслеживания временной динамики ранга риска А

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

Количественный анализ рисков

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

Исходной информацией для количественного анализа рисков служат:

• активы организационного процесса;
• описание содержания проекта;
• план управления рисками;
• реестр рисков ;
• план управления проектом .

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

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

Точки принятия решений — это моменты времени, когда происходит выбор альтернатив.

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

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

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

Ожидаемое значение (последствия) — это расположенное в конце ветви количественное выражение каждой альтернативы.

Рис. 9.3. Дерево решений для проектной ситуации, находящейся под воздействием

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

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

Пример использования дерева решения

Таблица 9.1. Сравнение стратегий реагирования на риски Классификация рисков Уклонение от риска Передача риска Принятие риска Снижение последствий вероятности возникновения риска

Риски, связанные с масштабом проекта	Разделение проекта на несколько под-проектов. Сокращение функционального и географического объема проекта	Разделение проекта на несколько под-проектов, выделение пилотного проекта по подсистемам (ограниченного масштаба)	Увеличение трудоемкости работ и стоимости проекта	Детальный анализ каждого этапа работ, взаимодействие участников, организация работ	Детально проработанная программа качества, отработанное управление конфигурацией проекта, специальные процедуры взаимодействия участников
Риски, связанные с недостаточным опытом в сфере ИТ	Реализация только не технологической части проекта, передача технологической части проекта другой компании	Согласование с заказчиком большинства проектных документов, согласование всех изменений в функциональности системы	Увеличение трудоемкости работ и стоимости проекта	Проведение обучения пользователей, включая руководство, соблюдение технологии работы	Разработка и утверждение концепции проекта на возможно более ранней его стадии
Технические риски проекта	Использование более надежных	Документально зафиксированная	Увеличение трудоемко-	Строгий отбор проектной команды по	Использование стандартов пред-
технологических решений	персональная ответственность участников проекта, документальное фиксирование всех изменений в процессе проекта	сти работ и стоимости проекта	квалификационным критериям. Обучение участников проекта технологии проектных работ, инструментальным средствам	приятия для проектных работ, разработка стандартов проекта
Организационные риски проекта	Значительное сужение объема проекта и превращение его в чисто инфраструктурный технологический проект	Включение представителей заказчика в рабочие группы	Увеличение трудоемкости работ и стоимости проекта	Обучение участников проекта(курс «управление проектом»), тренинги команды, как можно более полная формализация деятельности	Включение в команду администратора проекта, детальное распределение ролей в проекте
Операционные риски проекта	Изменение модели оплаты компании-исполнителю: перевод на оплату по результату оценки качества реализованного решения	Акт сдачи заказчику любого документа. Фиксирование отсутствия претензий заказчика по каждому этапу работы	Увеличение трудоемкости работ и стоимости проекта	Многократное тестирование созданных продуктов, тщательная экспертиза документов	Строгое выполнение процедур программы качества

Торговая компания открывает новый магазин, который должен быть укомплектован новейшим оборудованием. Оборудование производят два конкурирующих поставщика (П1 и П2), объявивших одну и ту же дату появления на рынке нового оборудования.

Для увеличения эффективности работы компания планирует осуществить внедрение ИС класса ERP . Разработаны три варианта расписания внедрения информационной системы: вариант 1, вариант 2, вариант 3. Длительность проекта рассматривается как параметр первостепенной важности. Расписание внедрения ИС зависит от поставки и монтажа оборудования. Команда проекта оценила вероятность того, что поставщик 1 (П1) или поставщик 2 (П2) поставит нужное оборудование первым. Анализ информации о прежних разработках поставщиков позволил предположить, что поставщик 1 поставит на рынок новое оборудование с вероятностью 60%; соответственно, для поставщика 2 эта вероятность будет равна 40%.

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

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

1. ожидаемая длительность для случайного узла А: (80 дней* 0,6) + (70 дней *0,4) = 76 дней;
2. ожидаемая длительность для случайного узла Б: (70 дней * 0,6) + (75 дней *0,4) = 72 дня;
3. ожидаемая длительность для случайного узла В: (75 дней * 0,6) + (80 дней *0,4) = 77 дней

Результат дерева решений — вариант расписания с наименьшей продолжительностью, равной 72 дням.

Дерево решений — инструмент, который позволяет наглядно провести анализ проектных решений, содержащих несколько путей решения. Такое определение данного метода дает возможность с полным основанием использовать его для принятий решений о продолжении и ходе развития проекта на шлюзах.

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

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

Существует четыре типовые стратегии реагирования на появление негативных рисков: уклонение, передача, принятие и снижение.

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

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

Подтверждение содержания проекта

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

Входной информацией для процесса являются:

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

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

Источник: intuit.ru

Анализ рисков бизнес плана

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

Риски можно подразделить на четыре основных вида: финансовые, коммерческие, производственные и специфические.

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

5.1.Качественный анализ вероятных рисков

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

Возможные источники возникновения рисков на фирме:

— недостаточная информация о спросе на данный товар/услугу

— недостаточный анализ рынка;

— падение спроса на данный товар/услугу.

Результаты качественного анализа рассматриваемого бизнес-план по оказанию туристических услуг фирмой «Вояж» приведены в таблице № 5.1.

Таблица №5.1. Качественный анализ рисков бизнес-плана по оказанию туристических услуг фирмой «Вояж».

1. недостаточная информация о спросе на данный товар/услугу

Недостаточная информированность о аналогичных услугах оказываемых конкурирующими фирмами

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

2.недостаточный анализ рынка

Недостаточная информированность о ситуации на рынке туристических услуг

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

3. недооценка конкурентов

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

Потеря фирмой своей ниши на рынке. Потеря клиентов.

4.падение спроса на

Некачественный анализ конкурентов, рынка в общем объеме,

недостаток информации о ситуации на рынке.

Падение объема производства.

Снижение прибыли фирмы.

В ходе реализации указанного проекта могут возникнуть ситуа­ции, приходящие к изменениям в хозяйственно-финансовой дея­тельности компании. Среди возможных рисков наиболее существен­ное влияние могут оказать:

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

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

5.2. Количественный анализ рисков проекта

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

Коэффициент эластичности экономического эффекта к фактору риска показывает, на сколько процентов снизится экономический эффект при ухудшении показателя риска на один процент. Коэффициент эластичности эффекта по отношению к i -му фактору риска:

абсолютное снижение экономического эффекта под влиянием изменения 1-го фактора;

-абсолютное значение (рост или снижение) показате­ля i—го фактора риска;

Эб- базисное значение экономического эффекта в бизнес-плаке;

Xбi- базисное значение показателя 1-го фактора в

БЭi- относительные изменения эффекта и показателя i-ro фактора относительно базисного уровня.

БXi- относительные изменения эффекта и показателя i-ro фактора относительно базисного уровня.

Количественный анализ рисков выполняют в такой последователь­ности: 1) оценивают вероятные изменения влияющих и зависимых показа­телей, характеризующих факторы риска в бизнес-плане; 2) рассчитывают значения экономического эффекта (интегрального или сравнительного — в зависимости от того, как это принято в проекте) при изменении каждого показателя риска в отдельности; 3) рассчитывают абсолютное и относи­тельное изменение экономического эффекта; 4) рассчитывают коэффици­ент эластичности эффекта к каждому фактору и по величине этого коэф­фициента назначают ранги значимости рисков;

5) выявляют наиболее зна­чимые риски и по ним прогнозируют пессимистический сценарий; 6) на­мечают меры нейтрализации рисков в случае пессимистического сценария. 11

Количественный анализ рисков проиллюстрируем на приведенном выше примере бизнес-плана по оказанию консалтинговых услуг на примере фирмы «Вояж».

Изменения влияющих показателей, базисные значения зависимых по­казателей риска в бизнес-плане, их вероятные изменения и новые значения при небла­гоприятном стечении обстоятельств приведены в табл.5.2.

Таблица 5.2. Расчет показателей фактора риска в рублях.

Изменение влияющего показателя

Зависимый показатель в бизнес-плане

Источник: studfile.net

Управление рисками в проектах digital-агентства без паранойи: оценка и минимизация

Как подарить конкуренту 70 миллионов пользователей из-за неучтенного риска

4 октября почти на шесть часов отказали WhatsApp, Instagram и Facebook. В Facebook объяснили, что многочасовой сбой произошел из-за изменений конфигураций магистральных маршрутизаторов, которые координируют сетевой трафик между центрами обработки данных.

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

Последствия известны: акции Facebook упали на 4,89%, состояние Цукерберга снизилось на $5,9 млрд, а к конкурентному мессенджеру Telegram на фоне сбоя присоединились 70 миллионов новых пользователей.

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

Риски в digital-агентстве

Управлять рисками важно не только гигантам вроде нынешней Meta — игнорирование рисков в любой компании приводит к негативным последствиям. Основные виды рисков для digital-агентства:

1. срыв сроков
2. снижение качества разработки
3. разлад в команде
4. снижение доверия клиента
5. ухудшение репутации

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

Управлять рисками — это значит при планировании проекта зафиксировать, что может пойти не так, и что с этим делать, если это произойдет.

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

Зачем проводить оценку рисков в организации:

1. Команда будет готова к ситуациям, которые могут снизить качество проекта или задержать его реализацию
2. Команда сможет контролировать риск, устранить, уменьшить или использовать его последствия
3. На этапе продаж агентство может делать более точную оценку проекта, заложив в нее наиболее вероятные риски
4. При составлении календарного плана проджект-менеджер будет знать, где необходимо подстраховаться и заложить дополнительное время

Как можно выявить риски

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

Способы выявления рисков

1. Спросить коллег, у которых были аналогичные проекты. Самый простой способ — проанализировать опыт других проджект-менеджеров, которые уже работали с похожим проектом.
2. Поговорить с заказчиком. Проект — это совместная работа команды и заказчика, поэтому он должен понимать, что риски зависят и от него. Заказчик лучше знает свои бизнес-процессы и заранее может сообщить, что в них может пойти не так. Например, один из наших клиентов предупредил, что из-за большой цепочки лиц, принимающих решения, согласование будет долгим, поэтому в договоре мы заложили 12 дней на согласование этапов, хотя обычно фиксируем меньшее количество времени.
3. Обсудить с командой. Разработчики и дизайнеры заранее могут выявить риск, связанный с их частью работы.
4. Подумать об интеграциях. Интеграция — узкое место любого проекта, которое всегда связано с риском, потому что зависит не только от исполнителя, но и от заказчика. Например, при подключении платежных систем может понадобиться заключить договор. Также заранее нужно получать доступы и требования к серверам.
5. Учесть специфику заказчика (особенно, если это государственные проекты). Например, если команда делает сайт для государственной структуры, то на нем обязательно должна быть версия для слабовидящих.
6. Учесть человеческий фактор. Внутренние моменты в команде несут большие риски: выгорание, конфликты и другие проблемы сотрудников могут навредить проекту.

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

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

Риски в проектах digital-агентства

Приведем примеры рисков, с которыми сталкивались наши проджект-менеджеры:

• Заказчик не готов менять свои бизнес-процессы
• Незаинтересованность контактного лица в проекте
• Смена менеджера со стороны заказчика или с нашей стороны в процессе проекта
• Недостаточная квалификация исполнителей проекта или контактного лица
• Увольнение или болезнь сотрудников
• Ошибки календарного плана
• Изменение требований заказчика в процессе проекта
• Низкая производительность команды
• Творческий кризис у дизайнера
• Несвоевременное предоставление доступов со стороны заказчика (например, к платежной системе)
• Разлад в команде

Анализируем риски по таблице

Один из самых наглядных и удобных инструментов управления рисками проектов — реестр рисков, который составляется отдельно для каждого проекта digital-агентства. Для этого мы создаем таблицу со следующими колонками:

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

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

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

• Степень управляемости — управляемый или неуправляемый, зависит от того, может ли команда своими действиями повлиять на риск
• Что делать с риском — определяем действия на случай, если риск произошел

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

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

Актуализировать риски рекомендуется раз в две недели. Если проект будет длиться полгода, то к третьему месяцу перечень рисков может измениться: какие-то риски станут более вероятны, а какие-то, наоборот, совсем минуют проект.

Еще одна рекомендация — сформировать топ-10 рисков проекта, которые всегда будут в поле зрения проджект-менеджера.

Если риск случился

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

Варианты действий:

• Уклониться. Например, риск — слабый разработчик на проекте. В этом случае можно запросить более сильного разработчика и устранить риск.

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

• Снизить вероятность или силу риска. В одном из наших проектов на макете был разработан слишком сложный дизайн, который бы затянул сроки разработки. Чтобы снизить вероятность этого риска, мы упростили макет.

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

• Эскалация. Подключаем руководство, чтобы противостоять угрозе.

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

• Использовать. Принять меры, чтобы возможность реализовалась.

• Увеличить. Повысить вероятность наступления события или силу его воздействия.

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

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

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

Пример оценки рисков компании

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

Риск № 1: незаинтересованность контактного лица в проекте

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

Источник: внешний, на стороне заказчика

Ответственный: проджект-менеджер, так как он взаимодействует с заказчиком и контактным лицом

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

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

Степень влияния на проект: по матрице рисков умеренная, желтый маркер.

Степень управляемости: управляемый, так как проджект-менеджер может принять меры для улучшения ситуации

• объяснить ответственность и последствия низкой вовлеченности в проект (контактному лицу важно отчитаться перед руководством о проделанной работе)
• эскалировать — сообщить о проблеме руководителю контактного лица, попросить заменить контактное лицо

Риск № 2: творческий кризис у дизайнера

Разберем ситуацию, в которой у дизайнера наступил творческий кризис. Такое случается, например, если заказчик не принимает дизайн-концепцию и дизайнеру не удается попасть в его видение. Он потерян, и не понимает, что делать дальше.

Источник: внутренний, на стороне агентства

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

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

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

Степень влияния на проект: по матрице рисков терпимая, зеленый маркер.

Степень управляемости: управляемый, так как проджект-менеджер может принять меры для улучшения ситуации

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

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

Ссылка на таблицу для использования.

Способы минимизации рисков: 5 советов из нашей практики

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

Держите заказчика в курсе рисков и объясняйте его ответственность

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

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

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

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

Фиксируйте все договоренности текстом

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

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

Оценивайте задачи и закладывайте коэффициент неопределенности

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

Назначайте ответственных и составляйте регламенты

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

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

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

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

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

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

Если пытаться предотвратить все риски, можно стать параноиком

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

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

Подведем итоги

• Введите управление рисками, чтобы повысить эффективность ведения проекта, не срывать сроки и сохранить репутацию агентства, проводите расчет рисков
• Составляйте реестр рисков по каждому проекту
• Проводите анализ рисков в управлении проектами по таблице
• Уделите особое внимание проработке плана действий на случай возникновения угроз и возможностей
• Ведите общий реестр рисков для будущих проектов
• Группируйте риски по степени влияния на проект, риски с оранжевым и красным маркером должны находиться под особым контролем
• Актуализируйте риски проекта каждые две недели и формируйте топ-10 рисков, которые должны быть в поле зрения команды
• Регулярно проводите работу по предотвращению рисков, например, закрепляйте регламенты и разъясняйте заказчику последствия угроз
• Не становитесь параноиком — все риски все равно предотвратить нельзя

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

Источник: atwinta.ru