CC BY
183
Николаенко В.С.
Превентивный риск-менеджмент в ИТ-проектах
Николаенко Валентин Сергеевич — ассистент, Томский политехнический университет; аспирант, Томский государственный университет, Томск, РФ. E-mail: nikolaenkovs@tpu. ru SPIN-код РИНЦ: 9301-1835
Аннотация
В статье представлено методическое обеспечение по управлению ИТ-проектами, используя которое, менеджеры ИТ-проектов, руководители ИТ-организаций и другие ИТ-специалисты смогут превентивно нивелировать и / или ослабить типичные и часто встречаемые риски. Разработанное методическое обеспечение базируется на результатах анализа основных моделей жизненных циклов, используемых для разработки ИТ-проектов, на анализе типичных и часто встречаемых рисковых событий в ИТ-проектах, а также на результатах, полученных в ходе исследования методического обеспечения, применяемого для управления ИТ-проектами.
Ключевые слова
Риск, управление рисками, риск-менеджмент, ИТ-проект.
Информационные технологии оказывают значительное влияние на развитие организаций. Так, в аналитических докладах агентства CNews Analytics приводятся данные, в которых говорится, что ежегодно все больше бизнес-процессов организаций становятся зависимыми от проектов, реализующихся в сфере информационных технологий1. Данную тенденцию подтверждает динамика развития рынка информационных технологий (ИТ) в России (Рисунок 1).
млрд. руб.
2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 год
2
Рисунок 1. Объем ИТ-рынка в России за 2002-2013 гг., млрд руб.
Эксперты McKinsey & Company условно классифицируют составляющие рынка ИТ на следующие группы: ИТ-оборудование, ИТ-сервисы, программное
1 CNews Analytics [Сайт]. URL: http://www.cnews.ru/ (дата обращения: 16.03.2016).
обеспечение (ПО). Доля ИТ-оборудования составляет 60%, ИТ-сервисов — 20%, ПО — 20%. Объем рынка информационных технологий (ИТ) в России составляет примерно 1,3% от ВВП. Для сравнения: в Индии, Бразилии и Китае этот же показатель — 2%, а в США, Великобритании и Гонконге — 4%2.
Специалисты McKinsey & Company также выявили актуальную проблему, связанную с безрисковым управлением в ИТ-проектах, а именно необходимость такого методического обеспечения для управления ИТ-проектами, при котором фактические результаты максимально сходились бы с запланированными (факт = план). Подобное безрисковое управление позволит значительно увеличить долю успешных ИТ-проектов.
В этой связи целью статьи является разработка методического обеспечения для управления ИТ-проектами, которая даст возможность превентивно нивелировать и / или ослабить типичные и часто встречаемые риски.
Для достижения поставленной цели автором статьи были решены следующие задачи:
1) проведен анализ методического обеспечения, который используется для управления ИТ-проектами;
2) изучены основные модели жизненных циклов, применяемые для реализации ИТ-проектов;
3) идентифицированы типичные и часто встречаемые риски в ИТ-проектах;
4) разработано методическое обеспечение по нивелированию и / или ослаблению типичных и часто встречаемых рисков в ИТ-проектах.
Согласно «Стандарту управления проектами» (Project Management Body of Knowledge, PMBoK), «проект» — это временный процесс, направленный на создание уникальных продуктов, услуг и / или результатов3. Временный характер процесса создания означает, что проект имеет фиксированную длительность, ограниченный бюджет и ресурсы. Проект считается завершенным, если достигнуты его цели (то есть разработано содержание, соблюдены запланированные сроки, стоимость и качество)4. В отличие от текущей (процессной, операционной) деятельности, проектная деятельность по причине уникального характера создания продуктов сталкивается с
2 McKinsey & Company [Official Site]. URL: http://www.mckinsey.com/ (accessed: 16.03.2016).
3 A Guide to the Project Management Body of Knowledge (PMBoK Guide). 4th edition / Project Management Institute (PMI), 2008.
4 Гага В.А., Николаенко В.С. Создание системы управления проектами в организации с применением эвристических методов // Вестник Томского государственного университета. 2013. № 374. С. 137-140.
неопределенностью, то есть набором непрогнозируемых ситуаций5. Так, проектные задачи могут быть новыми для проектной команды, что обусловливает необходимость более тщательного планирования.
Принято считать, что по завершении проекта может быть получен:
• продукт, например конечное изделие либо элемент изделия;
• услуга;
• результат, например будущее возможное последствие или документ. Вероятность наступления рискового события сказывается на взаимосвязанных
ключевых параметрах проекта: срок, стоимость и качество (Рисунок 2). Например, увеличение качества итогового продукта проекта приведет к увеличению стоимости и срока реализации6.
Рисунок 2. Основные параметры проекта
Под ИТ-проектом в данной статье будем понимать процесс, направленный на создание уникальных продуктов, услуг и / или результатов, связанных с оценкой, модернизаций, адаптацией, кастомизацией, настройкой, внедрением, тестированием, описанием и интеграцией информационных систем в определенные бизнес-процессы организаций.
Как правило, в ИТ-проектах выделяют пять групп лиц, заинтересованных в его успешном завершении (stakeholders): пользователь, заказчик, менеджер проекта, проектная команда, субподрядчики (Рисунок 3).
5 Хэлдман К. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.
6 Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. М.: Лори, 2012.
Проектная команда
Заказчик Пользователь Менеджер
проекта
Субподрядчик
Рисунок 3. Лица, заинтересованные в успешном завершении ИТ-проекта
Пользователь — это лицо либо организация, которая использует продукт, услугу и / или результат ИТ-проекта для выполнения каких-либо функций7.
Заказчик проекта — лицо либо организация, которая инициирует проект, формирует заказ на создание продукта, услуги и / или результата, обеспечивает финансирование проекта и получает основной продукт ИТ-проекта8. Заказчиком может выступать как стороннее лицо либо организация, тогда ИТ-проект называется «внешним», так и непосредственно организация, которой необходим продукт ИТ-проекта — данный проект принято называть «внутренним».
Менеджер проекта — лицо, осуществляющее управленческие функции, то есть лицо, ответственное за содержание ИТ-проекта, его стоимость, время, качество, персонал, коммуникации и интеграцию9.
Проектная команда — лица, которые являются непосредственными исполнителями по выполнению работ ИТ-проекта.
Субподрядчик проекта — лицо либо организация, работающая по субподряду, то есть полностью или частично выполняющая работы ИТ-проекта по контракту.
Методические обеспечения, используемые для управления ИТ-проектами
Отличительной особенностью ИТ-проектов от других является возможность запуска инкрементов продукта проекта (часть программного кода) в бизнес-процессы заказчика до того, как проект будет полностью завершен. Это означает, что
7 Ching Gu V., Hoffman J.J., Cao Q., Schniederjans M.J. The Effects of Organizational Culture and Environmental Pressures on IT-project Performance: A Moderation Perspective // International Journal of Project Management. 2014. No 32. P. 1170-1181.
8 LaceyM. The Scrum Field Guide: Practical Advice for Your First Year. Indianapolis, Ind.: Addison-Wesley, 2013.
9 Merna T., Al-Thani F. Corporate Risk Management. New York: John Wiley & Sons, Ltd, 2008.
пользователь получает возможность на ранних этапах использовать функционал еще не завершенного продукта и осуществлять тестовые бизнес-операции.
Для управления проектами в сфере информационных технологий применяют различное методическое обеспечение. Примеры методических обеспечений, используемых для управления ИТ-проектами, представлены в Таблице 110.
Таблица 1. Примеры методических обеспечений, используемых для управления
ИТ-проектами
Название методического обеспечения (оригинал) Название методического обеспечения (перевод на русский язык) Разработчик
Project Management Body of Knowledge (PMBoK) Стандарт управления проектом Project Management Institute (PMI)
Capability Maturity Model Integration (CMMI framework) Модель зрелости Software Engineering Institute (SEI)
Rational Unified Process (RUP) Компания Rational Software
Project in Controlled Environments (PRINCE2) Стандарт по руководству проектами в сфере информационных технологий (Великобритания) Central Computer and Telecommunications Agency (CCTA)
System Development Life Cycle (SDLC) Жизненный цикл разработки систем
Microsoft Solution Framework (MSF) Корпорация Microsoft
Extreme Programming (XP) Экстремальное программирование Кент Бек, Уорд Каннингем, Мартин Фаулер и др.
Rapid Application Development (RAD) Быстрая разработка приложений Джеймс Мартин (IBM)
Scrum Скрам Хироката Такэути и Икудзиро Нонака
Agile Adaptive Software Development (ADS) Адаптивная разработка программного обеспечения Джим Хайсмит и Сэм Байер
Crystal Clear Элистер Кокбёрн
Feature-Drive Development (FDD) Разработка, управляемая функциональностью Джеффер Де Люк
Dynamic System Development Method (DSDM) Метод разработки динамических систем Консорциум DSDM
Kanban Lean Development Канбан Дэвид Дж. Андерсон (Корпорация Toyota)
Structured System Analysis and Design Methodology (SSADM) Методология по анализу и дизайну структурированных Central Computer and Telecommunications Agency
систем
SixSigma Шесть сигм Корпорация Motorola
В работе К. Брандаса, О. Дидраги и Н. Бибу проводится сравнительный анализ существующих подходов и методов, используемых для управления ИТ-проектами11.
10 Николаенко В.С. Анализ инструментария по обеспечению функции управления рисками в ИТ-проектах // Государственное управление. Электронный вестник. 2015. № 49. С. 105-120. URL: http://e-journal.spa.msu.ru/vestnik/item/49 2015nikolaenko.htm (дата обращения: 21.03.2016).
Авторы интерпретируют достигнутые результаты, основываясь на принципах управления рисками (Таблица 2).
Таблица 2. Сравнительный анализ методического обеспечения, используемого для __управления ИТ-проектами12 __
Методология Фокусирование на риске Контроль риска Показатели риска Сложность внедрения Необходимость ресурсов Размер ИТ-проекта
PMBoK + + + Простой Средняя Большой
CMMI + + + Трудный Много Большой
RUP + + + Трудный Немного Большой
PRINCE2 + + - Простой Средняя Большой
SDLC - - - Средний Средняя Большой
Agile + + + Простой Немного Малый
SSADM - - + Средний Средняя Малый
Среди рассмотренных в Таблице 2 методических обеспечений необходимо отметить Agile, гибкую методологию управления ИТ-проектами (Agile Software Development)12. Agile — это комплекс подходов, позволяющих итеративно вести разработку ИТ-проекта, динамически изменяя при этом требования и цели проекта13. Специалисты The Standish Group International в ежегодном аналитическом отчете за 2013 год отмечают, что в большинстве успешно завершенных малых проектов были использованы подходы гибкой методологии Agile14. Исследования, проведенные Брандасом, Дидрагой и Бибу в 124 ИТ-организациях, подтверждают данную статистику (Рисунок 4).
Рисунок 4. Анализ подходов и методологий в управлении ИТ-проектами15
11 Brandas C., Didraga O., Bibu №Study on Risk Approaches in Software Development // Informatica Economica. 2012. Vol. 16. No 3. P 148-157.
12 Бек К. Экстремальное программирование: разработка через тестирование. СПб.: Питер, 2003.
13 Hoda R. Self-Organizing Agile Teams: A Grounded Theory. Wellington, NZ: Victoria University of Wellington, 2011.
14 The CHAOS Manifesto / The Standish Group International, 2013.
15 Бек К. Указ. соч.
Также Брандас, Дидрага и Бибу в своем аналитическом исследовании отмечают, что гибкая методология Agile не фокусируется на рисках и не использует систему контроля. Однако это утверждение является отчасти ошибочным. В Agile используются итеративный подход, после которого участники, задействованные в разработке ИТ-проекта, проводят ретроспективный анализ. Основной задачей ретроспективного анализа является выявление возможных угроз и опасностей (негативных рисков) и планирование системы мероприятий по их устранению.
Жизненный цикл ИТ-проекта
В своде правил управления проектами PMBoK жизненный цикл проекта определяется как последовательность работ, задаваемая исходя из потребностей управления (Рисунок 5).
Рисунок 5. Пример жизненного цикла проекта согласно PMBoK
Использование модели жизненного цикла позволяет определять последовательность действий и устанавливать взаимосвязь между различными типами рисковых событий. Чаще всего ИТ-проекты разрабатываются с использованием: каскадной модели жизненного цикла (WaterfallModel); V-образной модели жизненного цикла (V-model, Validation & Verification Model); модели быстрой разработки приложений RAD (Rapid Application Development); инкрементной модели жизненного цикла; спиральной модели жизненного цикла16.
• Каскадная модель жизненного цикла (Waterfall Model) — в ней реализация ИТ-проекта ведется последовательно. Примером может служить следующая последовательность действий: анализ требований, проектирование, разработка, тестирование, интеграция и поддержка17. Используя каскадную модель, проектная команда последовательно переходит от одного этапа разработки к другому только после полного и успешного завершения предыдущего этапа (Рисунок 6). Каскадная модель жизненного цикла имеет ряд недостатков. Во-первых, она требует наличия согласованного и утвержденного базового плана-графика всеми заинтересованными
16 Гламадзин Е.С., Новиков Д.А., Цветков А.В. Управление корпоративными программами: информационные системы и математические модели. М.: Институт проблем управления РАН, 2003.
17 Royce W.W. Managing the Development of Large Software System / The Institute of Electrical and Electronics Engineers. August 1970. P. 328-338. URL: https://www.cs.umd.edu/class/spring2003/cmsc838p/Pro cess/waterfall.pdf (accessed: 21.03.2016).
лицами проекта, что значительно увеличивает трудоемкость этапов «Требования» и «Проектирование». Во-вторых, в каскадной модели жизненного цикла фиксируются даты начала и окончания работ, ее длительность, бюджет и качество, что создает зоны риска и потенциальную угрозу для проекта. Это означает, что непредусмотренные негативные риски могут оказать катастрофическое влияние на успех проекта и повлечь за собой пересмотр требований и целей, вплоть до остановки проекта либо его преждевременного закрытия.
Рисунок 6. Каскадная модель жизненного цикла
• V-образная модель жизненного цикла (V-model, Validation & Verification Model)18 позволяет устанавливать связь между целями ИТ-проекта и результатами тестирования (Рисунок 7). Однако часто при использовании данной модели в процессе реализации ИТ-проекта могут возникать проблемы с выполнением параллельных задач и с динамическими изменениями требований. Также в V-образной модели жизненного цикла отсутствуют операции, направленные на идентификацию и анализ рисков, что делает ИТ-проект подверженным различным рисковым событиям.
Рисунок 7. V-образная модель жизненного цикла19
18 Balaji S., Sundararajan Murugaiyan M. Waterfall Vs V-Model Vs Agile: A Comparative on SDLC // International Journal of Information Technology and Business Management. 2012. Vol. 2. No 1. P. 26-30.
19 Ibid.
• Модель быстрой разработки приложений RAD (Rapid Application Development) позволяет задействовать пользователя на всех этапах жизненного цикла разработки ИТ-проекта20. Подобные коммуникации с пользователями позволяют минимизировать риски, связанные с дальнейшей доработкой созданного ИТ-продукта (Рисунок 8). Однако постоянное присутствие пользователя в процессе разработки может оказать и негативное влияние. Например, постоянный учет пользовательского мнения может легко «затянуть» срок реализации ИТ-проекта и создать риск того, что работа в проекте «никогда» не завершится. Необходимость оперативной реакции на обратную связь от пользователя также является проблемой модели жизненного цикла RAD, так как требует наличия высококвалифицированных специалистов, что значительно увеличивает стоимость проекта.
Время
Рисунок 8. Модель быстрой разработки приложений RAD21
• Инкрементная модель жизненного цикла — поэтапная модель, в которой разные части ИТ-продукта разрабатываются в разное время и разными темпами (Рисунок 9)22. Использование подобной модели жизненного цикла значительно упрощает проектирование, поскольку в начале разрабатываются основной функционал ИТ-продукта и функции, которые могут быть отнесены к группе риска. Однако инкрементная модель увеличивает трудоемкость при формализации требований проекта, его проектировании и тестировании, что увеличивает итоговую стоимость проекта.
20 Бахтизин В.В. Технология разработки программного обеспечения. Минск: БГУИР, 2010.
21 Там же.
22 Клейнер Г.Б. Мезоэкономика переходного периода: рынки, отрасли, предприятия. М.: Наука, 2001.
Рисунок 9. Инкрементная модель жизненного цикла23
• Спиральная модель жизненного цикла. В данной модели акцент ставится на идентификации и управлении рисками, где процедуры риск-менеджмента повторяются после каждой итерации и релиза прототипов (Рисунок 10). Среди менеджеров ИТ-проектов и разработчиков наибольшее распространение получила спиральная модель жизненного цикла, разработанная Б.В. Бёмом. Ее популярность может быть объяснена тем, что спиральная модель позволяет управлять рисками, итеративно реализовывать ИТ-проект, выбирая оптимальный вариант разработки и проводить корреляцию между получаемыми прототипами и целями ИТ-проекта. Главным недостатком спиральной модели жизненного цикла является то, что данная модель не может динамически реагировать на изменение целей ИТ-проекта.
В результате проведенного анализа жизненных циклов, применяемых для реализации ИТ-проектов, возникает потребность в разработке обобщенной модели жизненного цикла, которая учитывала бы специфику и особенности сферы информационных технологий, интегрировала бы положительные характеристики и минимизировала бы негативное влияние отрицательных. В этой связи автор статьи предлагает использовать обобщенную модель жизненного цикла ИТ-проекта, которая была получена в результате анализа различных моделей (Таблица 3).
23 Дайбова К.Е., Николаенко В.С. Разработка инструментария оперативной идентификации рисков в ИТ-проектах // Ресурсоэффективным технологиям — энергию и энтузиазм молодых. Сборник научных трудов VI Всероссийской конференции. Томск: Изд-во Томского политехнического университета, 2015. С. 254-257.
Рисунок 10. Спиральная модель жизненного цикла24 Таблица 3. Обобщенная модель жизненного цикла ИТ-проекта
№ Этапы жизненного цикла ИТ-проекта Описание этапа жизненного цикла ИТ-проекта Действия менеджера ИТ-проекта
1 Инициация мини-проекта (vision) Создание документа, в котором фиксируются цели, задачи проекта, описываются пользователи и планируемый продукт. Разрабатывает документ, в котором формулируются цели, задачи ИТ-проекта, основные требования, также описывается планируемый продукт и предполагаемые пользователи.
2 Инициация Даются примерные оценки ИТ-проекта, отклонение оценки срока реализации и бюджета до 50%. Подготавливает необходимые юридические документы (договор, заказ и т. д.).
3 Планирование Даются оценки ИТ-проекта, отклонение оценки срока реализации ИТ-проекта и бюджета до 10-15%. Формируется список требований к функциональности, упорядоченных по степени их важности (project backlog). Формирует команду. Разрабатывает иерархическую структуру работ (ИСР) (Work Breakdown Structure, WBS). Оценивает необходимые ресурсы. Оценивает продолжительность действий и стоимость ИТ-проекта. Разрабатывает метрики для управления качеством ИТ-
24 Дайбова К.Е., Николаенко В.С. Указ. соч. С. 254-257.
продукта. Создает план управления коммуникациями. Разрабатывает «план А» и «план Б» для управления 25 рисками25.
4 Реализация (планирование итерации) Команда планирует и оценивает функциональности на итерацию. Утверждает функциональности на итерацию.
Реализация (stand up meeting) Команда ИТ-проекта ежедневно проводит короткую встречу, где каждый участник отчитывается по выполненным задачам, а также рассказывает, с какими проблемами он столкнулся. Контролирует процесс реализации инкремента ИТ-продукта.
Реализация (ретроспективный анализ) Команда подводит итоги итерации. Оценивает состояние ранее идентифицированных рисков. Формулирует новые, выявленные в ходе итерации риски, анализирует их, разрабатывает меры по реагированию и контролю. Оценивает состояние ИТ-проекта. Предпринимает корректирующие меры.
Реализация (релиз) Презентация инкремента ИТ-продукта. Менеджер презентует инкремент ИТ-продукта. Утверждает функциональности на следующую итерацию.
5 Завершение Передача инкрементов ИТ-продукта заказчику. Осуществляет передачу инкрементов ИТ-продукта. Оценивает рассогласование фактических результатов с запланированными. Оценивает эффективность управления рисками.
6 Внедрение Внедрение разработанного ИТ-продукта. Сопровождение процесса внедрения ИТ-продукта.
7 Эксплуатация Эксплуатация, техническое обслуживание, сопровождение разработанного ИТ-продукта. Сопровождение эксплуатации ИТ-продукта.
8 Модернизация Доработка и (или) усовершенствование разработанного ИТ-продукта. Сопровождение процесса модернизации ИТ-продукта. Инициация нового ИТ-проекта при необходимости.
9 Ликвидация Удаление разработанного ИТ-продукта из бизнес-процессов. Сопровождение процесса ликвидации ИТ-продукта.
Степень детализации этапов жизненного цикла обусловлена сложностью ИТ-проекта, поэтому в зависимости от целей проекта некоторые этапы могут быть объединены либо, наоборот, более детализированы.
Типичные и часто встречаемые риски в ИТ-проектах
Многие исследователи, работающие с ИТ-проектами, эмпирически установили наиболее вероятные риски, так называемые часто встречаемые риски, которые типичны для многих ИТ-проектов. Так, в работе Т. Аддисона рассматривается список
25 Дайбова К.Е., Николаенко В.С. Указ. соч. С. 254-257.
негативных рисков, которым чаще всего подвержены ИТ-проекты26. Ранжирование рисковых событий в Таблице 4 построено согласно влиянию часто встречаемых рисков на успех ИТ-проекта.
Таблица 8. Часто встречаемые риски, выявленные Т. Аддисоном27
Номер риска Название негативного риска
Риск 1 Цели ИТ-проекта будут неточны и неконкретны
Риск 2 Будет недооценка требований ИТ-проекта
Риск 3 Пользователям не понравится разработанный ИТ-продукт
Риск 4 Будут ошибки (bug) в процессе реализации ИТ-проекта
Риск 5 Менеджер ИТ-проекта будет недостаточно вовлечен в ИТ-проект
Риск 6 Будут установлены неадекватные сроки реализации проекта и установлен неадекватный бюджет
Риск 7 Могут измениться требования в процессе реализации ИТ-проекта
Риск 8 Будет отсутствовать методическое обеспечение ИТ-проекта (Waterfall, Agile и т. п.)
Риск 9 Знания и умения проектной команды не будут соответствовать требованиям проекта
Риск 10 Менеджер ИТ-проекта завысит качество, предъявляемое к проекту — «золотая сервировка» (gold plating)
Также Аддисон в своей работе приводит данные о степени важности каждого из вышерассмотренных рисков (Рисунок 11).
LQ0
Рнск 1 Рнск 2 Риск 3 Рнск 4 Риск; Риск б Риск 7 Рнск S Риск 9 Риск 10
В Не важный И Важный В Очень важный
Рисунок 11. Степень важности управления рисков, согласно Т. Аддисону28
Ученые К. Стевен и С. Фовелл в своей работе также рассматривают рисковые события, которые чаще, чем остальные, наступают в ИТ-проектах (Таблица 9)29.
26 Addison T., Vallabh S. Controlling Software Project Risks — An Empirical Study of Methods Used by Experienced Project Managers // Proceedings of SAICSIT. 2002. P. 128-140.
27 Ibid.
28 Ibid.
Таблица 9. Часто встречаемые риски, выявленные К. Стевеном и С. Фовеллом30
Номер риска Название негативного риска
Риск 1 Менеджер проекта не будет заинтересован в успехе ИТ-проекта
Риск 2 Будут отсутствовать коммуникации с пользователями
Риск 3 Участники проектной команды недооценят сложность ИТ-проекта и его требования
Риск 4 Пользователям не будет интересен разрабатываемый ИТ-продукт
Риск 5 Результаты ИТ-проекта не оправдают ожиданий заказчика и пользователя
Риск 6 Будет изменение требований в процессе реализации проекта
Риск 7 У проектной команды будет недоставать знаний и навыков для реализации ИТ-проекта
Риск 8 Будет отсутствовать «заморозка» требований (frozen requirements) в процессе реализации ИТ-проекта
Риск 9 Будут использоваться новые технологии
Риск 10 Участники проектной команды не будут подходить для реализации ИТ-проекта
Риск 11 Будет конфликт между заинтересованными лицами проекта
М. Самнер в своей работе перечисляет основные факторы, вызывающие риски в крупных ИТ-проектах31. Под крупным проектом Самнер подразумевает проект, который планируется реализовывать более года (Таблица 10).
Таблица 10. Часто встречаемые риски, выявленные М. Самнером32
Номер риска Название негативного риска
Риск 1 На ИТ-проект будет оказывать влияние внешняя среда
Риск 2 У участников проектной команды не будет достаточно опыта
Риск 3 Будут отсутствовать профессиональные экспертизы
Риск 4 Не будут ясны цели ИТ-проекта
Риск 5 Будут меняться требования ИТ-проекта в процессе реализации
Риск 6 Будет отсутствовать методическое обеспечение управления ИТ-проектом (Waterfall, Agile и т. п.)
Риск 7 Будут отсутствовать коммуникации с пользователем, или их будет недостаточно
Риск 8 Будет некачественно запланирован бюджет и сроки реализации ИТ-проекта
Риск 9 Будет конфликт между заинтересованными лицами проекта
В ежегодном аналитическом отчете Chaos Manifesto 2013 также перечисляются факторы, которые влияют на успех ИТ-проектов. Проведя опрос среди менеджеров проектов, специалисты The Standish Group International представили ранжирование данных факторов по степени важности, где 100 баллов — это максимальная оценка (Таблица 11).
29 Stevens K.J., Fowell S. Perspective on E-Business Software Project Risk / 7th Pacific Asia Conference on Information Systems. 2003. P. 95-107.
30 Ibid.
31 Sumner M. Risk Factors in Enterprise-wide / ERP Projects // Journal of Information Technology. 2000. No 15. P. 317-327.
32 Ibidem.
Таблица 11. Факторы, влияющие на успех ИТ-проекта
Номер риска Факторы, влияющие на успех ИТ-проекта Баллы
Риск 1 Будет низкая заинтересованность менеджера ИТ-проекта 20
Риск 2 Пользователь не будет вовлечен в процесс разработки 15
Риск 3 ИТ-проект будет слишком большим и слишком сложным 15
Риск 4 Будут отсутствовать необходимые профессиональные навыки 13
Риск 5 Не будет экспертных оценок и экспертиз 12
Риск 6 Будут использоваться классические технологии реализации ИТ-проекта, например Waterfall 10
Риск 7 Будут неясно сформулированы цели ИТ-проекта 6
Риск 8 Будет отсутствовать эмоциональное мотивирование 5
Риск 9 Будет отсутствовать система контроля и быстрого реагирования 3
Риск 10 Не будут использоваться инструменты, необходимые для проектного управления 1
В этой связи могут быть идентифицированы типичные риски, которые имеют высокую вероятность наступления в ИТ-проектах. Результаты часто встречаемых рисков представлены в Таблице 12.
Таблица 12. Типичные и часто встречаемые риски для ИТ-проектов
Номер риска Название негативного риска
Риск 1 Цели ИТ-проекта будут неясны, неточны и неконкретны
Риск 2 Будут установлены неадекватные сроки реализации проекта и запланирован неадекватный бюджет
Риск 3 Могут измениться требования в процессе разработки ИТ-проекта
Риск 4 Будет недооценка требований и сложностей ИТ-проекта
Риск 5 Разработанный ИТ-продукт не будет пользоваться популярностью у пользователя
Риск 6 Будут ошибки (bug), допускаемые в процессе разработки
Риск 7 Проектная команда не будет иметь необходимых компетенций
Риск 8 Будет отсутствовать эффективное методическое обеспечение для управления ИТ-проектом (Agile, Waterfall и т. п.)
Риск 9 Будут сбои при коммуникациях между заинтересованными лицами проекта (менеджером, заказчиком, проектной командой и пр.)
Риск 10 Субподрядчики не будут выполнять условия контракта
Риск 11 Будут применяться новые технологий в ИТ-проекте
Риск 12 Будет некачественное управление ожиданиями заказчика, проектной команды и др.
Риск 13 Будут низкими производительность и мотивация проектной команды
Риск 14 Менеджер проекта будет завышать качество ИТ-проекта — «золотая сервировка» (gold plating)
Изучая часто встречаемые риски, специалисты The Standish Group International установили, что малые ИТ-проекты, то есть проекты, которые планируется реализовать не более чем за полгода и бюджет которых не превышает 1 млн долл., на 70% успешнее больших ИТ-проектов. Под большими ИТ-проектами в Chaos Manifesto понимаются проекты, которые реализуются от полугода и бюджет которых превышает 1 млн долл. В больших проектах в 10 раз чаще, чем в малых,
наступают рисковые события, влияющие на срок разработки, бюджет, качество. Так, федеральные ИТ-проекты США, бюджет которых превышает 1 млрд долл., регулярно пересматривают базовые планы и бюджеты ИТ-проектов, из-за возникающих проблем в процессе реализации, например, таких как техническая сложность разработок, государственные стандарты, конфликт целей проектов в связи с многочисленными комментариями ответственных лиц и т. п.33 На Рисунке 12 показан сравнительный анализ успешного завершения больших и малых ИТ -проектов в 2012 году.
Рисунок 12. Сравнительный анализ успешно завершенных больших и малых проектов в 2012 году34
На основании проведенного анализа методических обеспечений, использующихся для управления ИТ-проектами, жизненных циклов ИТ-проектов и часто встречаемых рисков в ИТ-проектах, автором статьи были сформированы девять методических подходов, ликвидирующих и / или уменьшающих вероятность наступления типичных и часто встречаемых рисков (Таблица 13)35.
33 Mishra A., Das S., Murray J. Managing Risk in Government Information Technology Projects: Does Process Maturity Matter? // Production and Operations Management. 2014. No 24 (3). P. 365-368.
34 The CHAOS Manifesto / The Standish Group International, 2013.
35 Николаенко B.C. Разработка принципов управления ИТ-проектом // Вестник Томского государственного университета. 2015. № 390. С. 155-160.
Таблица 13. Методическое обеспечение для управления ИТ-проектами
№ Название Комментарии Номер риска
1 Оптимизация Декомпозиция большого проекта на несколько малых проектов, Риск 2
проекта то есть создание портфеля проектов (project portfolio) с назначением ответственного лица, менеджера портфеля проектов, отвечающего за успешное завершение данных проектов Риск 4
2 Инициализация мини-проекта для создания виденья проекта (vision) Создание документа, в котором фиксируются цели, задачи проекта, описываются пользователи и планируемый продукт Риск 1
3 Привлечение Привлечение независимых экспертов для идентификации и Риск 1
независимых оценки рисков Риск 2
экспертов Риск 3 Риск 4 Риск 6 Риск 8
4 Использование Оценки срока реализации ИТ-проекта и бюджета на этапе Риск 2
грубых оценок инициации не должны превышать 50% Риск 4
Оценки срока реализации ИТ-проекта и бюджета на этапе Риск 2
планирования не должны превышать 10-15% Риск 4
5 Использование Agile Применение современных, гибких методологий в процессе разработки ИТ-проекта Риск 3 Риск 8 Риск 12 Риск 13 Риск 14
6 Итеративный Итеративный подход предполагает разбиение жизненного цикла Риск 1
подход разработки ИТ-проекта на последовательность итераций. Этот подход дает возможность проведения участниками проектной команды ретроспективного анализа после завершения итерации с целью обеспечения контроля ранее идентифицированных рисков и выявления новых Риск 2 Риск 3 Риск 4 Риск 9 Риск 12 Риск 13 Риск 14
7 Фокус-группы пользователей Тестирование инкрементов ИТ-продукта потенциальными пользователями после завершения итерации Риск 5
8 Корректировка Проведение корреляции между основными параметрами, целями Риск 1
основных проекта и полученными инкрементами ИТ-продукта на этапе Риск 2
параметров проекта релиза Риск 3
на этапе релиза (release) Риск 4 Риск 9
9 «Личная Закрепление за участниками ИТ-проекта «личной Риск 2
ответственность за ответственности за риск», то есть формирование зоны Риск 6
риск» у участников ответственности за контроль и мониторинг рисков Риск 13
проектной команды
В результате исследования методического обеспечения, используемого для управления ИТ-проектами, анализа жизненных циклов ИТ-проектов и часто встречаемых рисков, были разработаны девять подходов для безрискового управления, которые легли в основу методического обеспечения по управлению ИТ-проектами (Таблица 13)36. В этой связи может быть сформулирована гипотеза о том, что
36 Исследование выполнено при финансовой поддержке РФФИ в рамках научного проекта № 16-36-00031 мол_а.
разработанное методическое обеспечение даст возможность руководителям ИТ-организаций, менеджерам ИТ-проектов и другим ИТ-специалистам нивелировать и / или ослабить часто встречаемые рисковые события. Подтверждение данной гипотезы требует проведения дальнейших исследований и экспериментальной апробации.
Список источников и литературы:
1. Бахтизин В.В. Технология разработки программного обеспечения. Минск: БГУИР, 2010.
2. Бек К. Экстремальное программирование: разработка через тестирование. СПб.: Питер, 2003.
3. ГагаВ.А., НиколаенкоВ.С. Создание системы управления проектами в организации с применением эвристических методов // Вестник Томского государственного университета. 2013. № 374. С. 137-140.
4. Гламадзин Е.С., Новиков Д.А., Цветков А.В. Управление корпоративными программами: информационные системы и математические модели. М.: Институт проблем управления РАН, 2003.
5. Дайбова К.Е., Николаенко В.С. Разработка инструментария оперативной идентификации рисков в ИТ-проектах // Ресурсоэффективным технологиям — энергию и энтузиазм молодых. Сборник научных трудов VI Всероссийской конференции. Томск: Изд-во Томского политехнического университета, 2015. С. 254-257.
6. Йордон Э. Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте. М.: Лори, 2012.
7. Клейнер Г.Б. Мезоэкономика переходного периода: рынки, отрасли, предприятия. М.: Наука, 2001.
8. Николаенко В.С. Анализ инструментария по обеспечению функции управления рисками в ИТ-проектах // Государственное управление. Электронный вестник. 2015. № 49. С. 105-120. URL: http://e-iournal.spa.msu.ru/vestnik/item/49 2015nikolaenko.htm (дата обращения: 21.03.2016).
9. Николаенко В.С. Разработка принципов управления ИТ-проектом // Вестник Томского государственного университета. 2015. № 390. С. 155-160.
10. Хэлдман К. Управление проектами. М.: ДМК Пресс; Академия АйТи, 2007.
11. Addison T., Vallabh S. Controlling Software Project Risks — An Empirical Study of Methods Used by Experienced Project Managers // Proceedings of SAICSIT. 2002. P. 128-140.
12. A Guide to the Project Management Body of Knowledge (PMBoK Guide). 4th edition / Project Management Institute (PMI), 200В.
13. Balaji S., Sundararajan Murugaiyan M. Waterfall Vs V-Model Vs Agile: A Comparative on SDLC // International Journal of Information Technology and Business Management. 2012. Vol. 2. No 1. P. 26-30.
14. Brandas C., Didraga O., Bibu N. Study on Risk Approaches in Software Development // Informatica Economica. 2012. Vol. 16. No 3. P 148-157.
15. Ching Gu V., Hoffman J.J., Cao Q., Schniederjans M.J. The Effects of Organizational Culture and Environmental Pressures on IT-project Performance: A Moderation Perspective // International Journal of Project Management. 2014. No 32. P. 1170-1181.
16. CNews Analytics [Site]. URL: http://www.cnews.ru/ (дата обращения: 16.03.2016).
17. HodaR. Self-Organizing Agile Teams: A Grounded Theory. Wellington, NZ: Victoria University of Wellington, 2011.
1В. LaceyM. The Scrum Field Guide: Practical Advice for Your First Year. Indianapolis, Ind.: Addison-Wesley, 2013.
19. McKinsey & Company [Official Site]. URL: http://www.mckinsey.com/ (accessed: 16.03.2016).
20. Merna T., Al-Thani F. Corporate Risk Management. New York: John Wiley & Sons, Ltd, 200В.
21. Mishra A., Das S., Murray J. Managing Risk in Government Information Technology Projects: Does Process Maturity Matter? // Production and Operations Management. 2014. No 24 (3). P. 365-368.
22. Royce W. W. Managing the Development of Large Software System / The Institute of Electrical and Electronics Engineers. August 1970. P. 328-338. URL: https://www.cs.umd.ed u/class/spring2003/cmsc838p/Process/waterfall.pdf (accessed: 21.03.2016).
23. Stevens K.J., Fowell S. Perspective on E-Business Software Project Risk / 7th Pacific Asia Conference on Information Systems. 2003. P. 95-107.
24. SumnerM. Risk Factors in Enterprise-wide / ERP Projects // Journal of Information Technology. 2000. No 15. P. 317-327.
25. The CHAOS Manifesto / The Standish Group International, 2013.
Nikolaenko V.S.
Preventive Risk Management in IT-Projects
Valentin S. Nikolaenko — Teaching Assistant, Management Department, Tomsk Polytechnic University; graduate student, Tomsk State University, Tomsk, Russian Federation. E-mail: nikolaenkovs@tpu. ru
Annotation
The article presents the methodological support for the management of IT projects, to be used by project managers (PM) and other IT-professionals in order to eliminate or reduce typical business risks. The methodological support is based on the analysis of the life cycle models for IT-projects and the analysis of typical risk events in IT projects, as well as on the results obtained during the study of methodological support used in IT project management. The purpose of the article is to establish a methodological framework for risk management in IT projects.
Keywords
Risk, risk management, IT-project.
References:
1. Bakhtizin V.V. Tekhnologiia razrabotki programmnogo obespecheniia. Minsk: BGUIR, 2010.
2. Bek K. Ekstremal'noeprogrammirovanie: razrabotka cherez testirovanie. Saint Petersburg: Piter, 2003.
3. Gaga V.A., Nikolaenko V.S. Sozdanie sistemy upravleniia proektami v organizatsii s primeneniem evristicheskikh metodov. Vestnik Tomskogo gosudarstvennogo universiteta, 2013, 374, pp. 137-140.
4. Glamadzin E.S., Novikov D.A., Tsvetkov A.V. Upravlenie korporativnymi programmami: informatsionnye sistemy i matematicheskie modeli. Moscow: Institut problem upravleniia RAN, 2003.
5. Daibova K.E., Nikolaenko V.S. Razrabotka instrumentariia operativnoi identifikatsii riskov v IT-proektakh. Resursoeffektivnym tekhnologiiam — energiiu i entuziazm molodykh. Sbornik nauchnykh trudov VI Vserossiiskoi konferentsii. Tomsk: Izd-vo Tomskogo politekhnicheskogo universiteta, 2015. Pp. 254-257.
6. Iordon E. Put' kamikadze. Kak razrabotchiku programmnogo obespecheniia vyzhit' v beznadezhnom proekte. Moscow: Lori, 2012.
7. Kleiner G.B. Mezoekonomikaperekhodnogoperioda: rynki, otrasli, predpriiatiia. Moscow: Nauka, 2001.
8. Nikolaenko V.S. Analiz instrumentariia po obespecheniiu funktsii upravleniia riskami v IT-proektakh. Gosudarstvennoe upravlenie. Elektronnyi vestnik, 2015, 49, pp. 105-120. URL: http://e-journal.spa.msu.ru/vestnik/item/49 2015nikolaenko.htm (data obrashcheniia: 21.03.2016).
9. Nikolaenko V.S. Razrabotka printsipov upravleniia IT-proektom. Vestnik Tomskogo gosudarstvennogo universiteta, 2015, 390, pp. 155-160.
10. Kheldman K. Upravlenie proektami. Moscow: DMK Press; Akademiia AiTi, 2007.
11. Addison T., Vallabh S. Controlling Software Project Risks — An Empirical Study of Methods Used by Experienced Project Managers. Proceedings of SAICSIT. 2002. Pp. 128-140.
12. A Guide to the Project Management Body of Knowledge (PMBoK Guide). 4th edition / Project Management Institute (PMI), 2008.
13. Balaji S., Sundararajan Murugaiyan M. Waterfall Vs V-Model Vs Agile: A Comparative on SDLC.
International Journal of Information Technology and Business Management, 2012, vol. 2, no 1, pp. 26-30.
14. Brandas C., Didraga O., Bibu N. Study on Risk Approaches in Software Development. Informatica Economica, 2012, vol. 16, no 3, pp. 148-157.
15. Ching Gu V., Hoffman J.J., Cao Q., Schniederjans M.J. The Effects of Organizational Culture and Environmental Pressures on IT-project Performance: A Moderation Perspective. International Journal of Project Management, 2014, 32, pp. 1170-1181.
16. CNews Analytics [Site]. URL: http://www.cnews.ru/ (data obrashcheniia: 16.03.2016).
17. Hoda R. Self-Organizing Agile Teams: A Grounded Theory. Wellington, NZ: Victoria University of Wellington, 2011.
18. Lacey M. The Scrum Field Guide: Practical Advice for Your First Year. Indianapolis, Ind.: Addison-Wesley, 2013.
19. McKinsey & Company [Official Site]. URL: http://www.mckinsey.com/ (accessed: 16.03.2016).
20. Merna T., Al-Thani F. Corporate Risk Management. New York: John Wiley & Sons, Ltd, 2008.
21. Mishra A., Das S., Murray J. Managing Risk in Government Information Technology Projects: Does Process Maturity Matter? Production and Operations Management, 2014, 24 (3), pp. 365-368.
22. Royce W.W. Managing the Development of Large Software System / The Institute of Electrical and Electronics Engineers. August 1970. Pp. 328-338. URL: https://www.cs.umd.edu/class/spring2003/cmsc838p/Pr ocess/waterfall.pdf (accessed: 21.03.2016).
23. Stevens K.J., Fowell S. Perspective on E-Business Software Project Risk / 7th Pacific Asia Conference on Information Systems. 2003. Pp. 95-107.
24. Sumner M. Risk Factors in Enterprise-wide / ERP Projects. Journal of Information Technology, 2000, 15, pp. 317-327.
25. The CHAOS Manifesto / The Standish Group International, 2013.
