Home > Менеджмент, Финансы > Управление рисками

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

August 18th, 2013
  • Анализ риска
  • Доля бюджета посвященная управлению рисками
  • Топ-10 Список Рисков
  • Пример плана управления рисками
  • Планирование риска
  • Схема управления

Анализ риска

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

спецификаций – найти потенциальные проблемы на ранних стадиях

Анализ этапа Проблема, ожидание (вероятность), воздействие, серьезность – принять существование проблем и их значение
Реализация резервного плана Планируйте заранее потенциальные проблемы

Пример Топ 10 Список Рисков

На этой нед. На прошлой нед. Недель в Списке Риск Прогресс разрешения рисков
1 1 5 Переменные требований Прототип интерфейса используется для сбора высоких требований к качеству.

Техническое задание было создано под четким контролем изменений.

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

2 5 5 Требования или озолочення разработчика Видение определяет, что не включено в программное обеспечение.

Дизайн делает акцент на минимализме.

Отзывы имеют контрольный список пунктов для проверки “дополнительного дизайна или внедрения”

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

Технические осмотры проводятся по всем требованиям, дизайн и код.

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

Система тестируется независимыми тестерами.

4 7 5 Недостижи

мый график

Проект позволяет избежать принятия графика обязательств до завершения формирования технического задания.

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

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

5 4 2 Нестабильность инстру

ментов задержки графика

Новыми являются только один или два инструмента, которые используются на этом проекте, остальные были использованы на предыдущих проектах.
6 1 Высокая текучесть Проектное видение поощряет разработчиков покупать доли в компании.

Активное, детальное планирование проекта создает четкие ожидания.

Периодические оценки способствуют пересмотренным планам учитывать изменения в сфере без массовых просрочек.

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

7 3 5 Трения между разработчи

ками и заказчиками

  • Прототип интерфейса выравнивает видение разработчиков и клиентов на одинаковый детальный уровень.

Поэтапные поставки обеспечивают клиента свидетельством  неуклонности процесса

8 6 5 Непродукти

вные офисние помещения

Will move development to off-site environment with private offices after completing user interface prototype.

  • Тем не менее существует необходимость утверждения бюджета для проведения проекта за пределы существующей площадки.

План управления рисками для “Переменных требований”

Почему? Наш анализ показал, что выход за границы требований на проектах составляет около 40%. Нам нужно контролировать  переменные требования чтобы избежать неконтролируемого  увеличения затрат и времени на проекте.
Как? В целом, мы должны искать способы устранять  источник  изменения  требований  путем  первостепенного  сбора требований. Дальше, мы должны разрешать только  те изменения, которых нельзя избежать.
Что? Мы реагируем на риски тремя определенными способами:

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

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

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

Мы переводим риск в высший разряд при следующих обстоятельствах:

•   Мы не можем заставить пользователей  принять прототип интерфейса в резонный срок.

•   Мы получаем просьбы об изменении требований, составляющие более 5% системы в первые 30 дней после того, как требования были спланированы.

•   Мы фактически принимаем изменения требований  составляющие более 5% системы в любой точке жизненного цикла проекта.

Кто? Тех. лид (технический руководитель) отвечает за прототип интерфейса пользователя.

Орган управления изменениями по проекту отвечает за  удержание требований под контролем над изменениями.

Менеджер проекта отвечает за краткость стадий в рамках  нашего поэтапного плана поставки.

Оценка стоимостей

  1. Планирование ресурсов (Resource Planning)
  2. Оценка стоимостей (Cost Estimating)
  3. Разработка бюджета (Cost Budgeting)
  4. Управление стоимостью проекта (Project Cost Management)

Планирование ресурсов

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

  • Перечень операций.
  • Потребности операций в ресурсах.
  • Объемы работ на операциях.
  • Производительности ресурсов.

Определение длительности операцій

Оценка длительности операций или объемов работ – оценка количества рабочих временных интервалов или объемов работ, необходимых для завершения отдельных операций.

Необходимая информация

  • Перечень операций.
  • Объемы работ на операциях.
  • Потребности операций в ресурсах.
  • Производительности ресурсов.

Методы определения длительности операций:

  • Экспертный.
  • По аналогам.
  • Нормативы.
  • Моделирование

Оценка стоимости

Определение стоимости операций проекта и разработка бюджета.

Необходимая информация

  • Перечень операций.
  • Оценки длительности операций.
  • Объемы работ на операциях.
  • Перечень используемых ресурсов.
  • Стоимость ресурсов.

Методики расчета стоимости

  • Входящие параметры:
  • WBS
  • Ресурсы
  • Расчет деятельности
  • Исторические данные
  • Риски по проекту
  • Типы расчетов
  • Aналогичные проекты
  • Параметрическое моделирование
  • Расчет снизу-вверх
  • Компьютерное моделирование

Менеджмент, Финансы , ,

Comments are closed.