Файл: Учебное пособие Издательство Нижневартовского государственного гуманитарного университета 2008.pdf

158 зации работ, трудоемкого управления целостностью проекта и интегрированностью ре- шений и системы.
8.1.1. Риски, связанные с предприятием
В этой группе можно выделить такие риски, как недостаточность опыта внедрения ор- ганизацией подобных систем, слабо формализованная организационная структура пред- приятия, отсутствие формализованных бизнес-процессов компании, информационных систем, финансовое состояние предприятия и возможность финансировать проектные работы в полном объеме. Важна также реалистичность ожиданий руководства компании и рядовых сотрудников, взаимоотношения с подрядчиком, помогающим внедрять систему.
8.1.2. Риски связанные с предметной областью (риск в IT сфере)
Для того, чтобы управление рисками было эффективным, необходимо брать в расчет бизнес-среду, в которой осуществляется проект. Большинство IT-проектов не удались не по причинам, связанным с технологическими нюансами, а в связи с организационны- ми обстоятельствами, которые обычно игнорируются. Такие обстоятельства могут про- являться в различных формах — как, например, конкуренция, финансовое состояние, ор- ганизационная культура (рис. 8.2).
Рис. 8.2. Список источников риска и их возможных последствий
Следует отметить, что элементы значительных рисков не всегда одинаковы для раз- личных IT-проектов.
8.1.3. Риски, связанные с ресурсами проекта
К таким рискам относится квалификация проектной команды, опыт конкретных уча- стников проекта, оснащение проектной команды, территориальная распределенность участников проекта, опыт и квалификация руководителя проекта. Последний фактор яв- ляется важным, т.к. сильная команда со слабым руководителем имеет меньше шансов на успех, чем слабая команда с сильным руководителем. Такая команда имеет шансы стать сильной командой на протяжении проекта, но, безусловно, для успеха проекта важны оба фактора.

159
8.1.4. Риски, связанные с техническими факторами
Надежность и проверенность аппаратного и программного обеспечения, на которое делаются ставки в проекте. Как правило, чем новее аппаратные платформы и программ- ное обеспечение, тем выше риски сбоев в их работе. С другой стороны, старые продукты могут не обеспечить нормального функционирования системы в будущем — при росте объемов данных, появлении новых требований к системе.
8.1.5. Риски, связанные с ситуацией на рынке
Внешние риски, как правило, связаны с ситуацией на рынке. Проекты внедрения на предприятиях, работающих на динамичных, развивающихся рынках, либо недостаточно стабильных рынках, наиболее подвержены рискам изменения требований бизнеса на протяжении проекта.
8.1.6. Риски, связанные с выбором
консалтинговой компании, заключением контракта
При выборе компании важно убедиться в наличии опыта и квалифицированной ко- манды. При заключении договора с консалтинговой компанией важны условия и обяза- тельства сторон, определяемые в контракте. Так называемые «time materials» («время и материалы») контракты, для которых в обязанности консалтинговой компании входит только предоставление квалифицированных консультантов, имеют недостатки, связан- ные с иногда ограниченной ответственностью консалтинговой компании за результаты, нечеткими сроками и стоимостью проекта. Для контракта с фиксированными задачами и ценой должна быть проведена детальная предпроектная проработка, которая требует су- щественных ресурсов.
8.1.7. Риски, связанные с управлением проектом
К рискам управления проектами стоит отнести детальность и точность проработки плана структуры проекта, ключевых результатов и контрольных точек в рамках проекта, четкое определение процедур контроля качества результатов проекта, процедур управле- ния изменениями в проекте и контроля границ проекта.
8.2. Проектные отклонения. Риски, проблемы, изменения
Планируя проект, мы предполагаем, что не все получится именно так, как запланиро- вано [70]. И реальное исполнение проекта, как правило, подтверждает эти опасения. Воз- никающие несовпадения первоначального согласованного и зафиксированного представ- ления о проекте (project baseline) и того, что получается в действительности, и называют- ся обычно отклонениями. Понимаемый в этом смысле термин «отклонения» эквивален- тен термину «deviations», используемому в англоязычной литературе.
К традиционным областям управления проектами, так или иначе связанным с откло- нениями, относятся риски, проблемы и изменения. И хотя не во всех стандартах эти по- нятия объединяются общим понятием отклонения, наличие взаимосвязей между ними очевидно. Понимание этих связей и адекватное отражение их в стандарте управления проектом обеспечит возможность систематического контроля и анализа отклонений, как в отдельном проекте, так и в масштабах предприятия в целом.

160
8.3. Сценарии управления отклонениями
Управление отклонениями в основном сводится к борьбе с неприятностями, которая в общем случае может включать три стадии:
Управление рисками. Неприятности еще не наступили, но существует возможность возникновения нежелательных и незапланированных событий, которые могут привести к тому, что цели проекта (одна или несколько) не будут достигнуты. Цель этой стадии – предотвратить неприятности до их возникновения или, по крайней мере, встретить их во всеоружии.
Управление проблемами. Неприятности наступили и необходимо выяснить их про- исхождение, степень влияния на проект, способы преодоления. Цель этой стадии – обес- печить проекту возможность идти так, как запланировано.
Управление изменениями. Неприятности оказались достаточно серьезными, и спра- виться с ними без ущерба для проекта не удалось. Цель этого этапа – то, что у финанси- стов называется «зафиксировать убытки» – модификация ранее согласованных продук- тов и услуг, сроков исполнения и стоимости работ, управленческих и технологических процессов и т.п.
События в проекте, связанные с отклонениями, могут развиваться по различным сце- нариям (рис. 8.3).
Рис. 8.3. Общая схема управления отклонениями
Полному циклу управления отклонениями соответствует первый сценарий, при кото- ром, в ходе планирования проекта был идентифицирован риск, но работа с ним не приве- ла к желаемому результату,
Возникшая в результате наступления рискового события проблема также не была ус- пешно решена и это, в результате, привело к необходимости внесения изменений в план проекта.
Для сравнения рассмотрим второй сценарий, при котором изменения в проекте реали- зуют, не дожидаясь возникновения проблем. Это достаточно ответственное решение. Си- туации, когда такие решения оправданы, могут быть описаны в стандарте с указанием конкретных категорий рисков и количественных оценок рисков, при которых должен быть реализован данный сценарий.

161
Особый интерес с точки зрения анализа отклонений представляют четвертый и пятый сценарии, соответствующие случаю возникновения проблем, неучтенных в качестве рис- ков. Причиной этого может быть, например, нетипичность ситуации или просто «потеря» риска в результате недостатка квалификации. Результатом анализа причин и тяжести по- следствий может явиться решения о том, что для определенных категорий проектов предприятия вообще не целесообразно глубоко заниматься управлением рисками, а дос- таточно просто решать проблемы по мере их возникновения.
8.4. Список рисков TOP 10
Анализ рисков помогает взвешенно оценить угрозу каждого риска и определить, какие именно из них заслуживают внимания. Управление рисками, как и любая другая фор- мальная процедура, отвлекает время и усилия от других составляющих проекта. Для снижения временных затрат и повышения эффективности управления проектом следует управлять только ограниченным количеством важнейших рисков (обычно 10 или 5). Для ранжирования их значения должна быть определена единая шкала.
После проведения ранжирования воздействий рисков, проектная команда должна сфо- кусироваться на стратегии управления рисками и на том, как увязать активность по рабо- те с рисками с общим планом работ по проекту. Список TOP 10 представляет собой эффективную и простую методику управления рисками и должен быть всегда доступен для всех заинтересованных сторон проекта и, в первую очередь, для совладельцев.
8.5. Управление рисками
Управление рисками устанавливает дисциплину и создает обстановку для принятия решений и осуществления действий для постоянной оценки того, что происходит непра- вильно, и выявления рисков, требующих особого внимания.
Существуют два совершенно разных подхода к управлению рисками — активный и пассивный. Пассивное управление рисками подразумевает, что руководитель проекта реагирует на последствия риска (реальные проблемы), когда они возникают. Активное управление рисками означает, что проектная команда постоянно находится в процессе управления рисками. Предотвращение риска — ключевое понятие в отличиях между ак- тивным и пассивным подходом. Предотвращение происходит на стадиях планирования проекта, когда есть возможность препятствовать возникновению рисков. Важно пони- мать, что предотвращение — это стратегия управления рисками, а не аналог лекарства, подавляющего симптомы.
Для достижения качественных результатов в активном управлении рисками команда должна быть готова предпринять контролируемые рискованные действия. Это означает, что не надо бояться риска, а надо использовать его как средство для создания новых воз- можностей.
Используя такой подход, проектная команда постоянно оценивает риски и использует их анализ для принятия решений на всех фазах проекта (рис. 8.4). Риски обрабатываются до тех пор, пока они не исчезают или пока не превращаются в проблемы, решаемые со- ответствующим образом.

162
Рис. 8.4. Определение рисков и управление ими на всех фазах проекта
Определение риска — первый шаг в процессе активного управления. Очевидно, что риски должны быть определены для того, чтобы ими можно было управлять. Определе- ние рисков снабжает команду информацией, которая позволяет выявить основные опас- ности, прежде чем они смогут неблагоприятно отразиться на проекте. Взаимодействия и коммуникации, происходящие между членами команды и ключевыми заинтересованны- ми в проекте лицами (совладельцами), на данном этапе очень важны. Определение рис- ков происходит, когда члены команды и ключевые совладельцы используют диаграммы неблагоприятных факторов и, посредством открытых дискуссий, определяют и ранжи- руют риски проекта. После выявления рисков необходимо составить их описания и по- строить соответствующий список (табл. 8.1).
Таблица 8.1
Факторы риска
Малый риск
Средний риск
Малый риск
Соответствие проекта
Полностью поддерживает миссию и цели заказчика
Не полностью соответствует одной или нескольким целям
Не соответствует миссии це- ли заказчика
Представление заказчика
Ожидает, что команда вы- пустит продукт проекта
Полагает, что команда не ра- ботает над ожидаемым про- дуктом проекта
Полагает, что желаемый продукт проекта не может быть реализован командой
Work flow
Не вызывает или вызыва- ет незначительные изме- нения в Work flow
Изменяет некоторые аспекты или в малой степени влияет на Work flow
Значительно изменяет Work flow или методы работы
Факторы риска группируются по классам и по группам. Примерами категорий факто- ров риска внутри класса могут быть, например, миссия и цели, центры принятия реше- ний, факторы организации и управления, факторы бюджета и стоимости. Примеры клас- сов: разработка заказного ПО, быстрое внедрение инфраструктуры, внедрение коробоч- ного ПО, планирование корпоративной инфраструктуры, внедрение на базе отдельных компонент.
В документации (стандарте предприятия) по планированию управления рисками должна быть отражена формальная сторона управления рисками, а именно:
1. Процедуры, регламентирующие основные этапы работы с рисками – идентифика- ция рисков, мониторинг и анализ рисков, разработка планирование и реализация меро- приятий по противодействию рискам.

163 2. Шаблоны документов, отражающих процесс работы с рисками – карточка риска, журнал рисков проекта и т.д.
Из всего многообразия методов управления рисками для стандарта должны быть ото- браны те из них, которые адекватны проектам, в которых они будут применяться. Здесь мы имеем в виду, прежде всего, стоимость реализации управленческих процедур
Так, при анализе рисков может допускаться сознательное огрубление оценок для ка- ких-то конкретных категорий проектов, например, для проектов малой стоимости или сложности. Пример такого подхода приведен в табл. 8.2, где в качестве обобщенной оценки риска используется степень угрозы риска, «вычисляемая» через вероятность на- ступления рискового события и его влияния на ход проекта.
«Цена деления», как на вспомогательных (вероятность и влияние), так и на основной шкале (степень угрозы) должна определяться из сугубо практических соображений – достижима ли та или иная точность и может ли она быть использована.
Таблица 8.2
Матрица степени угрозы риска
Вероятность события
Влияние на проект
Низкая менее 20%
Средняя от 20 до 60%
Высокая более 60%
Слабое Возможно появление вопросов или проблем в проекте, но вряд ли при- ведет к нарушению календарного гра- фика, бюджета или ухудшению качест- ва продукта
Низкая
Средняя
Средняя
Среднее Возможно нарушение графи- ка, увеличение стоимости или ухудше- ние качества продукта
Низкая
Высокая
Высокая
Сильное Возможно значительное на- рушение графика, увеличение стоимо- сти или ухудшение качества продукта
Средняя
Высокая
Критическая
По каким сценариям будет развиваться управление отклонениями в проекте, во мно- гом определяется принятыми стратегиями работы с рисками. Можно делать все для избе- гания риска, и тогда наиболее вероятным является второй сценарий (рис. 8.3). Можно, наоборот, принять риск и не противодействовать ему, допуская развитие событий по первому или по третьему сценарию. Можно также снижать риск и тогда при благоприят- ном развитии событий реализуется самый желанный сценарий, когда рисковое событие не наступает.
8.6. Управление проблемами
Под проблемой в проекте понимается любой функциональный, технический или свя- занный с бизнесом вопрос, который возник в процессе осуществления проекта и требует ответа – изучения и решения для того, чтобы проект мог идти так, как запланировано.
Другими словами – проблема, это исключительные обстоятельства, которые должны быть под контролем (то есть, управляемы) с момента их возникновения.
Обычно проблемы делят на две категории – на проблемы, которые могут быть решены в месте возникновения, то есть на уровне управления проектом – problems, и возрастаю- щие проблемы – issues, которые для их разрешения требуется поднять на верхние уровни управления, в том числе, внешние по отношению к проекту.
В управлении рисками должна быть отражена формальная сторона управления про- блемами:

164 1. Процедуры, регламентирующие основные этапы работы с проблемами – выявление проблемы, мониторинг и анализ проблемы, принятие решения и его исполнение, закры- тие проблемы.
2. Шаблоны документов, отражающих процесс работы с проблемами – карточка про- блемы, журнал проблем проекта и т.д.
Для анализа проблем могут разрабатываться специальные таблицы решений. Напри- мер, для определения такой важнейшей характеристики проблемы, как приоритетность ее решения, может использоваться матрица приоритетов, приведенная в табл. 8.3.
Таблица 8.3
Матрица приоритетов решения проблем
Срочность.
Влияние на проект
Несрочная
Первоочередная
Неотложная
Слабое Вряд ли приведет к нарушению ка- лендарного плана, бюджета или ухудшению качества продукта
Несущественная
Незначительная
Важная
Среднее Возможно нарушение календарно- го плана, увеличение стоимости или ухуд- шение качества продукта
Незначительная
Важная
Особо важная
Сильное Возможно значительное наруше- ние календарного плана, увеличение стои- мости или ухудшение качества продукта
Важная
Особо важная
Особо важная
Особо важные проблемы – требуют немедленного решения с привлечением всех не- обходимых ресурсов.
Важные проблемы – требуют срочного решения с привлечением всех доступных ре- сурсов.
Незначительные проблемы – требуют решения в рамках имеющихся ресурсов без ущерба для остальных работ по проекту.
Несущественные проблемы – никакие действия по решению проблемы не предприни- маются до изменения ее приоритета.
8.7. Управление изменениями
Изменение в проекте – это модификация ранее согласованных продуктов и услуг, сро- ков исполнения и стоимости работ, управленческих и технологических процессов и т.п.
В качестве традиционных мероприятий по изменениям ресурсов, используемых в про- екте, применяются, например, увеличение интенсивности работ, материальное стимули- рование, замена или привлечение дополнительных исполнителей и субподрядчиков. С точки зрения тяжести последствий изменения могут быть классифицированы, например, следующим образом:
1. Плановые потери (учтены в плане управления проектом).
2. Допустимые потери (незначительные незапланированные затраты).
3. Нежелательные потери (значительные незапланированные затраты).
4. Недопустимые потери (незапланированные затраты, которые являются неприемле- мыми для одного или нескольких участников проекта).
Для каждого проекта изначально может быть определена степень влияния тех или иных изменений на величину вероятных потерь, возникающих при реализации этих из- менений. Эта информация (рис. 8.5) представлена в виде диаграммы, в которой измене- ния связаны с областями потерь.

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

166
Рис. 8.6. Стратегии изменений в проекте
8.8. Управление взаимодействием в проекте
Управление взаимодействием – определение потоков информации и способов взаи- модействия, необходимых для участников проекта;
Управление практически любым современным проектом — это во многом управление взаимодействием [6]. Взаимодействием заказчика и исполнителя, члена проектной ко- манды и руководителя проекта, руководителя проекта и руководителя функционального подразделения (в организациях с матричной структурой), сотрудников заказчика между собой и т.д.
Рассмотрим типовую ситуацию в проекте программной разработки: исполнитель на- чал работы, подготовил ТЗ, заказчик его утвердил, программисты начали работы, к мо- менту сдачи работ выясняется, что сделанное не соответствует ожиданиям заказчика.
Причина этого несоответствия заключается прежде всего в том, что команда исполни- теля на продолжительное время «удалилась» в процесс реализации, а заказчик находится в неведении, что происходит, как идут дела, как учитываются его, заказчика, важные по- желания и мысли. В конце концов, ни одна система не может быть описана в ТЗ так, как ожидает заказчик, и сделана так, как написано в ТЗ. Поэтому важность взаимодействия заинтересованных лиц на всем протяжении проекта нельзя недооценивать. Как правило, хорошим интервалом для отчетности в проекте служит календарная неделя. Руководи- тель проекта должен еженедельно информировать всех участников о состоянии дел, про- блемах, рисках, основных событиях, выполненных и невыполненных (да-да, не надо это- го бояться!) работах. Информирование всех сторон всегда ведет к положительным трен- дам в решении возникающих проблем проекта (а проекта без проблем не бывает!). Такое информирование, как правило, осуществляется путем рассылки текстовых отчетов, шаб- лон которых есть в организации-исполнителе и утвержден главным руководящим доку- ментом проекта — Уставом.
Раз уж речь зашла об Уставе проекта, следует сказать несколько слов о его роли. В нашей практике Устав — основной рабочий документ проекта, отвечающий на вопросы:
Желательная стратегия
Возможные стратегии
субподрядчиков увеличение интенсивности работ