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

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

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

· с продуктом проекта.

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

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

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

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

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

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

Таблица 4

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

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

В основе модели управления качеством крупного проекта должна находиться система управления рисками проекта.

Практически любой процесс проекта имеет свой собственный (специфичный) набор рисков и некоторый общий набор рисков для всех процессов проекта. В соответствии со стандартом ИСО 10006:1996 управление рисками включает следующие виды деятельности:

· выявление - определение рисков в проекте;

· оценка - оценивание вероятности появления рисковых событий и их воздействия на проект;

· развитие реакции - разработка планов реагирования на риски;

· контроль за рисками - реализация и обновление рисковых планов.

Для выявления рисков первоначально необходимо выбрать объекты, которые будут анализироваться. К ним относятся процессы и продукты проекта. Как правило, в сферу анализа рисков невозможно включить все процессы и продукты проекта, так как это может потребовать неприемлемых затрат времени и сил, поэтому приходится останавливаться на некоторых наиболее важных и критичных процессах и продуктах. Поможет в выборе таких процессов анализ конфигурации. В стандартах ИСО/МЭК 12207:1995 "Информационные технологии. Процессы жизненного цикла программного обеспечения" и ИСО 10007:1995 представлены процедуры и задачи, которые должны выполняться при управлении конфигурацией. Конфигурация проекта обычно основывается на спецификациях ИС на определенном этапе работ и процессах, выполнение которых приведет к созданию этой системы. Так же можно определить взаимосвязи процессов и соответственно наметить возможные "переходные" риски.

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

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

Важным этапом работ по управлению риском проекта является разработка планов реагирования на риск. Как правило, для разработки таких планов недостаточно идентифицировать и оценить риски, необходимо еще и провести анализ причин их возникновения. Одним из простых и достаточно эффективных методов такого анализа может служить метод FME(С)A (Failure Mode, Effects and (Criticality) Analysis) - метод анализа видов, последствий и (критичности) отказов (дефектов). На этом этапе работ определяется стратегия внесения изменений в проект, так как конфигурация проекта находится в прямой зависимости от вероятных рисков процессов. При необходимости планы реагирования на риск должны строиться на основе данных предыдущих аналогичных проектов, так как это уменьшит вероятность внесения новых рисков. Составляя планы реагирования на риск, целесообразно учитывать возможность с помощью одного мероприятия предотвратить несколько рисков. Такая возможность появляется, например, при наличии "переходных" рисков.

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