Вовремя и в рамках бюджета - Лоуренс Лич

Последовательность ключевых событий — это инструмент, позволяющий перейти от иерархической картины ИСР к логическому плану проекта. Это генеральная линия движения работ, которой будут пользоваться менеджеры, чтобы понимать значение входов и выходов своих рабочих заданий (пакетов работ). (Эта составляющая не раскрывается в руководстве РМВОК, но будет описана в следующей главе.)

4.4.2.4. Пакеты работ

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

4.4.2.5. Сетевая диаграмма проекта

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

4.4.3. ОЦЕНКА И КОНТРОЛЬ ВЫПОЛНЕНИЯ ПРОЕКТА

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

Матрица соответствий также определяет потребность в процессе непрерывного совершенствования и обеспечения качества итогового продукта проекта. В задачи данной книги не входит подробное рассмотрение процесса обеспечения качества продукта. Описание такого процесса дает Льюис Айланд [8].

4.4.4. УПРАВЛЕНИЕ ИЗМЕНЕНИЯМИ В ПРОЕКТЕ

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

4.4.5. УПРАВЛЕНИЕ РИСКАМИ В ПРОЕКТЕ

Управление рисками направлено на особые причины потенциальной вариабельности. Поскольку в РМВОК не проводится разграничения между общими и особыми причинами отклонений, вы увидите, что работа с вариабельностью обоих типов идет в рамках управления рисками. ССРМ строит управление проектом с учетом общих причин вариабельности, а особые причины остаются на долю управления рисками (смотрите главу 10).

4.5. Итоги

В этой главе мы рассмотрели требования к системе управления проектом и увидели, какие элементы ССРМ и РМВОК обеспечивают соответствие этим требованиям. Основные свойства получившейся системы следующие:

• критическая цепь показывает ограничение проекта;

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

• для максимального использования возможностей критической цепи исполнитель должен знать, над каким следующим заданием он будет работать. Этого можно достичь, создавая списки приоритетов работ, графики работ для определенного исполнителя или «оповестительные флаги»13;

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

• в ССРМ для контроля выполнения в первую очередь используют управление с помощью буферов;

• чтобы система управления проектом соответствовала всем необходимым требованиям, нужно использовать ряд параметров, описанных в РМВОК.

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

ЛИТЕРАТУРА

1. Juran, Joseph J., Juran on Planning for Quality, New York: The Free Press, 1988.

2. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1979 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

3. Shewhart, Walter A., Statistical Method from the Viewpoint of Quality Control, New York: Dover Publications, 1986 (впервые опубликовано в 1939 году).

4. Kiley, Martin D., 1997 National Construction Estimator, Carlsbad, CA, Craftsman Book Company, 1996.

5. Moore, David S., George P. McCabe, Introduction to the Practice of Statistics, New York: W.H.Freeman & Co., 1993, р. 398.

6. Meredith, Jack R., Samuel J. Mantel, Project Management, A Managerial Approach, New York: John Wiley and Sons, Inc., 1995.

7. Goldratt, Eliyahu M., The Haystack Syndrome, Croton-on-Hudson, NY: North River Press, 1990.

8. Ireland, Lewis R. Quality Management for Projects and Programs, Upper Darby, PA: PMI, 1991.

Глава 5. Запуск нового проекта

5.1. Процесс инициации проекта

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

Рис. 5.1 дает общее представление о процессе успешного запуска проекта. Начинается все с устава — это необходимая составляющая любого проекта, хотя часто ею пренебрегают. Завершением процесса является план управления проектом, по которому уже можно начинать работы.

РМВОК [1] разделяет процессы инициации и процессы планирования. В данной главе мы оба типа процессов рассматриваем как части процесса запуска-инициации проекта. При таком подходе результатами на выходе процесса будут устав проекта, назначение менеджера проекта, описание ограничений, исходных установок и допущений, а также другие компоненты полного плана управления проектом, включая график работ и бюджет.

5.2. Устав проекта

Устав проекта — краткое письменное заявление о запуске проекта, дающее основание для создания соответствующей проектной команды и начала планирования. Это определение намного шире приведенного в РМВОК и предполагает также, что в устав включаются ответы на шесть вопросов, необходимых для создания плана проекта, — кто делает, что делает, когда, где, как и зачем. Как правило, в уставе должны быть освещены все перечисленные ниже пункты, обозначенные авторами из CH2MHILL [2] как обязательные: