Согласно РМВоК возможны четыре метода реагирования на риски:

§ Уклонение от риска

§ Передача риска

§ Снижение рисков

§ Принятие риска

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

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

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

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

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

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

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

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

29. Управление человеческими ресурсами

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

Для успешного достижения целей проекта критически важным является следующее:

· идентифицировать состав участников проекта;

· определить роли участников проекта и порядок их взаимодействия;

· сформировать команду проекта и команду управления проектом;

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

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

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

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

Команда управления проектом (КУП) - члены команды проекта, уполномоченные принимать управленческие решения по управлению проектом .

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

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

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

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

· Руководитель проекта;

· Куратор проекта (Спонсор);

· Архитектор системы;

· Администратор проекта.

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

Состав команды управления должен быть достаточным, чтобы осуществлять:

· Управление ресурсами проекта , в том числе:

o определение требуемых для достижения целей проекта ресурсов

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

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

o оценка стоимости проекта, подготовка бюджетов проекта и отчетов об исполнении бюджетов.

· Управление сроками выполнения проекта, в том числе:

o подготовка плана работ проекта;

o контроль над выполнением проекта;

o подготовка отчетов о ходе работ проекта.

· Управление качеством проекта, в том числе:

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

o организация экспертизы проектных решений.

· Управление рисками проекта, в том числе:

o анализ рисков проекта;

o разработка планов мероприятий по снижению рисков;

o реализация мероприятий по снижению рисков.

· Управление проблемами проекта, в том числе:

o анализ проблем проекта;

o разработка мероприятий по разрешению проблем проекта;

o реализация мероприятий по разрешению проблем проекта.

· Контроль над организацией работ в проектных группах , в том числе:

o согласование отчетов о ходе работ;

o контроль над функционированием системы сбора и распределения информации ;

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

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

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

· какие цели стоят перед сотрудником, назначенным на данную роль;

· кому подчиняется сотрудник, назначенный на ту или иную роль;

· каковы его функции, обязанности, полномочия.

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

Разработка плана управления человеческими ресурсами

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

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

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

30. Управление коммуникациями

Управление коммуникациями проекта - управленческая функция, направленная на обеспечение своевременного сбора, генерации, распределения и сохранения необходимой проектной информации.

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

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

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

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

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

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

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

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

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

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

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

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

Выделяются следующие основные процессы:

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

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

Сбор технико-коммерческих предложений – сбор технико-коммерческих предложений и оферт от разных поставщиков.

Выбор поставщиков – выбор поставщика для каждого закупаемого продукта или услуги.

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

Закрытие контрактов – признание контракта завершенным (закрытие), включая решение всех отложенных или неразрешенных вопросов, связанных с данным контрактом/поставщиком.

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

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

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

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

32. Управление безопасностью

Управление безопасностью в проекте (Project Safety Management) – решение основных вопросов, связанных с безопасностью, здоровьем и окружающей средой. В рамках проекта все основные вопросы, связанные с безопасностью, здоровьем и окружающей средой, решаются с помощью использования определенных стандартов и методов, которые позволяют снизить вероятностью нанесения ущерба здоровью людей или различных повреждений оборудования до приемлемого уровня, установленного действующим законодательством или нормативными актами. Управляющий проектом должен обеспечить соблюдение таких стандартов и нормативов при осуществлении проекта. При обоснованной необходимости менеджер проекта может инициировать их пересмотр с целью обеспечения их актуальности и действенности. Процессами и инструментами обеспечения безопасности, сохранения здоровья и защиты окружающей среды являются: o План обеспечения безопасности o Проверка безопасности (специальная сертификация) o Контроль воздействия на окружающую среду.

33. Управление конфликтами

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

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

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

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

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

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

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

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

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

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

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

4. Смириться с конфликтом. Иногда конфликт длится дольше, чей работа над проектом, и хотя он отвлекает от работы, с ним приходится примириться.

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

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

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

34. Системная модель управления проектами

Системная модель управления проектами содержит три основных блока:

1. Объекты управления – системы, проекты, программы, комплексы работ и т.д.:

2. Субъекты управления – активные участники проекта, взаимодействующие в процессе его осуществления;

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

§ Стадии процесса управления , включающие группы процессов :

– инициацию или организацию запуск проекта и его отдельных фаз;

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

– организацию и контроль выполнения работ проекта;

– анализ и регулирование хода работ проекта;

– закрытие работ проекта и его частей.

§ Функции управления , включающие:

– управления предметной областью проекта;

– управление проектом по временным параметрам;

– управление стоимостью и финансами в проекте;

– управление качеством в проекте;

– управление рисками в проекте;

– управление персоналом в проекте;

– управление коммуникациями в проекте;

– управление поставками и контрактами в проекте;

– управление изменениями в проекте;

– прочее.

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

35. Инициация проекта

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

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

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

Кризисные обстоятельства и неопределенность на рынке заставляют участников бизнеса задуматься в очередной раз над эффективным управлением проектами. А всякий проект связан с рисками, что задается по умолчанию определением проекта: проект – это мероприятие временного характера, направленное на создание нового продукта, процесса или услуги. Как управлять рисками? Данная работа дает обзор современных методов реагирования на риски.

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

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

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

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

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

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

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

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

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

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

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

2. Идентификация рисков – определение того, какие риски могут повлиять на проект, и документальное оформление их характеристик. Возникает на стадии планирования проекта, но носит повторяющийся характер, возникая периодически для пополнения реестра рисков проекта по мере его реализации.

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

4. Количественный анализ рисков – количественный анализ потенциального влияния идентифицированных рисков на общие цели проекта.

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

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

Табл. 1. Процесс управления рисками на всех стадиях проекта

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

Успех проекта зависит от того, какую стратегию или стратегии реагирования на риски запланирует и реализует команда управления проектом. Запланированные операции по реагированию на риски должны:

соответствовать серьезности риска;

быть экономически эффективными в решении проблемы;

быть своевременными;

быть реалистичными в контексте проекта;

быть согласованными со всеми участниками.

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

В стандартах управления проектам выделяются:

1. Стратегии реагирования на негативные риски (угрозы);
2. Стратегии реагирования на позитивные риски (благоприятные возможности);
3. Общие стратегии реагирования на риски;
4. Стратегии реагирования на непредвиденные обстоятельства.

Любая стратегия работы с риском направлена на управление либо вероятностью риска, либо последствиями риска, либо одновременно двумя данными параметрами.

1.1 Стратегии реагирования на негативные риски

Уклонение

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

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

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

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

Рис. 2. Стратегия уклонения от риска

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

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

Передача и разделение

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

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

Инструменты передачи рисков включают в себя, в частности:

Страхование;

Гарантии выполнения контракта;

Поручительства и гарантийные обязательства;

Прописывание условий в контракте;

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

Рис. 3. Стратегия передачи риска

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

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

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

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

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

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

Снижение

Стратегия снижения (смягчения) рисков предполагает:

понижение вероятности реализации риска;

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

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

Рис. 4. Стратегия снижения риска

В качестве примеров мероприятий по снижению рисков можно привести:

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

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

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

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

Пример 1: При разработке крупного и сложного технологического пакета команда управления проектом производит серию лабораторных испытаний, а также экспериментов на моделях. Причем производится моделирование как отдельных компонентов, так и укрупненных сборок в различных условиях. Таким образом, уменьшается (но не исключается!) риск того, что окончательный технологический пакет будет работать не так, как это закладывалось в техническом задании. Как результат, вероятность повышения качества исполнения проекта растет, однако это требует привлечения дополнительных ресурсов на резервные испытания и создание дополнительных моделей. Например, компания Alcan при разработке новой технологии провела разработку трех конструкций электролизеров с целью проработки различных технических решений. По итогам испытаний и моделирования была выбрана одна конструкция, на основе которой планируется запуск опытной серии алюминиевого завода в 2010 году.

Пример 2: При создании автомобиля Prius, первого автомобиля-гибрида для коммерческого производства, компания Toyota провела анализ более 80 гибридных двигателей! В конечном счете список был сокращен до 10, а затем до четырех двигателей, которые были протестированы, и был выбран один. Тем самым, был снижен риск разработки двигателя, который не был оптимальным и требовал значительных доработок.

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

1.2 Стратегии реагирования на позитивные риски

Использование

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

Рис. 5. Стратегия использования риска

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

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

Совместное использование

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

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

Усиление

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

1.3 Общие стратегии реагирования на риски

Принятие

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

Эта стратегия используется в случаях, когда:

исключить все риски из проекта маловероятно;

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

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

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

Рис. 7. Стратегия принятия риска

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

1.4 Выбор стратегии реагирования на риски

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

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

Рис. 8. Выбор стратегии риска в зависимости от параметров риска

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

	Меры до рискового события	Меры после рискового события	Когда применяется	Формат реализации (пример)
Негативные риски
Уклонение	+		Последствия риска велики; Вероятность риска велика, и он имеет значительные последствия; Условия реализации риска вне зоны контроля менеджера проекта	· Альтернативный сценарий реализации проекта · Уточнение условий на стадии инициации и планирования с целью уничтожения вероятности рискового события
Передача	+		Есть возможность оценить величину последствий, и есть компании (страховщики), готовые разделить риск или условия по передаче рисков (партнеры согласны на условия контракта)	· Страховой договор · Условия в договоре / контракте
Снижение	+		Возможно выделение ресурсов на дополнительные испытания / модели; Возможно ужесточение спецификаций и требований	· Многократные предварительные испытания или предварительные испытания в меньших масштабах · Ужесточение условий выбора поставщиков и подрядчиков · Ужесточение спецификаций
Позитивные риски
Использование	+	+	Есть возможность привлечения дополнительных ресурсов для увеличения вероятности позитивного риска	· Привлечение дополнительного персонала для уменьшения сроков · Выбор альтернативных путей, позволяющих улучшить качество продукта, снизить издержки проекта
Совместное использование	+	+	Есть возможность привлечения партнеров для улучшения качества продукта проекта	· Создание альянсов, стратегических партнерств и совместных предприятий
Усиление	+	+	Есть причины, приводящие к позитивным рискам	· Выделение работ на усиление причин в плане проекта
Общие стратегии
Принятие		+	Вероятность риска очень низка; Последствия риска очень низкие, дешевле принять риск, нежели разрабатывать меры; Нет путей избегания риска, и/или последствия риска очень велики	· Создание резервов ресурсов

1.5 Стратегии реагирования на непредвиденные обстоятельства

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

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

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

Резюме

1. Каждый проект связан с неопределенностью. Неопределенность рождает риски проекта.
2. Риски бывают как негативными – угрозы проекта, - так и позитивными – возможности проекта.
3. Для повышения качества реализации проекта и увеличения вероятности достижения поставленных целей руководитель проекта вместе с командой проекта управляет рисками, повышает вероятность позитивных рисков и снижает вероятность негативных рисков.
4. Стратегии реагирования на негативные риски: уклонение, уменьшение, разделение/передача.
5. Стратегии реагирования на позитивные риски: использование, совместное использование, усиление.
6. Общая стратегия реагирования на риски - принятие.

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

Принятие

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

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

Перенос

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

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

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

Избежание

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

Смягчение

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

Планирование управления рисками проекта. Идентификация, качественная и количественная оценка рисков. Планирование реагирования на риски, мониторинг и контроль. Факторы внешней среды. Активы организационного процесса. Распределение ролей и ответственности.

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

хорошую работу на сайт">

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

Размещено на http://www.allbest.ru/

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

2. Планирование управления рисками проекта

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

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

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

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

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

Планирование управления рисками - выбор подходов и планирование деятельности по управлению рисками проекта.

Идентификация рисков - определение рисков, способных повлиять на проект, и документирование их характеристик.

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

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

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

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

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

Рисунок 1 - Общая схема управления рисками проекта

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

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

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

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

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

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

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

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

Рисунок 2 - Планирование управления рисками: входы, инструменты и методы, выходы

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

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

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

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

План управления рисками. План управления рисками содержит описания структуры управления рисками проекта и порядок его выполнения в рамках проекта. Этот план включается в состав плана управления проектом. План управления рисками включает в себя следующие элементы:

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

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

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

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

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

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

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

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

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

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

Идентификация рисков предусматривает определение рисков, способных повлиять на проект, и документальное оформление их характеристик. При необходимости в операциях по идентификации рисков могут принимать участие: менеджер проекта, члены команды проекта, команда управления рисками (если таковая создана), эксперты в определенных областях, не входящие в команду проекта, заказчики, конечные пользователи, другие менеджеры проектов, участники проекта и эксперты по вопросам управления рисками. Хотя главная роль в идентификации рисков принадлежит этим специалистам, следует поощрять участие в этом процессе всего персонала.

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

Рисунок 3 - Идентификация рисков

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

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

Допущения проекта приводятся в описании содержания проекта. Неопределенность в допущениях проекта следует рассматривать в качестве потенциального источника возникновения рисков проекта.

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

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

Методы и средства:

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

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

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

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

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

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

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

К методам отображения рисков в виде диаграмм относятся:

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

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

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

4. Качественная и количественная оценка рисков

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

Рисунок 3 - Качественная оценка рисков

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

Вероятность достижения конечной цели проекта;

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

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

Рисунок 4 - Количественная оценка рисков

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

5. Планирование реагирования на риски, мониторинг и контроль

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

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

Рисунок 5 - Планирование реагирования на риски

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

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

Целью мониторинга и контроля является выяснить, было ли:

Система реагирования на риски внедрена в соответствии с планом;

Реагирование достаточно эффективно или необходимы изменения;

Риски изменились по сравнению с предыдущим значением;

Наступление влияния рисков;

Необходимые меры приняты;

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

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

Список использованных источников

1. Дитхелм Герд Управление проектами. СПб, Бизнес-пресса, 2003, Том 1 «Основы», 390 с., Том 2 «Особенности», 274 с.

2. Мазур И.И., Шапиро В.Д. и др. Управление проектами (справочник для профессионалов). М.: «Высшая школа», 2001 - 880 с.

3. Под общей редакцией Шапиро В.Д. Управление проектами. Учебник. СПб.: «Два Три», 1996 - 610 с.

4. Покровский М.А. Основы управления проектами. Учебное пособие. Под ред. Фалько С.Г. М.: Изд-во МГТУ им. Баумана, 1998, 104 с.

5. Руководство к Своду знаний по управлению проектами. Третье издание (Руководство PMBOK)/. Американский национальный стандарт ANSI/PMI 99-001-2004.

6. Управление проектами. Основы профессиональных знаний. Национальные требования к компетенции специалистов. - М.: Изд-во «Консалтинговое Агентство «КУБС Групп - Кооперация, Бизнес-Сервис», 2001.

7. Щедровицкий Г.П. Организация. Руководство. Управление. (Оргуправленческое мышление: идеология, методология, технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4). М.: «Путь», 2000 - 384 с.

8. Щедровицкий Г.П. Организация. Руководство. Управление. (Методология и философия оргуправленческой деятельности. Курс лекций / из архива Г.П. Щедровицкого. Т.5). М., 2003 - 288 с.

Размещено на Allbest.ru

Подобные документы

Понятие и идентификация рисков. Планирование управления рисками на предприятии. Качественная и количественная оценка эффективности бизнеса, мониторинг и контроль. Анализ деятельности гостиничного комплекса "Джемайка". Оценка инвестиционного проекта.

курсовая работа , добавлен 21.05.2015


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

курсовая работа , добавлен 02.06.2010


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

курсовая работа , добавлен 11.03.2014


Действия по анализу рисками как неотъемлемая часть бизнес-процесса на предприятии. Основные факторы риска при реализации проектов строительства объектов сотовой связи. Качественный и количественный анализ рисков. Планирование реагирования на риски.

контрольная работа , добавлен 27.04.2011


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

курсовая работа , добавлен 28.08.2011


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

курс лекций , добавлен 24.02.2011


Основная задача, стоящая перед руководителем, проводящим анализ внешней среды. Определение "критических точек" организационной среды. Классификация рисков по факторам возникновения, характеру учета и последствий. Основные методы управления рисками.

контрольная работа , добавлен 25.05.2015


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

контрольная работа , добавлен 16.02.2016


Планирование в управлении проектами, его основные принципы, подходы и методы. Планирование проекта в рамках стратегии компании. PEST-анализ окружающей среды и SWOT-анализ, порядок их проведения. Анализ эффективности проекта и его ключевые риски.

дипломная работа , добавлен 02.05.2011


Понятие и сущность рисков современного предприятия. Процесс управления рисками. Оценка стабильности и эффективности деятельности предприятия ТОО "Полиолефин-ТЛК". Модели управления рисками. Превентивные меры организации в процессе управления рисками.

Как управлять рисками в проектах. Часть 4. Стратегия реагирования на риск February 19th, 2013

Все посты на эту тему:

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

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

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

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

Оказывается, существует всего четыре варианта реакции на такое событие:

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

Давайте разберемся с каждым из этих вариантов.

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

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

Нужно понимать, что, принимая риск, мы сохраняем его в проекте . Все гадости, которые этому риску сопутствуют, по-прежнему висят над нами и готовы нас порадовать.

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

Не обязательно принимать риск, можно от него уклониться.

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

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

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

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

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

Что делать, если уклониться от риска нельзя? Можно попробовать передать его другому.

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

Как передается риск в проектной области? Скажем, риск изменения сроков проекта? Например, привлечением вендора по модели fixed price. Как только мы заключили с вендором контракт, все риски за проект должен нести он (ха-ха-ха). На самом деле, это красивый модельный пример. Вендором можно прикрыться, если дойдет до разборок на высшем уровне (генеральный директор РусГидро с этим утверждением не согласится), но с точки зрения рисков сдвига сроков и ухудшения качества, привлечение вендора, скорее, несет в себе дополнительные риски (генеральный директор РусГидро может это легко подтвердить).

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

Что делать, если ни одна из трех описанных выше стратегий к риску не применима? Остается последний вариант - снизить влияние риска.

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

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

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

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

Вы-то, наверное, думаете, что скоро конец? А до конца еще далеко. Как сказал один великий поэт,

The woods are lovely, dark, and deep,
But I have promises to keep,
And miles to go before I sleep,
And miles to go before I sleep.

(продолжение следует)