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

Организации, осуществляющие много проектов, могут значительно выиграть от процесса управления рисками, охватывающего весь портфель проектов. Выгода обычно состоит в следующем:

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

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

· Используя опыт коллег, проектные группы могут быстрее самосовершенствоваться.

· Для каждого проекта осуществляется контроль процесса управления рисками.

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

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

Ниже приводятся рекомендации по управлению рисками портфеля проектов:

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

· Планируйте собрания заблаговременно. В идеале, планируйте их регулярно в такие дни, когда смогут присутствовать большинство руководителей проектов. Заблаговременно приглашайте аналитическую группу – хорошие аналитики имеют много других обязанностей.

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

· Устанавливайте фиксированный круг вопросов, рассматриваемый по каждому из проектов. Таким образом руководители проектов будут знать, что ожидать от проводимых собраний. Например, 20 минут выделяется на доклад о текущих оценках рисков, затем 20 минут идет обсуждение стратегий по предотвращению и смягчению последствий, а затем делается 5-ти минутный обзор извлеченных уроков для обмена опытом с другими проектными группами.

· Используйте стандартизированную документацию отчетности.

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

· Стимулируйте посещение аналитических совещаний руководителями внутрипроектных групп – либо лично, либо по телефону (т.н. “селекторное” совещание).

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

· Избегайте персональных порицаний за сложившуюся в проекте ситуацию.

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

 

Заключение

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

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

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

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

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

механическими, включая фотокопирование и запись на магнитный носитель), если на то нет письменного разрешения корпорации Майкрософт.

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

© Корпорация Майкрософт (Microsoft Corp.), 2002. Все права защищены.

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

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

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

1 MSF Process Model v. 3.0, 2002 (доступно на 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. ожидайте изменений – проявляйте гибкость (expect things to change – stay agile);

2. вырабатывайте общее видение (work toward a shared vision);

3. концентрируйтесь на бизнес-ценностях (focus on delivering business value throughout the life cycle);

4. инвестируйте в качество (invest in quality);

5. извлекайте уроки из любого опыта – и положительного, и отрицательного (learn from all experiences – good and bad);

6. поощряйте открытое общение (foster open communication);

7. распределенная ответственность, фиксированная отчетность (clear accountability, shared responsibility);

8. команда, наделенная полномочиями (empowered team).

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

8 См. более детальное рассмотрение в MSF 3.0 Process Model Whitepaper, доступно на 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/

⇐ Предыдущая45678910111213

Поделиться: