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

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

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

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

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

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

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

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

Например, заказ на стороне разработки рискованного компонента по фиксированной цене. В 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. Инициация проекта

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

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

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

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

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

Мониторинг и контроль

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

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

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

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

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

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

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

Очень важно! Риск – это не плохо и не хорошо! Риск – это неопределенность . Вероятность и Риск — это синонимы. Соответственно, как следует из определения, каждый риск можно оценить.

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

Угрозы — негативное воздействие на результат
Возможности — положительное воздействие на результат

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

Основные источники рисков ИТ проекта

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

Заинтересованные стороны, их требования и ожидания — заказчик может отказаться принимать работу т.к. система не решает задачи, для которых создана, заказчик сам не знает чего хочет, два ключевых пользователя озвучивают прямо противоречащие друг другу требования, заказчик уверен, что РМ или BA догадаются о чём он думает…

Технические источники рисков — применяемые технологии, ускорение проекта за счёт отказа от полноценного проектирования, «технический долг», производительность…

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

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

Процессы управления рисками проекта согласно PMBoK

Управление рисками включает в себя следующие задачи:

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

Реагирование на риски ИТ проекта

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

Уклонение от риска
Передача риска
Снижение рисков
Принятие риска

Частый пример такого подхода в ИТ проектах, даже fixed price — ереложить риск на заказчика. Это можно сделать в несколько способов:

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

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

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

План управления проектом (обновления) . Обновление плана управления проектом происходит за счет добавления операций реагирования на риски в процессе общего управления изменениями проекта.

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

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

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

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

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

количество "открытых" (найденных и неисправленных) ошибок на один модуль или компонент;

среднее за неделю количество сверхурочных часов работы на одного сотрудника;

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

изменения бизнес-процессов Заказчика;

своевременность выделения требуемых ресурсов ;

техническое обеспечение работ.

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

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

Таблица 7.8. Пример формы для мониторинга рисков
Тип риска	Описание риска	Проактивные мероприятия	Реактивные мероприятия	Пороговые состояния	Вероятность	Влияние	Фактор риска
Политический	Заказчик решил не внедрять систему	Плана нивелирования риска не существует. Заказчик решает либо внедрять систему, либо не внедрять	Если Заказчик не представляет стратегической ценности для OXS, не начинать проект
Политический	Ввиду того, что выбор системы (и подрядчика) проводился холдинговым руководством Заказчика, сам Заказчик на текущий момент не заинтересован в проекте и внедрении системы	Проведение ряда заблаговременных семинаров, повышающих уровень заинтересованности Заказчика во внедрении системы Организация референс-визитов к успешным клиентам Определение реальных лидеров в организации, Точечное повышение уровня их заинтересованности в успешном внедрении

Как управлять рисками в проектах. Часть 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.

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

Стратегии реагирования на негативные риски (угрозы). Реагирование на риски проекта