Управление финансами
документы

1. Акт выполненных работ
2. Акт скрытых работ
3. Бизнес-план примеры
4. Дефектная ведомость
5. Договор аренды
6. Договор дарения
7. Договор займа
8. Договор комиссии
9. Договор контрактации
10. Договор купли продажи
11. Договор лицензированный
12. Договор мены
13. Договор поставки
14. Договор ренты
15. Договор строительного подряда
16. Договор цессии
17. Коммерческое предложение
Управление финансами
егэ ЕГЭ 2018    Психологические тесты Интересные тесты   Изменения 2017 Изменения 2017
папка Главная » Предпринимателю » Планирование рисков проекта

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

Риски проекта

Вернуться назад на Риски проекта

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

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

Далее мы производим сортировку рисков - группируем их по категориям, с учетом степени их значимости для проекта. Для этого можно использовать внешние источники для описания групп рисков. Так, например, в известной книге “Вальсируя с медведями” ДеМарко и Листера приводятся ТОР5 групп рисков для разработки ПО, сгруппированных по степени значимости.

Вот они:

1. Внутренние изъяны календарного планирования.
2. Изменение требований.
3. Текучесть кадров.
4. Нечеткие спецификации.
5. Низкая производительность.

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

Цель данного этапа состоит также и в том, чтобы отсеять риски, являющиеся малозначимыми для проекта. Например, землетрясение силой 8 баллов может уничтожить весь город, в котором ведется работа над проектом, но вероятность этого землетрясения – миллиардные доли процента, если речь идет о Москве. Также вероятно заболевание на неделю одного из тестеров, но нет смысла учитывать это на ранних этапах планирования – лучше объявить риск с названием “недоступность персонала” и включать туда все подобные риски.

При планировании рисков следует помнить, что это - не самоцель. Можно спланировать все возможные риски и потом тратить массу времени на их мониторинг, тогда как не будет хватать времени на остальное. Лучше установить для себя некоторый порог рисков по стоимости и регулярно отслеживать только те риски, которые выходят за это порог. Остальные, мелкие риски лучше писать в раздел "Прочее" и рассматривать этот раздел, скажем, раз в месяц.

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

Далее идет этап планирования реагирования на риски.

Мы можем реагировать на риски одним из четырех способов:

1. Уклонение от риска – предпринимаем корректирующие действия, чтобы риск не наступил вообще. Например, настаиваем на исключении из ТЗ спорного пункта, возможность успешной реализации которого сейчас не можем даже оценить.
2. Ослабление риска - предпринимаем корректирующие действия, чтобы наступивший риск имел возможно меньшее влияние. Типичный пример – фраза в ТЗ: “уточняется на этапе технического проекта”.
3. Передача риска – мы передаем риск другой стороне. Это не только покупка страховки. Запись о форс-мажорных обстоятельствах в договоре – пример бесплатного перекладывания рисков большой величины на заказчика.
4. Принятие риска – мы считаем, что с риском поделать ничего нельзя, поэтому просто закладываем резервы в бюджет и график для покрытия данного риска.

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

тема

документ Риски инвестиций
документ Риск в деятельности предпринимателя
документ Инвестирование
документ Инвестиционный проект
документ Инвестиции
документ Инвестиционная оценка



назад Назад | форум | вверх Вверх

Управление финансами
важное

Новое пособие на первого ребенка в 2018 году
Как получить квартиру от государства
Как получить земельный участок бесплатно
Потребительская корзина 2017
Налоговые изменения 2017
Повышение пенсий 2017
Материнский капитал 2017
Транспортный налог 2017
Налог на имущество 2017
Налог на прибыль 2017
ЕНВД 2017

Налог с продаж 2017
Налоги ИП 2017
УСН 2017
Изменения для юристов 2017
Земельный налог 2017
Кадровое делопроизводство 2017
НДФЛ 2017
Налоговый вычет 2017
Льготы 2017
Производственный календарь на 2017 год
Бухгалтерские изменения 2017
Расчет больничного 2017
Расчет отпускных 2017
ФСС 2017
Недвижимость


©2009-2018 Центр управления финансами. Все права защищены. Публикация материалов
разрешается с обязательным указанием ссылки на сайт. Контакты