Текст книги "Набор инструментов для управления проектами"

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

Формирование подробного списка результатов. Данный шаг требует проведения мозгового штурма для определения того, каковы должны быть результаты проекта. Каждый результат допустимо записать на бумажке с клейким слоем и прикрепить на видное место. Для малого или среднего проекта нормальной считается идентификация 40 – 60 результатов, в крупных проектах может потребоваться большее количество. Обратите внимание: в ходе мозгового штурма критика идей недопустима.

Группировка результатов. Итог этого шага – группировка взаимосвязанных результатов. Цель может состоять в создании групп, включающих в себя порядка пяти результатов. Необходимо тщательно исследовать их взаимоотношения и затем объединить в группы, стремясь к тому, чтобы в малых и средних проектах было три или четыре уровня группировки (в крупных возможно больше).

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

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

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

Подход «снизу вверх» хорош для новичков и при выполнении незнакомых проектов. Чтобы в полной мере оценить его потенциал, следует принять во внимание, что он обеспечивает легкий старт, позволяет добиться значительной сопричастности членов команды и решить терминологические проблемы. Простота использования дает ему преимущество перед подходом «сверху вниз», который требует большего времени для старта, разделяемого словаря и, кроме того, ограничивает сопричастность.

Время использования. Небольшая проектная команда, которая обладает надлежащими навыками и подготовкой, способна построить СДР, состоящую из трех уровней и включающую в себя 15 пакетов работ, в течение 30 – 60 минут. Необходимое время растет при увеличении СДР и численности команды.

Когда использовать. СДР первоначально применялась для того, чтобы упорядочить управленческую работу, требуемую в случае выполнения больших и сложных проектов правительственного сектора. Поэтому логично, что основные положения науки о СДР были сформулированы в правительственных организациях и очень хорошо освещены в известных книгах по управлению проектами [27]. Но далеко не столь хорошо рассмотрен вопрос адаптации этой науки к тем проектам, которые являются основными в сегодняшнем мире бизнеса, – к малым и средним. Для таких проектов СДР является одним из немногих обязательных инструментов. Будь то разработка аппаратного или программного обеспечения, маркетинг или бухгалтерский учет, производство или строительство, почти любая отрасль промышленности – малые и средние проекты нуждаются в СДР, способной соединить все их части. На самом деле можно достичь успеха и без СДР. Мы слышали о таких случаях. Однако, как показывает опыт, вероятность успешного выполнения проекта при помощи качественной СДР выше, чем при использовании СДР ненадлежащего качества или при ее отсутствии (см. врезку «Советы по использованию СДР»).

Выгоды. Ценность СДР трудно переоценить. И тому есть две причины: СДР помогает упорядочить необходимые работы и создает каркас для полной интеграции управления проектами. В частности, она дает проектной команде возможность организовать работы проекта в виде малых управляемых результатов, облегчая назначение ответственных за каждый из них. Поскольку результаты относительно независимы, их взаимодействие с другими результатами и взаимовлияние сведены к минимуму. При этом по мере продвижения к верхним уровням СДР их можно интегрировать, что позволяет команде увидеть целостную картину итогового продукта. Наконец, ход получения результатов поддается измерению. Эта чрезвычайно важная черта – способность организовывать работы проекта – приводит к появлению у СДР еще одного ценного свойства: она способна служить каркасом для интеграции функций планирования и контроля проекта. Именно поэтому некоторые специалисты считают СДР наиболее важным элементом управления проектами [23].

СОВЕТЫ ПО ИСПОЛЬЗОВАНИЮ СДР

• Разрабатывать СДР для любого проекта, малого или большого, беря за основу шаблон СДР.

• Принимать шаблон СДР для каждого семейства проектов.

• При создании шаблона начинать с небольшого числа уровней. Добавлять уровни только по просьбе команды.

• Разрешать малым проектам использовать меньшее количество уровней в шаблоне.

• Встраивать «пустые» элементы работ в шаблон СДР, чтобы они могли применяться в необычных проектах.

Основой значимости СДР является ее способность играть роль каркаса для планирования и контроля проекта, что обеспечивает надежное выполнение следующих основополагающих действий по управлению проектами (рис. 5.9):

• назначение лиц, ответственных за работы проекта;

• календарное планирование работ;

• оценивание затрат или ресурсов, необходимых для выполнения работ;

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

• измерение хода исполнения;

• управление работами, направленное на достижение целей проекта.

Объектом названных действий является элемент работ. В каждый элемент работ назначается лицо, которое отвечает за получение результатов, перечисленных под данным элементом. Например, если мы идентифицируем в СДР 20 элементов работ, то каждый из них должен иметь «владельца», ответственного за данный элемент, соблюдение его расписания, расходов, реагирование на риски, измерение хода исполнения и контроль проекта. Очень удобным инструментом для назначения ответственности является матрица ответственности, где по вертикали перечислены элементы работ, а по горизонтали – лица, вовлеченные в проект. В ячейках, расположенных на пересечениях строк с элементами работ и столбцов с именами лиц, обозначаются различные виды ответственности за исполнение того или иного элемента.

Второе действие, которое становится возможным при использовании СДР, – это календарное планирование элементов работ. В данном случае интеграция расписаний начинается на уровне пакета работ. В частности, как только расписание для каждого паке– та составлено, расписание для элемента работ следующего уровня превращается в сумму расписаний своих пакетов. Аналогично расписание для любого элемента работ более высокого уровня есть сумма расписаний составляющих его элементов проекта. Суммирование расписаний достигается благодаря иерархической структуре работ (см. рис. 5.9 и раздел «Иерархическое расписание» главы 6). Важно помнить, что каждый элемент работ может иметь только одно расписание. Тем практикующим специалистам, которые утверждают, что СДР статична и не показывает зависимости между своими элементами, следует вспомнить о том, что отражать зависимости – задача сетевого графика, а не СДР.

Помимо интеграции расписаний, СДР также предоставляет формальную структуру для оценивания ресурсов. Снова выполняется оценка потребностей пакетов работ в ресурсах, а их объединение выявляет общие ресурсные требования (как показано на рис. 5.9). Распределив ресурсы, необходимые для выполнения элемента работ, по затрачиваемому на это времени, вы получите привязанный к временной шкале план использования ресурсов[20]20
  Ресурсный план. – Прим. ред.


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

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

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

Окончательная цель измерения хода исполнения – упреждающий контроль проекта. Иными словами, когда мы знаем ход исполнения для каждого элемента работ и всего проекта в целом, мы можем оценить отклонение фактических значений от базового плана и готовы искать ответы на вопросы, важные для проактивного цикла управления проекта (см. врезку «Упреждайте события: пять вопросов проактивного цикла контроля проекта» в разделе «Линия исполнения» главы 12).

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

Преимущества и недостатки. Преимущества использования СДР обширны, мы перечислим лишь наиболее заметные их них:

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

• простота. Старая пословица гласит, что простота ведет к совершенству. И это справедливо в отношении СДР: обычно для того, чтобы участники проекта смогли читать и строить СДР, достаточно весьма небольшой подготовки.

Рис. 5.9. СДР как каркас для интеграции функций планирования и контроля проекта

Однако в некоторых ситуациях СДР может стать источником неприятностей:

• чрезмерно большая СДР требует слишком много времени, что сводит «на нет» производительность. Если СДР состоит из слишком большого количества уровней и пакетов работ, то ее использование в качестве каркаса для интеграции функций планирования и контроля проекта становится бессмысленным, времяемким и требующим больших затрат ресурсов.

Адаптация СДР. Обобщенная СДР, которую мы рассмотрели в данном разделе, поддерживает возможность адаптации, что позволяет подстроить ее к специфике конкретной компании и проекта. Далее рассказывается, как подстроить СДР к вашим нуждам, тем самым повысив ее ценность.

СДР – это дерево семейства проектов, которое обеспечивает иерархическое представление его результатов. Удобная в использовании и полезная применительно к любому проекту, СДР часто рассматривается как наиболее важный элемент управления проектами. Причина этого заключается в ее способности организовывать работы проекта и создавать каркас, на основе которого выполняется полная интеграция управления. Ключевые аспекты структурирования СДР приводятся во врезке «Проверка СДР».

ПРОВЕРКА СДР

Убедитесь, что СДР:

• основывается на исходной информации;

• включает в себя только результаты;

• представляет все работы проекта;

• содержит результаты, которые относительно независимы друг от друга;

• отражает интегральные усилия.

Четыре инструмента, рассмотренные в данной главе, применяются совместно, повышая ценность друг друга (см. итоговое сравнение). Они не конкурируют за внимание и время проектной команды. Причина существования устава – дать проекту жизнь путем авторизации ресурсов, основываясь на обязательствах функциональных отделов, а также официально представить его. Если рассуждать логически, то написание устава должно следовать за процедурой разумного планирования. Увы, в реальности это не всегда так. Подобное планирование должно опираться на SWOT-анализ, позволяющий выявить сильные стороны и разрывы в возможностях проекта и выработать стратегии закрытия разрывов. Далее с учетом результатов проведенного анализа необходимо составить описание содержания, где будет дано общее направление развития проекта, – пространство решений, в котором должна действовать проектная команда. А затем на основе содержания следует построить СДР, являющуюся базовым планом работ и каркасом для интеграции всех действий по управлению проектом.

1. Cleland, D. I. 1990 “Project Management, Strategic Design, and Implementation” Blue Ridge Summit, Pa.:TAB Books.

2. Smith, P. G. and D. G. Reinertsen 1991 “Developing Products in Half the Time” 1st ed. New York: Van Nostrand Reinhold.

3. Cleland, D. I. and W. R. King 1983 “Systems Analysis and Project Management” 3d ed. New York: McGraw – Hill.

4. Milosevic, D. 1990 “Case Study: Integrating the Owner’s and the Contractor’s Project Organization” Project Management Journal 21(4): 23 – 32.

5. Project Management Institute 2000 ”A Guide to the Project Management Body of Knowledge” Drexell Hill, Pa.: Project Management Institute.

6. Stevenson, W. J. 1993 ”Production and Operations Management” Boston: Irwin.

7. Katzenbach, J. R. and D. K. Smith 1993 ”The Wisdom of Teams” Boston: Harvard Business School Press.

8. Kerzner, H. 2000 ”Applied Project Management” New York: John Wiley & Sons.

9. Lock, D. 1990 ”Project Planner” Aldershot, U.K.: Gower Publishing.

10. Harrison, J. S. and С. Н. St. John 1998 ”Strategic Management of Organisations and Stakeholders” 2d ed. Cincinnati: South – Western College Publishing.

11. Liedecker, J. K. and A. V. Bruno 1984. Identifying and Using Critical Success Factors “Long Range Planning” 17(1): 23 – 32.

12. Handifield, R. B. 1994. Effects of Concurrent Engineering on Make – to – Order Products. “IEEE Transactions on Engineering Management” 41(4): 384 – 393.

13. Zirger, B. J. and J. L. Hartley 1996. The Effect of Acceleration Techniques on Product Development Time “IEEE Transactions on Engineering Management” 43 (2): 143 – 152.

14. Thomson, J. 1967 «Organizations in Action” New York: McGraw – Hill.

15. McDounough, E. F. I. and G. Barczak 1991. Speeding Up New Product Development: The Effects of Leadership Style and Source of Technology “Journal of Product Innovation Management” 8(3): 203 – 211.

16. Handifiled, R. B., et al. 1999. Involving Suppliers in New Product Development “California Management Review” 42(1): 59 – 82.

17. Wright, P., С. D. Pringle, and M. J. Kroll 1992 “Strategic Management” Boston: Allyn and Bacon.

18. Thompson, A. T. and A. J. Strickland 1995 “Crafting and Implementing Strategy” Boston: Irwin.

19. Frame, J. D. 1999 “Building Project Management Competence” San Francisco: Jossey – Bass.

20. Rosenau, M. D., С. Griffin, G., and N. Anschuetz 1996 “The PDMA Handbook of New Product Development” New York: John Wiley & Sons.

21. Cooper, R. G. 1993 “Winning at New Products” 2d ed. Reading, Mass.: Perseus Books.

22. Hammer, M. and J. Champy 1993 “Reengineering the Corporation” New York: Harper Business.

23. Kerzner, H. 2001 “Project Management: A Systems Approach to Planning, Scheduling, and Controlling” 7th ed. New York: John Wiley & Sons.

24. Lavold, G. D. 1983 “Developing and Using the Work Breakdown Structure” in Project Management Handbook. Edited by D. Cleland and W. R. King. Van Nostrand Reinhold: New York, 283 – 302.

25. Schneider, A. 1995. Project Management in International Teams: Instruments for Improving Cooperation “International Journal of Project Management” 13(4): 247 – 251.

26. Department of Defense 1998 “MIL HDBK – 881; Department of Defense – Work Breakdown Structure” Washington, D.C.: Department of Defense.

27. Department of Energy 1996 “DOE G 120.1 – 5, Performance Measurement Systems Guidelines” Washington, D.C.: Department of Energy.

28. Berg, С. and K. Colenso 2000. Work Breakdown Structure Practice Standard Project: WBS vs. Activities “PM Network” 14(4): 69 – 71.

Глава 6
Разработка расписания

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

Миамото Мусаши

Основные темы настоящей главы – инструменты разработки расписания:

• диаграмма Гантта;

• диаграмма контрольных событий;

• диаграмма по методу критического пути (МКП-диаграмма);

• диаграмма «операции на дугах», привязанная к временной шкале;

• расписание критической цепочки;

• иерархическое расписание;

• линия баланса.

Рис. 6.1. Роль инструментов разработки расписания в процессе управления проектами

Эти инструменты помогут при составлении расписания проекта с привязкой к календарю. Инструменты разработки расписания применяются вместе с инструментами планирования содержания и стоимости, а результатом их совместного использования является сводный план проекта (рис. 6.1). Важная роль здесь принадлежит инструментам облегчения процессов, в частности планированию команды, качества и обеспечения, а также продумыванию способов реагирования на риски. Данная глава призвана помочь менеджерам проектов:

• познакомиться с различными инструментами разработки расписания;

• выбрать инструменты, которые отвечают конкретной проектной ситуации;

• адаптировать выбранные инструменты.

Эти навыки являются критически важными в планировании и разработке процесса стандартизованного управления проектами.