Проекты+: Важность управления рисками в проектном управлении

ВВЕДЕНИЕ

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

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

Итак, начнем с того, что же есть управления рисками проекта?

ОБ УПРАВЛЕНИИ РИСКАМИ

Понятие «Управление рисками проекта» можно трактовать как действие, принятие мер в отношении рисков, а действия требуют времени и ресурсов.

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

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

СТРУКТУРИРУЕМ ПРОЦЕДУРУ УПРАВЛЕНИЯ РИСКАМИ

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

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

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

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

ОТПРАВНАЯ ТОЧКА

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

Далее становится актуальным вопрос «Как мы будем идентифицировать риски, какие методы мы будем использовать?». Вполне естественна потребность в анализе документации, сборе информации. Не менее важна экспертная оценка, методы отображения с помощью диаграмм или таблиц (Таблица 1)

РИСКИ

ИСПОЛНИТЕЛЬ

ДАТА НАЧАЛА

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

Владимир Е.

01.07.2012

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

Владимир Е.

15.07.2012

Затягивание сроков согласования проектной документации у Заказчика

Владимир Е.

01.08.2012

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

Руслан Ш.

01.06.2012

Сопротивление некоторых сотрудников при внедрении системы

Евгений К.

01.09.2012

Таблица 1

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

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

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

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

РЕЕСТР РИСКОВ – ПОМОЩЬ В ОЦЕНКЕ И БОРЬБЕ С РИСКАМИ

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

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

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

Наимено- вание риска

Причина

Последствия

Как бороться

Плюсы

Минусы

Заниженная оценка проекта

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

Скорее для менеджеров. Процент вероятности продажи проекта увеличивается.

Увеличение сроков проекта - превышение бюджета проекта. Для внедренца это означает - Overtime по проекту.

Повышение культуры оценки работ, более тщательная проверка оценки перед ее публикацией

Отсутствие основных ресурсов

Необходимые ресурсы задействованы на других проектах.

-

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

Заранее планировать ресурсы, увеличение штата сотрудников.

Изменение требований заказчика

Поверхностное, нечеткое описание работ в техническом задании

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

Увеличение объема работ, как следствие – увеличение бюджета проекта.

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

Ошибки внедряемой системы

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

-

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


Недоста- точное тести-рование решений

Отсутствие наиболее компетентного ресурса, максимально сжатые сроки.

-

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

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

Обновление системы

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

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

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

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

Увеличение количества пользова- телей

Пополнение штата компании

Дополни- тельный ресурс

Изменение данных в системе в разрезе пользователей.

Заранее планировать ресурсы, увеличение штата сотрудников.

Увольнение ключевых исполни- телей

Пожелание сотрудника, сокращение штата

Возможность набора более квалифици- рованных и компетентных кадров.

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

Работа с сотрудниками, создание комфортных условий труда

Таблица 2

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

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

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

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

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

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

Рисунок 1.

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

Говоря о целесообразности данного блока «Риски проекта», как об инструменте фиксации и управления рисками, заострю внимание на его преимуществах:

  1. Возможность управлять рисками, обладая полноценной информацией о проекте, актуальность которой всегда поддерживается в едином рабочем пространстве.
  2. Блок «Риски проекта» адаптирован для работы с рисками, поэтому в иных способах ведения реестра потребность автоматически отпадает.
  3. Управление рисками с помощью ведения реестра рисков в ELMA обеспечивает сохранность и безопасность информации, а также абсолютно исключает возможность ее потери.
  4. Данный блок имеет возможность не только фиксировать риски, но также вести полноценную работу с ними, а именно - подробно описывать методологию и способы управления рисками.
  5. Текущий реестр рисков неразрывно связан с проектом, в рамках которого и велась деятельность по управлению рисками.
  6. Командная работа, которая способна дать результаты показателей выше и быстрее по времени.

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

Рисунок 2.

НЕМНОГО ЦИФР

Параллельно с теорией и данными в таблице 2, можно провести динамический анализ рисков. Для примера возьмем риск – увеличение количества пользователей. Последствия риска - внесение изменений в программный продукт работниками IT компании, где ими же ранее было создано пространство определенного технического объема и характера, и было адаптировано под определенное количество пользователей. Если верить практике внедрения программных продуктов, вероятность данного риска составляет 70%.

Обратимся к конкретным цифрам. Был приобретен программный продукт компанией в 1000 человек. Программный продукт был успешно внедрен и адаптирован для 1000 человек. Проделана огромная работа по созданию пользователей, индивидуальной настройке профилей департаментов, отделов, групп пользователей, согласно внутренним регламентам организации, определенным образом настроено делегирование полномочий. И в ходе процесса, что является в принципе нормальной практикой, до группы внедрения программного продукта доходит информация, что в штат принято еще 100 сотрудников и их необходимо завести в систему, настроить им личные кабинеты и выдать им определенные права доступа. И все это необходимо выполнить в максимально короткие сроки (мы помним, что в проектной деятельности, сроки проекта – ключевая составляющая). И как быть в этом случае группе внедренцев, которые абсолютно не были к этому готовы? Неготовность заключается в отсутствии выделенных дополнительных ресурсов в рамках текущего проекта, в жестко установленных сроках проекта, которые в принципе сдвигать не положено, так как они утверждены, ну, и, конечно же, бюджет проекта – как будут оплачены сверхурочные часы работы по данной задаче? Итак, предположительно, рабочий день одного специалиста внедрения программного продукта стоит 6000 рублей. Работы, которые предстоит выполнить рассчитываем в количестве дней на одного человека, это будет 5 рабочих дней. Дальше все очень просто, высчитываем стоимость дополнительных работ 6000 * 5 = 30 000 рублей. Для компании-внедренца программного продукта предполагаемая сумма ущерба будет составлять именно 30 000 рублей – это риск, который, предположим, не был рассчитан.

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

ЗАКЛЮЧЕНИЕ

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

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



#УправлениеПроектами( #Статьи
Cветлана Шутова

Cветлана Шутова

Контент-менеджер

Читайте также

pic

Узнайте, какое решение ELMA оптимально для вашего бизнеса. Запросите звонок консультанта прямо сейчас!

Заказать звонокЗадать вопрос