Риски в управлении IT-проектами

Риски в управлении IT-проектами

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

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

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

Определений рисков великое  множество. Они общеизвестны и интуитивно понятны. Приведем некоторые из них.

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

Риск – некоторое событие или условие, которое может позитивно или негативно повлиять на результат проекта (план, качество, стоимость, объём реализованной функциональности) (Обществознание: учебник для 11 класса)

Выделим несколько категорий  рисков в управлении IT-проектами. Рассмотрим некоторые из них:

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

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

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

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

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

• выявление рисков;
• анализ рисков;
• планирование рисков;
• разрешение конфликтов;
• отслеживание и модификация данных по рискам (Где описание этапа?).

Выявление рисков:

Цель данного этапа  – выявить некоторое количество опасных для проекта рисков. Полагаем, что потенциальных проблем вокруг нас бесконечно много, поэтому задачу нужно ставить количественно. Для начала проекта, можно идентифицировать 50 – 100 рисков, в дальнейшем – по 20-30 штук.

Анализ рисков:

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

Фактически на данном этапе  и происходит управление проектом. Для каждого риска, из списка критичных, необходимо найти стратегию, которая  обезопасит проект от него. Всего стратегий используется три: Transfer (перенесение ответственности за последствия риска на третью сторону), Accept (взятие ответственности за последствия риска на себя), Mitigate (борьба с риском, при которой ответственность за последствия риска на себя).

Отслеживание  и модификация данных по рискам:

Это скорее процесс, чем этап. Его цель – поддерживать список рисков и план проекта в актуальном состоянии.

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

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

Разрешение конфликтов:

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

Таким образом,  на основании изученного материала обобщим этапы управления рисками в IT-проектах и выделим несколько стадий управления рисками:

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

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