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

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

• 
  Ресурсы и усилия могут быть распределены между проектами в соответствии с возникающими в них рисками.
  
• 
  Каждый, кто осуществляет управление рисками на уровне проекта, имеет внешнюю высшую инстанциювозможность эскалации своих вопросов, способную предоставить свое мнение о сделанных проектной группой оценкахи получения “внешнего” для проекта мнения о его рисках.
  
• 
  Используя опыт коллег, Ппроектные группы могут быстрее самосовершенствоваться свой опыт, используя внешние источники.
  
• 
  Для каждого проекта осуществляется Кконтроль процесса управления рисками производится в рамках каждого из проектов.
  

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

• 
  ОбеспечьтеЗаручитесь поддержкуподдержкой исполнительного руководства компании. процесса анализа портфеля исполнительными действиями. Поддерживайте их рРегулярной отчетностьюпредоставляйте “наверх” отчеты о новых данных и извлеченных уроках, полученных в процессе анализа рисков портфеля проектовданных и извлеченных уроках.
  
• 
  Планируйте собрания заблаговременно. В идеале, планируйте их регулярно в такие дни, когда смогут присутствовать многиебольшинство руководителируководителей проектов смогут присутствовать. Заблаговременно приглашайте аналитическую группу – хорошие аналитики имеют много других обязанностей.
  
• 
  Тщательно выбирайте проекты, представляемые на анализ. Вы можете исходить из ежемесячного графика анализа больших проектов, но нужно также обеспечьтеобеспечить регулярный анализ широкого спектра проектов средней величины.
  
• 
  Устанавливайте фиксированный круг вопросов, рассматриваемый по каждому из проектов., Ттаким образом чтобы руководители проектов будут знализнать, чегочто ожидать от проводимых собраний. Например, 20 минут выделяется на доклад о текущих оценках рисков, затем 20 минут идет обсуждение стратегий по предотвращению и смягчению последствий, а затем делается 5-ти минутный обзор извлеченных уроков для обмена опытом с другими проектными группами.
  
• 
  Используйте стандартизированную документацию для отчетности об оценке рисков и их состоянии.
  
• 
  Убедитесь, что все документы розданы всем участникам собрания заблаговременно. Это позволит сократить трату времени.
  
• 
  ПригласитеСтимулируйте напосещение аналитических собраниесовещаний руководителейями проектныхвнутрипроектных групп – либо в личной беседе, либо по телефону (т.н. “селекторное” совещание).
  
• 
  Убедитесь, что проводимые встречи приносят проектным группам пользу. Часто это может быть достигнуто анализом прогресса в тех вопросах, которые, в узком понимании, не являются рисками, но где опыт аналитической группы способен помочь проектной группе.
  
• 
  Избегайте персональных порицаний за сложившуюся в проектуе ситуацию.
  
• 
  Позволяйте всякомукаждому члену проектной команды сделать прошениезаявку о рассмотрении их проекта.
  

Заключение

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

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

Данный обзор носит чисто информативный характер. КОРПОРАЦИЯ МАЙКРОСОФТ НЕ ПРЕДОСТАВЛЯЕТ НИКАКИХ ГАРАНТИЙ, НИ ЯВНО ВЫРАЖЕННЫХ, НИ ПОДРАЗУМЕВАЕМЫХ В СВЯЗИ С ДАННЫМ ДОКУМЕНТОМ.

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

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

© Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены.Результаты и уроки, извлеченные из плановых мероприятий по смягчению последствий, включаются затем в отчет о ходе выполнения планов и их результатах. Таким образом, эта информация становится частью базы знаний проекта и предприятия о рисках. При этом необходимо охватить как можно больше информации о возникающих проблемах и о плане в целом, когда требуется определить его эффективность

It is important to capture as much information as is possible about problems when they incur or about a contingency plan when it is invoked to determine the efficacy of such a plan or strategy on risk control.

Microsoft является охраняемым товарным знаком корпорации Майкрософт в США и других странах.

Названия компаний или продуктов, указанные здесь, могут быть товарными знаками соответствующих владельцев.Часть номер: 602-i401a

Перевод данного документа на русский язык был осуществлен в 2003 г. корпорацией eLine Software (http://www.elinesoftware.com). Другие документы по MSF на русском языке доступны в Internet по адресу: http://www.microsoft.com/rus/msf .

1 MSF Process Model v. 3.0, 2002 (доступно наavailable at http://www.microsoft.com/msf/)

2 Audrey J. Dorofee, Julie A. Walker, Christopher J Alberts et al, Continuous Risk Management Guidebook (Carnegie-Mellon University, 1996).

3 Ronald P. Higuera, “Team Risk Management: A New Model for Customer-Supplier Relationships”, SEI Technical Report CMU/ SEI-94-SR-5, (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University), 1994.

4 Encarta 2002, Статья “Insurance. II. Reasons for Insurance”.

5 Jim McCarthy, Dynamics of Software Development (Redmond, Washington: Microsoft Press, 1995), page 99.

6 Восемь принципов – это:

1. 
   1. ожидайте изменений – проявляйте гибкость (expect things to change – stay agile);.
   
2. 
   2. вырабатывайте общее видение (work toward a shared vision).;
   
3. 
   3. концентрируйтесь на бизнес-ценностях (focus on delivering business value throughout the life cycle).;
   
4. 
   4. инвестируйте в качество (invest in quality).;
   
5. 
   5. извлекайте уроки из любого опыта – и положительного, и отрицательного (learn from all experiences – good and bad).;
   
6. 
   6. поощряйте открытое общение (foster open communication).;
   
7. 
   7. распределенная ответственность, фиксированная отчетность (clear accountability, shared responsibility).;
   
8. 
   8. компетентная команда, наделенная полномочиями (empowered team).
   

7 MSF Team Model 3.0 Whitepaper (http://www.microsoft.com/msf/).

8 См. более детальное рассмотрение в MSF 3.0 Process Model Whitepaper, доступно наavailable at http://www.microsoft.com/msf/

9 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report CMU/SEI-96-TR-012 ESC-96-012 (Pittsburgh, PA: Software Engineering Institute—Carnegie Mellon University, 1996).

10 К примеру, Steve McConnell, Software Project Survival Guide, (Redmond, WA: Microsoft Press), 1998.

11 Barry W. Boehm, Software Risk Management, (New York, NY: IEEE Press), 1989.

12 Capers Jones, Assessment and Control of Software Risks. (Englewood, NJ: Prentice-Hall, 1994). ISBN 0-13-741406-4

13 Ronald P. Higuera and Yacov Y. Haimes, “Software Risk Management”, SEI Technical Report, 1996.

14 Steve McConnell, Rapid Development, (Redmond, Microsoft Press), 1996, pp 87-91.

15 Thomas R. Peltier, Information Security Risk Analysis, (Boca Raton: Auerbach Publications, 2001).

16 Donald L Pipkin, Information Security: Protecting the Global Enterprise, (Newark, NJ: Prentice Hall, 2000).

17 http://seir.sei.cmu.edu/

18 Одна из эффективных методик мозгового штурма для обнаружения первопричины называется “Пять почему”. Согласно этому подходу, команда должна поставить вопрос “Почему это так?” по отношению к условию риска, дать ответ и циклически повторить “Почему это так? - Потому что ...” до пяти раз.

19 Это может быть достигнуто вариацией методики “5 почему”, при которой команда циклически повторяет вопрос-ответ “Что тогда?..Тогда будет...” до пяти раз.

20 Audrey J Dorofee, Julie A Walker, Christopher J Alberts, et al., Continuous Risk Management Guidebook. (Pittsburgh, PA: Carnegie Mellon University, 1996).

21 Linda H Rosenberg , Theodore Hammer , Albert Gallo, Continuous Risk Management at NASA, 1999 (http://satc.gsfc.nasa.gov/support/ASM_FEB99/crm_at_nasa.html)

22 MSF Risk Management Process Whitepaper, 2001.

23 Principles of Application Development- Course 593 and Course 1517.

24 Rosenberg LH, et al., 1999.

25 Elaine Hall, Managing Risk. Methods for Software Systems Development, SEI Series in Software Engineering, (Reading, MA: Addison-Wesley, 1998), Ch. 4, “Identify Risk”.

26 Dorfee AJ, et al, 1996.

27 Elaine Hall, Managing Risk, p. 101.

28 Project Management Institute, A Guide to the Project Management Body of Knowledge 2000 Edition, (Newtown Square, PA: Project Management Institute, Inc. 2000), Chapter 11.

29 Elaine Hall, Managing Risk.

30 См. MSF 3.0 Project Management Discipline, доступно на: http://www.microsoft.com/msf/

31

~~

жүктеу/скачать 1.02 Mb.

Достарыңызбен бөлісу: