Финансы
<<  Система управления рисками в ФТС РФ Управление рисками проекта  >>
Пример характеристик риска
Пример характеристик риска
Пример иерархической структуры рисков проекта
Пример иерархической структуры рисков проекта
Ранг риска и матрица вероятностей и последствий
Ранг риска и матрица вероятностей и последствий
Пример карточки с описанием риска
Пример карточки с описанием риска
Влияние факторов профессионализма разработчиков ПО на трудозатраты по
Влияние факторов профессионализма разработчиков ПО на трудозатраты по
Пример анализ дерева решений при выборе покупать или производить
Пример анализ дерева решений при выборе покупать или производить
5 основных факторов риска программного проекта, учитываемых в модели
5 основных факторов риска программного проекта, учитываемых в модели
Гистограмма распределения возможного срока завершения проекта,
Гистограмма распределения возможного срока завершения проекта,
Неопределенность не уменьшается, если управление не направлено на
Неопределенность не уменьшается, если управление не направлено на
Определение приоритетов требований на первые итерации проекта
Определение приоритетов требований на первые итерации проекта
Управление, нацеленное на снижение рисков, позволяет уменьшать
Управление, нацеленное на снижение рисков, позволяет уменьшать
Картинки из презентации «Управление рисками проекта» к уроку экономики на тему «Финансы»

Автор: Простаков И.Е.. Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока экономики, скачайте бесплатно презентацию «Управление рисками проекта.pptx» со всеми картинками в zip-архиве размером 1685 КБ.

Управление рисками проекта

содержание презентации «Управление рисками проекта.pptx»
Сл Текст Сл Текст
1Управление рисками проекта. В силу 34Пример карточки с описанием риска.
специфики отрасли, программная инженерия Результатом качественного анализа рисков
остается и, в ближайшем будущем, будет является их подробное описание: Результаты
оставаться производством с высоким уровнем качественного анализа используются в ходе
рисков. Если задуматься, то все, что мы последующего количественного анализа
делаем, управляя проектом разработки ПО, рисков и планирования реагирования на
направлено на борьбу с рисками не риски.
уложиться в срок, перерасходовать ресурсы, 35Количественный анализ рисков.
разработать не тот продукт, который Количественный анализ производится в
требуется. Риск (отрицательный) – это отношении тех рисков, которые в процессе
проблема, которая еще не возникла, а качественного анализа были квалифицированы
проблема – это риск, который как имеющие высокий и средний ранг. Для
материализовался. количественного анализа рисков могут быть
2Управление рисками проекта. Риск использованы следующие методы: Анализ
характеризуется следующими чувствительности. Анализ дерева решений.
характеристиками: Причина или источник. Моделирование и имитация.
Явление, обстоятельство обусловливающее 36Анализ чувствительности. Анализ
наступление риска. Симптомы риска, чувствительности помогает определить,
указание на то, что событие риска какие риски обладают наибольшим
произошло или вот-вот произойдет. потенциальным влиянием на проект. В
Первопричина нам может быть не наблюдаема, процессе анализа устанавливается, в какой
например, заразились гриппом. Мы наблюдаем степени неопределенность каждого элемента
некоторые симптомы – поднялась проекта отражается на исследуемой цели
температура. Последствия риска. Проблема проекта, если остальные неопределенные
или возможность, которая может элементы принимают базовые значения.
реализоваться в проекте в результате Результаты представляются, как правило, в
произошедшего риска. Влияние риска. виде диаграммы «торнадо». Рисунок 4
Влияние реализовавшегося риска на представляет пример такой диаграммы,
возможность достижения целей проекта. которая отражает влияние на проектные
Воздействие обычно касается стоимости, трудозатраты различных факторов
графика и технических характеристик профессионализма разработчиков ПО.
разрабатываемого продукта. Многие риски 37Влияние факторов профессионализма
происходят частично и оказывают разработчиков ПО на трудозатраты по
соразмерное отрицательное или проекту.
положительное воздействие на проект. 38Анализ дерева решений. Анализ
3Пример характеристик риска. последствий возможных решений проводится
4Управление рисками проекта. Риск это на основе изучения диаграммы дерева
всегда вероятность и последствия. решений, которая описывает рассматриваемую
Например, всегда есть вероятность того, ситуацию с учетом каждой из имеющихся
что метеорит упадет на офис центра возможностей выбора и возможного сценария.
программных разработок, и это будет иметь Рисунок 5 представляет пример диаграммы
катастрофические последствия для проекта. дерева решений на дугах которой
Однако вероятность наступления этого проставлены вероятности и затраты при
события настолько мала, что мы в развитии событий по тому или иному
большинстве проектов принимаем это риск и сценарию. Критерием для принятия решения
не пытаемся им управлять. Принято выделять служит математическое ожидание потерь от
две категории рисков: «Известные его принятия.
неизвестные». Это те риски, которые можно 39Пример анализ дерева решений при
идентифицировать и подвергнуть анализу. В выборе покупать или производить
отношении таких рисков можно спланировать необходимую для проекта библиотеку
ответные действия. «Неизвестные визуальных компонентов (VCL).
неизвестные». Риски, которые невозможно 40Анализ дерева решений. При
идентифицировать и, следовательно, моделировании рисков проекта используется
спланировать ответные действия. модель для определения последствий от
5Управление рисками проекта. воздействия подробно описанных
Неизвестные риски это непредвиденные неопределенностей на результаты проекта в
обстоятельства. Единственное, что мы можем целом. Моделирование обычно проводится с
в этом случае предпринять, это создать помощью метода Монте-Карло. Интересный
управленческий резерв бюджета проекта на пример подобной модели - система Riskology
случай незапланированных, но потенциально от Демарко и Листера, который иллюстрирует
возможных изменений. На расходование этого применение метода Монте-Карло для
резерва менеджер проекта, как правило, получения информации о том, какой запас
обязан получать одобрение вышестоящего времени будет необходим для того, чтобы
руководства. Управленческие резервы на преодолеть влияние всех неуправляемых
непредвиденные обстоятельства не входят в рисков проект. Модель позволяет учесть
базовый план по стоимости проекта, но пять основных (Рисунок 6) и пять
включаются в бюджет проекта. Они не дополнительных рисков проекта.
распределяются по проекту, как бюджет, и 415 основных факторов риска программного
поэтому не учитываются при расчете проекта, учитываемых в модели riskology.
освоенного объема. 42Анализ дерева решений. Характеристики
6Управление рисками проекта. Девиз предопределенных в системе Riskology
разработчиков ПО из Microsoft:«Мы не рисков пользователь может изменить, задав
боремся с рисками — мы ими управляем». значения минимальной, максимальной и
Цели управления рисками проекта – снижение наиболее вероятной задержки сроков сдачи
вероятности возникновения и/или значимости проекта из-за влияния данного риска. Можно
воздействия неблагоприятных для проекта включить в модель дополнительные
событий. Адекватное управление рисками в собственные риски. Результат моделирования
компании – признак зрелости по методу Монте-Карло будет представлен в
производственных процессов. Том Демарко виде гистограммы распределения срока
пишет: «Рассматривать только благоприятные завершения оцениваемого проекта (Рисунок
сценарии и встраивать их в план проекта – 7).
настоящее ребячество. И все же мы 43Гистограмма распределения возможного
постоянно так поступаем. …Если тех, кто срока завершения проекта, рассчитанная по
говорит о возможных проблемах до открытия результатам моделирования методом
проекта, называют troublemakers, а тех, Монте-Карло.
кто сдает проект спустя 2 месяца после 44Планирование реагирования на риски.
обещанного срока, работая при этом по Планирование реагирования на риски – это
60-80 часов в неделю, – героями, то у вас процесс разработки путей и определения
плохая команда». действий по увеличению возможностей и
7Планирование управления рисками. снижению угроз для целей проекта. Данный
Управление рисками это определенная процесс начинается после проведения
деятельность, которая выполняется в качественного и количественного анализа
проекте от его начала до завершения. Как и рисков. Запланированные операции по
любая другая работа в проекте управление реагированию на риски должны
рисками требует времени и затрат ресурсов. соответствовать серьезности риска, быть
Поэтому эта работа обязательно должна экономически эффективными в решении
планироваться. Планирование управления проблемы, своевременными, реалистичными в
рисками – это процесс определения подходов контексте проекта и согласованными со
и планирования операций по управлению всеми участниками.
рисками проекта. Тщательное и подробное 45Планирование реагирования на риски.
планирование управления рисками позволяет: Возможны четыре метода реагирования на
выделить достаточное количество времени и риски: Уклонение от риска (risk
ресурсов для выполнения операций по avoidance). Передача риска (risk
управлению рисками, определить общие transference). Снижение рисков (risk
основания для оценки рисков, повысить mitigation). Принятие риска (risk
вероятность успешного достижения acceptance).
результатов проекта. 46Уклонение от риска. Уклонение от риска
8Планирование управления рисками. предполагает изменение плана управления
Планирование управления рисками должен проектом таким образом, чтобы исключить
быть завершено на ранней стадии угрозу, вызванную негативным риском,
планирования проекта, поскольку оно крайне оградить цели проекта от последствий риска
важно для успешного выполнения других или ослабить цели, находящиеся под угрозой
процессов. Исходными данными для (например, уменьшить содержание проекта).
планирования управления рисками служат: Некоторые риски, возникающие на ранних
Отношение к риску и готовность к риску стадиях проекта, можно избежать при помощи
организаций и лиц, участвующих в проекте, уточнения требований, получения
оказывает влияние на план управления дополнительной информации или проведения
проектом. Оно должно быть зафиксировано в экспертизы. Например, уклониться от риска
изложении основных принципов и подходов к можно, если отказаться от реализации
управлению рисками. Стандарты организации. рискованного функционального требования
Организации могут иметь заранее или самостоятельно разработать необходимый
разработанные подходы к управлению программный компонент, вместо ожидания
рисками, например категории рисков, общие поставок продукта от субподрядчика.
определение понятий и терминов, 47Передача риска. Передача риска
стандартные шаблоны, схемы распределения подразумевает переложение негативных
ролей и ответственности, а также последствий угрозы с ответственностью за
определенные уровни полномочий для реагирование на риск на третью сторону.
принятия решений. Передача риска просто переносит
9Планирование управления рисками. ответственность за его управление другой
Описание содержания проекта подробно стороне, но риск при этом никуда не
описывает результаты поставки проекта и исчезает. Передача риска практически
работы, необходимые для создания этих всегда предполагает выплату премии за риск
результатов поставки. План управления стороне, принимающей на себя риск.
проектом, формальный документ, в котором Например, заказ на стороне разработки
указано, как будет исполняться проект и рискованного компонента по фиксированной
как будет происходить мониторинг и цене. В IT часто приходится формулировать
управление проектом. риски в виде допущений, тем самым
10Планирование управления рисками. План передавая его заказчику. Например,
управления рисками обычно включает в себя оценивая проект внедрения, мы можем
следующие элементы: Определение подходов, записать допущение о том, что
инструментов и источников данных, которые производитель не изменит стоимость
могут использоваться для управления лицензий на базовое ПО.
рисками в данном проекте. Распределение 48Снижение рисков. Снижение рисков
ролей и ответственности. Список позиций предполагает понижение вероятности и/или
выполнения, поддержки и управления рисками последствий негативного рискованного
для каждого вида операций, включенных в события до приемлемых пределов. Принятие
план управления рисками, назначение предупредительных мер по снижению
сотрудников на эти позиции и разъяснение вероятности наступления риска или его
их ответственности. Выделение ресурсов и последствий часто оказываются более
оценка стоимости мероприятий, необходимых эффективными, нежели усилия по устранению
для управления рисками. Эти данные негативных последствий, предпринимаемые
включаются в базовый план по стоимости после наступления события риска.
проекта. 49Снижение рисков. Например, раннее
11Планирование управления рисками. разрешение архитектурных рисков снижает
Определение сроков и частоты выполнения потери при досрочном закрытии проекта.
процесса управления рисками на протяжении регулярная ревизия поставок заказчиком
всего жизненного цикла проекта, а также может снизить вероятность риска его
определение операций по управлению неудовлетворенности конечным результатом.
рисками, которые необходимо включить в Если в проектной команде высока
расписание проекта. Категории рисков. вероятность увольнения сотрудников, то
Структура, на основании которой введение на начальной стадии в проект
производится систематическая и дополнительных (избыточных) людских
всесторонняя идентификация рисков с нужной ресурсов снижает потери при увольнении
степенью детализации. Такую структуру членов команды, поскольку не будет затрат
можно разработать с помощью составления на «въезд» в проектный контекст новых
иерархической структуры рисков (Рисунок участников.
2). Общие подходы для определения уровней 50Принятие рисков. И, наконец, принятие
вероятности, шкалы воздействия и близости риска означает, что команда проекта
рисков на проект. осознанно приняла решение не изменять план
12Пример иерархической структуры рисков управления проектом в связи с риском или
проекта. не нашла подходящей стратегии
13Планирование управления рисками. Шкала реагирования. Мы вынуждены принимать все
оценки воздействия отражает значимость «неизвестные риски». Принятие это то, что
риска (Таблица 1) в случае его всегда происходит, когда мы вообще не
возникновения. Шкала оценки воздействия управляем рисками. Если же мы управляем
может различаться в зависимости от рисками, то мы можем страховать риски,
потенциально затронутой риском цели, типа закладывая резерв в оценки срока
и размера проекта, принятыми в организации завершения и/или трудозатрат. Проактивное
стратегиями и его финансовым состоянием, а отношение к принятым рискам может состоять
также от чувствительности организации к в разработке плана реагирования на риски.
конкретному виду воздействий Таблица 1. Этот план может быть введен в действие
Пример шкалы оценки воздействия рисков. только при заранее определенных условиях,
Вес. Значение. Критерий. 3. если есть уверенность и достаточное
Катастрофические. Потери более 400K. 2. количество признаков того, что данный план
Критичные. Потери от 40K до 400K. 1. будет успешно выполнен.
Умеренные. Потери менее 40K. 51Главные риски программных проектов и
14Планирование управления рисками. Хотя способы реагирования. Список из пяти
риск может воздействовать и на сроки главных причин провала программных
проекта, и на качество получаемого проектов - следующий: Требования заказчика
продукта, но все эти отклонения могут быть отсутствуют (не полны) подвержены частым
оценены в денежном эквиваленте. Например, изменениям. Отсутствие необходимых
последствия задержка по срокам для ресурсов и опыта. Отсутствие рабочего
заказной разработки может быть выражена в взаимодействия с заказчиком. Неполнота
сумме денежных санкций, определенных в планирования. «Забытые работы». Ошибки в
контракте. Похожая шкала может быть оценках трудоемкостей и сроков работ.
применена для оценки вероятности Приходится сталкиваться с программными
наступления риска (Таблица 2). Таблица 2. проектами, в которых отсутствуют
Пример шкалы оценки вероятности какие-либо определенные цели и требования.
осуществления риска. Вес. Значение. Цитата из жизни: «Была бы разработана
Критерий. 3. Очень вероятно. Шансы хорошая программа, а какой процесс
наступления весьма велики. 2. Возможно. автоматизировать с ее помощью, мы найдем».
Шансы равны. 1. Мало вероятно. Наступление К этому можно добавить только одно: «Когда
события весьма сомнительно. человек не знает, к какой пристани он
15Планирование управления рисками. Еще держит путь, для него никакой ветер не
одной важной характеристикой риска будет попутным» (Сенека Луций Аней,
является близость его наступления. философ, 65-3 до н.э.).
Естественно, что при прочих равных 52Главные риски программных проектов и
условиях рискам, которые могут способы реагирования. К часто упускаемым
осуществиться уже завтра, следует сегодня требованиям можно отнести: Функциональные
уделять больше внимания, чем тем, которые Программы установки, настройки,
могут произойти не ранее, чем через конфигурации. Миграция данных. Интерфейсы
полгода. Для шкалы оценки близости риска с внешними системами. Справочная система.
может быть применена, например, следующая Общесистемные Производительность.
градация: очень скоро, не очень скоро, Надежность. Открытость. Масштабируемость.
очень нескоро. Безопасность. Кросплатформенность.
16Идентификация рисков. Идентификация Эргономичность.
рисков – это выявление рисков, способных 53Как правило, эти требования
повлиять на проект, и документальное «всплывают» при подготовке и проведении
оформление их характеристик. Это приемо-сдаточных испытаний и могут сильно
итеративный процесс, который периодически задержать проект по времени и увеличить
повторяется на всем протяжении проекта, трудозатраты на его реализацию. Чтобы
поскольку в рамках его жизненного цикла этого не происходило, следует достигать
могут обнаруживаться новые риски. Исходные соглашения с заказчиком по всем
данные для выявления и описания перечисленным пунктам предпочтительнее еще
характеристик рисков могут браться из на стадии инициации проекта. Например,
разных источников. В первую очередь это если требования портируемости продукта на
база знаний организации. Информация о разные аппаратно-программные платформы
выполнении прежних проектов может быть нет, то это целесообразно включить в
доступна в архивах предыдущих проектов. раздел концепции с допущениями проекта.
Следует помнить, что проблемы завершенных Главные риски программных проектов и
и выполняемых проектов, это, как правило, способы реагирования.
риски в новых проектах. 54Если вероятность изменений требований
17Идентификация рисков. Другим проекта высока, то возможны следующие
источником данных о рисках проекта может подходы для реагирования на данный риск:
служить разнообразная информация из Переоценка проекта каждый раз, когда
открытых источников, научных работ, требования добавляются / изменяются
маркетинговая аналитика и другие (уклонение). Итерационная разработка.
исследовательские работы в данной области. Контракт с компенсацией затрат на основе
Наконец, многие форумы по программированию «Time & Materials» (передача риска
могут дать бесценную информацию о Заказчику). Учет в оценках трудоемкости и
возникших ранее проблемах в похожих сроков возможности роста требований,
проектах. Каждый проект задумывается и например, на 50% (резервирование риска).
разрабатывается на основании ряда гипотез, Изменение требований.
сценариев и допущений. Как правило, в 55И еще, при сборе требований следует
описании содержания проекта перечисляются соблюдать принцип минимализма Вольтера:
принятые допущения - факторы, которые для «Рассказ закончен не тогда, когда в него
целей планирования считаются верными, нечего добавить, а тогда, когда из него
реальными или определенными без нечего больше выкинуть». Для большинства
привлечения доказательств. программных продуктов применим принцип
18Идентификация рисков. Неопределенность Парето: 80% ценности продукта заключены
в допущениях проекта следует также лишь в 20% требований к нему. Анализ
обязательно рассматривать в качестве требований.
потенциального источника возникновения 56Если у нас в проекте недостаточно
рисков проекта. Анализ допущения позволяет квалифицированных специалистов, то мы
идентифицировать риски проекта, можем снизить последствия этого риска,
происходящие от неточности, применив следующие действия: Привлечь
несовместимости или неполноты допущений. экспертов-консультантов на начальных
Для сбора информации о рисках могут этапах. Учитывать в оценках трудоемкости
применяться различные подходы. Среди этих издержки на обучение сотрудников.
подходов наиболее распространены: Опрос Уменьшать потери от текучести кадров,
экспертов Мозговой штурм Метод Дельфи привлекая на начальном этапе избыточное
Карточки Кроуфорда. число участников. Учесть в оценках «время
19Опросы. Цель опроса экспертов – разгона» для новых сотрудников.
идентифицировать и оценить риски путем Квалифицированные специалисты.
интервью подходящих квалифицированных 57Для установления открытых и
специалистов. Специалисты высказывают свое доверительных отношений с заказчиком,
мнение о рисках и дают им оценку, исходя необходимо предпринимать следующие шаги:
из своих знаний, опыта и имеющейся Постоянное взаимодействие. Согласование
информации. Этот метод может помочь пользовательских интерфейсов и разработка
избежать повторного наступления на одни и прототипа продукта. Периодические поставки
те же грабли. Перед опросом эксперт должен тестовых версий конечным пользователям для
получить всю необходимую вводную их оценки. Отношения с заказчиком.
информацию. Деятельность экспертов 58При планировании работ по проекту
необходимо направлять, задавая вопросы. Во часто «забывают»: Обучение Координацию
время опроса вся информация, выдаваемая работ Уточнение требований Управление
экспертом, должна записываться и конфигурациями Разработку и поддержку
сохраняться. При работе с несколькими скриптов автосборки Разработка автотестов
экспертами выходная информация обобщается Создание тестовых данных Обработка
и доводится до сведения всех запросов на изменения. Главные риски
задействованных экспертов. программных проектов и способы
20Мозговой штурм. К участию в мозговом реагирования.
штурме привлекаются квалифицированные 59Главные риски программных проектов и
специалисты, которым дают «домашнее способы реагирования. Не стоит надеяться,
задание» - подготовить свои суждения по что участники проекта будут каждую неделю
определенной категории рисков. Затем по 40 часов работать именно над вашим
проводится общее собрание, на котором проектом. Есть множество причин, по
специалисты по очереди высказывают свои которым они не смогут работать по проекту
мнения о рисках. Важно: споры и замечания 100% своего времени. К списку наиболее
не допускаются. Все риски записываются, распространенных причин этого относятся:
группируются по типам и характеристикам, Сопровождение действующих систем Повышение
каждому риску дается определение. Цель – квалификации Участие в подготовке
составить первичный перечень возможных технико-коммерческих предложений Участие в
рисков для последующего отбора и анализа. презентациях Административная работа
21Метод Дельфи. Метод Дельфи во многом Отпуска, праздники, больничные
похож на метод мозгового штурма. Однако Рекомендация, планировать, что
есть важные отличия. Во-первых, при разработчики, которые назначены в ваш
применении этого метода эксперты участвуют проект на 100% будут реально работать над
в опросе анонимно. Поэтому результат вашими задачами в среднем от 24 до 32
характеризуется меньшей субъективностью, часов в неделю.
меньшей предвзятостью и меньшим влиянием 60На стадии инициации проекта оценка его
отдельных экспертов. Во-вторых, опрос трудоемкости имеет погрешность от -50% до
экспертов проводится в несколько этапов. +100%. Это, если оценка хорошая! А если
На каждом этапе модератор рассылает плохая, то неопределенность, а,
анкеты, собирает и обрабатывает ответы. следовательно, и риски сорвать сроки и
Результаты опроса рассылаются экспертам превысить плановую трудоемкость, могут
снова для уточнения их мнений и оценок. быть в разы больше. Если не прилагать
Такой подход позволяет достичь некоего специальных усилий этот «дамоклов меч»
общего мнения специалистов о рисках. неопределенности будет висеть над проектом
22Карточки Кроуфорда. Для быстрого на всем его протяжении (Рисунок 8).
выявления рисков можно воспользоваться еще Проектом следует управлять так, чтобы
одной из методик социометрии является риски несвоевременной сдачи и перерасхода
известной как "Карточки Кроуфорда». ресурсов постоянно снижались. Управление
Суть этой методики в следующем. Собирается проектом, направленное на снижение рисков.
группа экспертов 7-10 человек. Каждому 61Неопределенность не уменьшается, если
участнику мини-исследования раздается по управление не направлено на раннее
десять карточек (для этого вполне подойдет разрешение рисков.
обычная бумага для записок). Ведущий 6280% ценности разработки обусловлена
задает вопрос: "Какой риск является лишь 20% требований к продукту, без
наиболее важным в этом проекте?" Все реализации которых продукт для заказчика
респонденты должны записать наиболее, по становится просто ненужным. Остальные
их мнению, важный риск в данном проекте. требования, как правило, так называемые
При этом никакого обмена мнениями не «украшательства», от части которых
должно быть. Ведущий делает небольшую заказчик, как правило, может отказаться,
паузу, после чего вопрос повторяется. чтобы получить проект в срок. Поэтому
Участник не может повторять в ответе один следует в первую очередь реализовывать
и тот же риск. ключевые функциональные требования .
23Карточки Кроуфорда. После того как Управление проектом, направленное на
вопрос прозвучит десять раз, в снижение рисков.
распоряжении ведущего появятся от 70 до 63Но есть и еще архитектурные риски.
100 карточек с ответами. Если группа Известно, что закон Парето применим и к
подобрана хорошо (в том смысле, что в нее потреблению вычислительных ресурсов: 80%
входят люди с различными точками зрения), потребления ресурсов (время и память)
вероятность того, что участники приходится на 20% компонентов. Поэтому,
эксперимента укажут большинство значимых необходимо реализовывать
для проекта рисков, весьма высока. архитектурно-значимые требования так же в
Остается составить список названных рисков первую очередь, создавая
и раздать его участникам для внесения «представительный» прототип будущей
изменений и дополнений. системы, который охватывает весь спектр,
24Источники информации о рисках. В применяемых технологий. Прототип позволит
качестве источника информации при измерить и оценить общесистемные свойства
выявлении рисков могут служить различные будущего продукта: доступность,
доступные контрольные списки рисков быстродействие, надежность,
проектов разработки ПО, которые следует масштабируемость и проч. (Рисунок 9)
проанализировать на применимость к данному Ошибка - реализовывать сначала легкие
конкретному проекту. Например, Барри Боэм требования, чтобы продемонстрировать
приводит список 10 наиболее быстрый прогресс проекта. Управление
распространенных рисков программного проектом, направленное на снижение рисков.
проекта: Дефицит специалистов. 64Определение приоритетов требований на
Нереалистичные сроки и бюджет. Реализация первые итерации проекта.
несоответствующей функциональности. 65Управление, нацеленное на снижение
Разработка неправильного пользовательского рисков, позволяет уменьшать
интерфейса. «Золотая сервировка», неопределенность.
перфекционизм, ненужная оптимизация и 66Проработка ключевых функциональных
оттачивание деталей. требований и детальное планирование их
25Источники информации о рисках. реализации позволяет уменьшить разброс
Непрекращающийся поток изменений. Нехватка начальных оценок, примерно, в 2 раза: от
информации о внешних компонентах, -30% до +50%. Детальное проектирование и
определяющих окружение системы или разработка прототипа будущей системы
вовлеченных в интеграцию. Недостатки в позволит получить еще более точные оценки
работах, выполняемых внешними (по общей трудоемкости: от -10% до +15%. Может
отношению к проекту) ресурсами. оказаться так, что по результатам
Недостаточная производительность прототипирования, уточненные оценки
получаемой системы. «Разрыв» в суммарной трудоемкости окажутся
квалификации специалистов разных областей неприемлемыми. В этом случае проект
знаний. придется закрыть досрочно, но потери при
26Источники информации о рисках. Демарко этом, будут значительно меньше, чем в
и Листер приводят свой список из пяти случае, если то же самое произойдет, когда
наиболее важных источников рисков любого проект уже в 2 раза превысит
проекта разработки ПО: Изъяны календарного первоначальную оценку трудоемкости.
планирования Текучесть кадров Раздувание Управление проектом, направленное на
требований Нарушение спецификаций Низкая снижение рисков.
производительность. 67Если с заказчиком не удается найти
27Источники информации о рисках. Не взаимоприемлемое решение при
существует исчерпывающих контрольных первоначальной оценке проекта, то разумно
списков рисков программного проекта, попытаться договориться о выполнении
поэтому необходимо внимательно проекта в 2 этапа с самостоятельным
анализировать особенности каждого финансированием: Исследование.
конкретного проекта. Результатом Бизнес-анализ, уточнение требований,
идентификации рисков должен стать список проектирование и прототипироание решения,
рисков с описанием их основных уточнение суммарных оценок трудозатрат.
характеристик: причины, условия, Эта работа, как правило, требует 10% общих
последствий и ущерба. Если вернуться к трудозатрат и 20% времени всего проекта.
примеру проекта создания Непосредственно реализация. Если
«Автоматизированной системы продажи уточненные оценки трудозатрат окажутся
документации», то список главных приемлемыми для заказчика. С вменяемыми
выявленных рисков может выглядеть заказчиками это часто удается. Управление
следующим образом: проектом, направленное на снижение рисков.
28Список рисков проекта создания 68Управление рисками должно
«Автоматизированной системы продажи осуществляться на протяжении всего
документации». проекта. Мониторинг и управление рисками –
29Качественный анализ рисков. это процесс идентификации, анализа и
Качественный анализ рисков включает в себя планирования реагирования на новые риски,
расстановку рангов для идентифицированных отслеживания ранее идентифицированных
рисков. При анализе вероятности и влияния рисков, а также проверки и исполнения
предполагается, что никаких мер по операций реагирования на риски и оценка
предупреждению рисков не производится. эффективности этих операций. В процессе
Качественный анализ рисков включает: мониторинга и управления рисками
Определение вероятности реализации рисков. используются различные методики, например,
Определение тяжести последствий реализации анализ трендов и отклонений, для
рисков. Определения ранга риска по матрице выполнения которых необходимы
«вероятность - последствия». Определение количественные данные об исполнении,
близости наступления риска. Оценка собранные в процессе выполнения проекта.
качества использованной информации. Мониторинг и контроль рисков.
30Качественный анализ рисков. Для 69Мониторинг и управления рисками
качественной оценки вероятности реализации включает в себя следующие задачи:
риска и определения тяжести последствий Пересмотр рисков Аудит рисков Анализ
его реализации применяется, как правило, отклонений и трендов Пересмотр рисков
общепринятые в организации шкалы, примеры должен проводиться регулярно, согласно
которых мы приводили ранее. Для расписанию. Управление рисками проекта
определения ранга риска используется должно быть одним из пунктов повестки дня
матрица вероятностей и последствий всех совещаний команды проекта. Неплохо
(Рисунок 3). Ранг риска определяется начинать каждый статус митинг с вопроса:
произведением веса вероятности и «Ну и какие еще неприятности нас ожидают?»
значимости последствий. Продолжая Идентификация новых рисков, и пересмотр
рассмотрение примера проекта создания известных рисков происходит с
«Автоматизированной системы продажи использованием процессов, описанных ранее.
документации», матрица рангов главных Мониторинг и контроль рисков.
выявленных рисков может выглядеть 70Аудит рисков предполагает изучение и
следующим образом (Таблица 3). предоставление в документальном виде
31Качественный анализ рисков. Причина. результатов оценки эффективности
Вероятность. Воздействие. Ранг. Требования мероприятий по реагированию на риски,
не ясны. Очень вероятно. Катастрофические. относящихся к идентифицированным рискам,
9. Недостаток квалифицированных кадров. изучение основных причин их возникновения,
Очень вероятно. Критичные. 6. Текучесть а также оценку эффективности процесса
кадров. Возможно. Критичные. 4. управления рисками. Аудит рисков.
32Ранг риска и матрица вероятностей и 71Анализ отклонений и трендов. Тренды в
последствий. процессе выполнения проекта подлежат
33Качественный анализ рисков. Для оценки проверке с использованием данных о
рисков необходима точная и адекватная выполнении. Для мониторинга выполнения
информация. Использование неточной всего проекта могут использоваться анализ
информации ведет к ошибкам в оценке. освоенного объема и другие методы анализа
Неверная оценка риска также является отклонений проекта и трендов. На основании
риском. Критерии оценки качества выходов этих анализов можно прогнозировать
используемой при анализе информации потенциальные отклонения проекта на момент
выглядят следующим образом: Степень его завершения по показателям стоимости и
понимания риска. Доступность и полнота расписания. Отклонения от базового плана
информации о риске. Надежность, могут указывать на последствия, вызванные
целостность и достоверность источников как угрозами, так и благоприятными
данных. возможностями.
Управление рисками проекта.pptx
http://900igr.net/kartinka/ekonomika/upravlenie-riskami-proekta-136236.html
cсылка на страницу

Управление рисками проекта

другие презентации на тему «Управление рисками проекта»

«Стратегические разработки» - Эффективность. Внешнее окружение. Цели и задачи прог- раммы. Паспорта программ. Паспорт целевой программы. Механизм оценки результатов.Пример. Аналитические отчеты. Если процесс поиска не проводился, укажите причины. Мероприятие. Обоснование необходимости ЦП. Утверждение Думой, включение в Стратегический план.

«Стили управления» - Первого среди равных. Пророка, провидца. Обеспечивать профессиональный рост своих подчиненных. Отеческий стиль. Климат организации. Наставнический стиль. Принуждающий или диктаторский Авторитетный Отеческий Демократический Эталонный Наставнический. Стиль управления и климат в организации. Пример для подражания.

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

«Подросток в обществе риска» - 1. Шум. 5. Приобщение к курению Период приобщения к курению совпадает с периодом приобщения к пиву: с 4-го по 9-й класс включительно. 4. Раннее сексуальное развитие. 3.Отрицательные последствия просмотров телепрограмм. 6. Подростковая наркомания. Подросток в обществе риска. 2. Подростковый алкоголизм.

«Система управление проектами» - Контроль исполнения проектов. Порядок контроля … Отчёт об отклонениях. Функции Проектного офиса ВУЗа. Проблемы проектов. Рабочие места в соответствии с ролями. Основной элемент системы управления портфелем проектов. Куратор проекта. Срыв сроков. Ланит, 2008. Информационная подсистема. Программные средства управления проектами.

«Управление рисками» - Собрания, посвященные планированию. Коррекция. Milestone Review. Вопросы для самоконтроля. Шаг 5: Корректирование ситуации. eXtreme Programming. Сравнение PMBOK и MSF. Получили. Классификация и причины рисков. Выявление. Принятие решений в условиях неопределенности всегда связано с рисками. Microsoft Solution Framework.

Финансы

16 презентаций о финансах
Урок

Экономика

125 тем
Картинки
900igr.net > Презентации по экономике > Финансы > Управление рисками проекта