Главная Промышленная автоматика.

Анализ вероятности успеха

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

i Название 1 Начале

Мримс-р

I Задача 1 Задача 2 Задача 3

Затраты

СОПТЙМИСГК

I ч«скйе)

ililioEliiis 14.05.2Ш 2з отэ.юе

03,03.2003 09.04.2003 10 909.097

09,04.2003 16,05.2003 6 333,333

.03.03.2003 09.04.2003 6 666.675

Пример -

Тренды

вероятно

сгей

усгшха

Затраты 25800 Затраты 24000 О«1тчанйе14.05 2ВВЗ

1001

20 i

Май 2

Э 11017124

7 14 21 28

<

>

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

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

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

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

АНАЛИЗ ВЫПОЛНЕННОЙ СТОИМОСТИ

Результаты применения анализа выполненной стоимости (освоенных объемов) (EVA) к проекту, взятому в качестве примера, приведены в табл. П.б.

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

Таблица П.б. Тренды, полученные для примера проекта

в результате анализа выполненной стоимости

Параметр 03.03.03 10.03.03 17.03.03

Дата

24.03.03 31.03.03 07.04.03 14.04.03 21.04.03 28.04.03

3200

6400

9600

12800

16000

18109,1

19309,1

20509,1

21709,1

3280

6560

9840

13120

16400

18480

19560

20640

21720

3200

6400

9600

12800

16000

19200

20400

21600

22800

370,89

250,89

130,89

10,89

-720

-840

-960

-1080

CPI, %

102,5

102,5

102,5

102,5

102,5

102,05

101,3

100,64

100,05

SPI, %

102,5

102,5

102,5

102,5

102,5

96,25

95,88

95,56

95,26



ПРАКТИЧЕСКОЕ ПРИМЕНЕНИЕ МЕТОДОВ ИНФОРМАЦИОННОЙ ИНТЕГРАЦИИ ДЛЯ ДОСТИЖЕНИЯ УПРАВЛЕНИЯ ПРОЕКТАМИ, «ВЕДОМОГО УСПЕХОМ"

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

• в целях оценивания рисков и управления ими использовать диапазоны оценок (оптимистическую, наиболее вероятную, пессимистическую) для длительностей и объемов операций, производительности и количества ресурсов, стоимости операций и ресурсов, календарей. Оценки обычно основываются не только на суждениях экспертов, но и на регуляторных (нормативных) или корпоративных нормах. Такие описываемые диапазоном оценки позволяют создавать и анализировать оптимистические, наиболее вероятные и пессимистические расписания/бюджеты с учетом ограниченности ресурсов и допустимых затрат;

• в ходе переговоров оперировать вероятностями успеха для того, чтобы утвердить реалистичные целевые даты завершения и бюджеты. Определять приемлемые реалистичные целевые даты и бюджеты, отражающие разумные значения вероятности успеха, и достигать соглашения и взаимопонимания с лицами (органами), имеющими полномочия утверждать эти даты, бюджеты и вероятности;

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

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

Название

Flpmtep

Задача 1 Задача 2 Задача 3

Окхжчахие

буфер

\сть

тчвт

Затраты ! Затраты jSeiXj твчестае)! шныЩ I сть

29.е4.»03 14.05.2003 72.1

04,04.2003 29,04,2003 i 31 03 2003

3.0 20 000.0 25 000.0; Ш.7

23,0:10 000,0; 7,2 5 000,0 3,0 5 000.0


Рисунок П.7. Исходные данные для проекта, выбранного в качестве примера

СРАВНЕНИЕ ИНТЕГРАЛЬНОГО МЕТОДА С МЕТОДОМ КРИТИЧЕСКОЙ ЦЕПОЧКИ

у вышеописанного интегрального метода и метода критической цепочки [42] много общего:

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

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

- планировать повседневные операции, используя оптимистические оценки, однако при этом уделять особое внимание временным резервам по ресурсам и страховым резервам;

- включать информацию о причинах задержки выполнения операций и перерасходов в отчеты об исполнении проекта;

- регулярно обновлять и анализировать оценки по оптимистическому, наиболее вероятному и пессимистическому расписаниям;

- регулярно пересчитьшать вероятности успеха и анализировать их тренды;

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



Литература

1. А Guide to the Project Management Body of Knowledge. Newtown Square, PA: Project Management Institute, 2000.

2. APM-BoK Project Management Body of Knowledge, 4th ed. High Wycombe, U.K.: Association for Project Management, 2000. ISBN 1-903494-00-1. См. также British Standard BS607 9-1:2000. Project Management - Part 1: Guide to Project Management. British Standards Institute, U.K. ISBN 0-580-25594-8.

3. Archibald, Russell D.; Harpham Alan. Project Managers Profiles and Certification Workshop Report / Proceedings of the 14th International Expert Seminar, Zurich, Switzerland: International Project Management Association (IPMA), March 15-17, 1990.

4. Archibald, Russell D.; Villoria, Richard L. Network-Based Management Systems (PERT/CPM). New York: Wiley, 1967.

5. Belanger, Thomas C. Choosing a Project Life Cycle / Field Guide to Project Management, edited by David I. Cleland. - New York: Wiley, 1998, pp. 61-73.

6. Block, Thomas R. The Project Office Phenomenon PM Network (March 1998).

7. Boznak, Rudolph G. "Master Business Planning - The Art of Controlling Project Management in a Multi-Project Environment" / Proceedings of the Project Management Institute Seminar Symposium. - Newtown Square, PA: Project Management Institute, October 1987, pp. 143-158.

8. Bridges, Dianne N.; Crawford, J. Kent. How to Start Up and Rollout a Project Office / Proceedings of the Project Management Institute Annual Seminars & Symposium. - Newtown Square, PA: Project Management Institute, September 7-16, 2000.

• "буферы подпитки" в методе критической цепочки подобны "резервам по ресурсам" в интегральном методе;

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

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

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





0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 [70] 71 72 73

0.0033