Файл: Управление рисками проекта.pdf

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

Количественная оценка рисков

Рисунок 2. Количественная оценка рисков.^[2]

Количественная оценка рисков определяет вероятность возникновения рисков и влияние последствий рисков на проект, что помогает группе управления проектами верно принимать решения и избегать неопределенностей.

Количественная оценка рисков позволяет определять:

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

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

Мониторинг и контроль

Рисунок 3. Мониторинг и контроль^[3]

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

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

Глава 2. Анализ управления рисками проекта на примере создания проекта в технической сфере.

2.1. Краткая характеристика проекта

Реализуется технический проект, целью которого является создание новой видеокарты. Проект называется «GTX999».

Задачами проекта являются:

• Создание производительной видеокарты средне ценового сегмента.
• Укрепиться на рынке.

Целевой аудиторией являются пользователи программ по 3D-моделированию, видеомонтажу, растровой/векторной графике.

Результаты проекта подразделяются на промежуточные и конечные и представлены ниже в таблице (табл. 1)

Таблица 1^[4]

Результаты проекта

Требования к проекту:

1.Наличие DVA, VGA, HDMI, Display Port портов.

2.Наличие активного охлаждения (2 кулера 140мм)

3.Минимальный объем памяти 4Гб

4.Максимальное разрешение 4096 × 3072

5.Наличие дополнительного питания

Ограничения проекта:

1.Время (1 месяц)

2.Бюджет

Для реализации проекта необходимо выполнить следующие этапы:

1) Создание идеи

2) Составление бизнес-плана

3) Поиск инвесторов

4) Заключения договора с инвестором

5) Поиск команды для управления проектом (менеджеры по управлению проектом)

6) Поиск технической команды

7) Поиск инженерной команды

8) Поиск маркетинговой команды

9) Заключение трудового договора с командой управления проектом

10) Заключение трудового договора с технической командой

11) Заключение трудового договора с инженерной командой

12) Заключение трудового договора с маркетинговой командой

13) Поиск и аренда помещения под производство

14) Поиск и закупка необходимого оборудования для создания

15) Оборудование помещения

16) Создание опытного образца видеокарты технической и инженерной командой

17) Тестирование

18) Создание технической документации

19) Начало массового производства

20) Вывод на рынок

В таблице ниже представлены фазы проекта (табл. 2.)

Таблица 2^[5]

Фазы проекта

Построение иерархической структуры работ (ИСР) на основе этапов проекта представлено ниже (рис. 4).

Рисунок 4. Иерархическая структура работ проект (ИСР)^[6]

Для реализации проекта была выбрана функциональная организационная структура (рис 5)

Рисунок5.Организационная структура проекта^[7]

Ниже в таблице представлен реестр заинтересованных сторон (таблица 3.)

Таблица 3^[8]

Реестр заинтересованных сторон

К критериям успешности проекта можно отнести:

1)Качество:

• Реализованы все возможности.
• Эти возможности реализованы с надлежащим качеством.

2)Время:

• Старт проекта реализован вовремя.
• Этапы проекта реализованы вовремя.

3)Бюджет:

• Проект уложился в планируемый бюджет.
• Оправдать желания инвестора (стоимость, сроки и т.д.).

Этапы проекта:

A-Создание идеи

B-Составление бизнес-плана

C-Поиск инвесторов

D-Заключения договора с инвестором

E-Поиск команды для управления проектом

F-Поиск технической команды

G-Поиск инженерной команды

H-Поиск маркетинговой команды

I-Заключение трудового договора с командой управления проектом

J-Заключение трудового договора с технической командой

K-Заключение трудового договора с инженерной командой

L-Заключение трудового договора с маркетинговой командой

M-Поиск и аренда помещения под производство

N-Поиск и закупка необходимого оборудования для создания

O-Оборудование помещения

P-Создание опытного образца видеокарты технической и инженерной командой

Q-Тестирование

R-Создание технической документации

S-Начало массового производства

T-Вывод на рынок.

Состав работ и их продолжительность представлены ниже (таблица 4).

Таблица 4^[9]

Состав работ и их продолжительность

Сетевая модель вида «Работа-Вершина» строится по предоставленным данным в таблице 2. Она представлена на стр. 22 (рис. 1).

Рисунок 6. Сетевая модель вида «Работа-Вершина»^[10]

Рисунок 7. Сетевая модель вида «Работа-Дуга»^[11]

Календарный план проекта строится на основании сетевой модели «Работа-Вершина». Он представлен ниже (рис. 3).

Рисунок 8. Календарный план проекта

Реализация проекта будет длиться 24 дня. Критический путь проекта проходит через работы: B; C; D; M; N; O; P; Q; R; S; T и длится 24 дня (выделен красным цветом на сетевой модели «Работа-Вершина»). Так же некоторые работы имеют резервные дни, а именно: A, E, F, G, H, I, J, K, L.

2.2. Описание управления рисками проекта

План управления рисками — это компонент плана управления проектом, описывающий, каким образом действия по управлению рисками будут структурироваться и выполняться. План управления рисками включает в себя следующие элементы:

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

Роли и сферы ответственности. Определение руководящих членов команды, поддерживающих членов команды, а также членов команды, отвечающих за управление рисками, для каждого вида действий, включенных в план управления рисками, и разъяснение их сфер ответственности.

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

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

Категории рисков. Предоставляют средства для распределения потенциальных источников риска по группам. Могут быть использованы несколько подходов, например, структура, основанная на целях проекта по категориям. Иерархическая структура рисков (RBS) помогает команде проекта рассмотреть множество источников, из которых могут проистекать риски проекта, во время выполнения процедуры идентификации рисков. Различным типам проектов соответствуют различные структуры RBS. Организация может использовать разработанную заранее схему категоризации рисков, которая может принимать форму простого списка категорий или оформляться в виде RBS. RBS — это иерархическое представление рисков согласно категориям рисков.