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

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

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

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

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

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

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

• диаграмма проекта — представленная в максимально простой форме для успешного выполнения работ;

• правильно составленная логическая последовательность работ с указанием необходимых ресурсов — нужна для разработки расписания проекта;

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

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

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

• процесс управления изменениями (необходим в большинстве проектов);

• этап завершения проекта как часть плана проекта.

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

1. PMI, A Guide to the Project Management Body of Knowledge, 2000 Edition Newton Square, PA: PMI, 2000 (в русском переводе: Руководство к своду знаний по управлению проектами/Под. ред. В. Либерзона, Д. Лобанова. — М.: Институт управления проектами, 2004. — редакция 2000 года; Руководство к своду знаний по управлению проектами. — Project Management Institute, 2004. — редакция 2004 года).

2. CH2MHILL, Project Delivery System: A System and Process for Benchmark Performance, Denver, CO: CH2MHILL, 1996.

3. Goldratt, Eliyahu M., It’s not Luck, Great Barrington, MA: North River Press, 1994 (в русском переводе: Голдратт Э. М., Кокс Д. Цель. Процесс непрерывного улучшения. Цель-2. Дело не в везенье. — Киев—Москва: Максимум, Логос, 2007).

4. Dettmer, H. William, Eliyahu M. Goldratt’s Theory of Constraints, A Systems Approach to Continuous Improvement, Milwaukee, Wisconsin: ASQC Press, 1997 (в русском переводе: Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию. — М.: Альпина Бизнес Букс, 2007).

5. PMI. Practice Standard for Work Breakdown Structures. Newton Square, PA: PMI, 2001.

6. U.S. Department of Defense, DoD Handbook — Work Breakdown Structures. MIL-HDBK-881, 1998, доступна по адресу http://dcarc.pae.osd.mil/881handbook/ milhdbk 881_cover_chap1.pdf (материал для книги взят 24 мая 2004 года).

7. Kerzner, Harold, Project Management, A Systems Approach to Planning, Scheduling, and Controlling, 4th ed., New York: Van Norstrand, 1992.

8. Kiley, Martin D. and Marques Allyn, 1997 National Construction Estimator, Carlsbad, CA, Craftsman Book Company, 1997.

9. Leach, L. “Schedule and Cost Buffer Sizing: How to Account for the Bias between Project Performance and Your Model,” Project Management Journal, Vol. 34, No. 2, June 2003.

10. Vidger M.R., and A.W. Kark, “Software Cost Estimation and Control,” NRC-CNRC (National Research Council Canada), NRC No. 37166, February 1994.

Глава 6. Создание плана отдельного проекта по методу критической цепи

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

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

Далее мы раскроем основные этапы процесса создания графика проекта методом критической цепи. Процедура написана для работы «вручную», без использования программ для построения критических цепей. Эти правила успешно применялись руководителями отдельных проектов с бюджетом до $5 млн — для планирования и управления по ССРМ. Для управления более крупными проектами или программами необходимо специализированное программное обеспечение, работающее на алгоритме критической цепи.

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

1. Найдите критическую цепь.

1.1. Постройте логическую последовательность операций со связями типа «поздний финиш». Используйте среднюю длительность операций (вероятность 50/50) и укажите исходные данные о необходимых ресурсах. (Если для выполнения задачи требуется несколько исполнителей, укажите, кто, по вашему мнению, будет основным ограничением работ. Если таковых несколько, разбейте задачу в соответствии с количеством исполнителей-ограничений.)

1.2. Если в вашем проекте нет проблем с ресурсами (конфликта ресурсов), переходите к шагу 1.6.

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

1.4. Устраните конфликт ресурсов, запланировав выполнение некоторых операций на более ранний срок. (На данном этапе не задумывайтесь о появлении новых конфликтов; вы снимете их позже.)

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