Структура декомпозиции работ

Итак, мы определили результаты, которые должны быть достигнуты по завершении проекта, и согласовали их со всеми заинтересованными лицами. Однако мы не можем планировать проект, руководствуясь лишь перечнем этих результатов. Чтобы спланировать проект, необходимо определить, какие конкретные работы должны быть выполнены для достижения этих результатов, т. е. для успешного завершения проекта. Для этого и используется структура декомпозиции работ (СДР, или Work Breakdown Structure, WBS).

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

В «Руководстве по управлению проектами» (Guide to the Project Management Body of Knowledge, http://www.pmi.org/publictn/pmboktoc.htm) WBS определяется как «ориентированное на результаты группирование компонентов проекта, которое определяет, какие работы должны быть произведены в проекте. Работы, не включенные в WBS, не входят в рамки проекта». Из этого определения мы можем извлечь метод выявления работ, которые надлежит выполнить для получения требуемых результатов проекта. Как мы увидим ниже, этот метод во многих проектах позволяет определить около 90% необходимых работ.

Методика

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

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

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

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

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

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

Пример: проект «Аполлон»

В 60-е годы в США был реализован проект полета человека на Луну с последующим возвращением на Землю. В этом очень крупном проекте участвовали многие тысячи сотрудников. Руководитель проекта, о котором идет речь, жил в Вашингтоне и тратил большую часть своего времени на взаимодействие с Конгрессом США и другими правительственными структурами.

Когда программа «Аполлон» достигла своего апогея, в ее реализации единовременно оказались задействованы 40 тыс. человек. В эту программу входил проект создания двигателя первой ступени ракеты-носителя «Сатурн 5». У проекта был свой руководитель и множество сотрудников. В проекте разработки двигателя ракеты-носителя было задействовано несколько организаций, расположенных в различных частях страны. В рамках проекта, над которым трудились несколько тысяч человек, были другие проекты: проект тестирования механизмов, проект топливных систем, проект систем охлаждения и т. д. и у каждого проекта был свой руководитель.

Хотя объем работ в рамках проекта создания двигателя ракеты-носителя был весьма и весьма значителен, речь идет лишь о малой части программы «Аполлон». Поэтому в зависимости от места, занимаемого в иерархии руководителем какой-либо части программы, мы можем считать его менеджером программы, менеджером проекта или даже менеджером подпроекта.

Методика в подробностях

Подготовку структуры декомпозиции работ (WBS) можно считать законченной, когда определены мелкие индивидуальные части (элементарные) работы. Ответственность за каждую элементарную работу должна быть поручена одному и только одному члену команды проекта. Очень важно понять, что первоочередная задача составления WBS » разделить проект на подпроекты до той степени детализации, когда появится возможность распределить элементарные работы.

Если проект большой, WBS может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что начиная с этого уровня другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.

На самом нижнем уровне WBS должно быть описание элементарной работы, которая может быть выполнена одним человеком (или группой людей). Если этот человек (или группа) собираются выполнять работу, а не руководить ее выполнением, этот уровень может быть признан самым нижним уровнем WBS (в отличие от более высокого уровня » пакета работ, » определение которому дается выше). Этот же уровень называется уровнем задания или конкретных действий.

Вышеприведенные термины еще не вполне устоялись, что отразилось и на их трактовке в «Руководстве по управлению проектами», где подход к построению WBS отделен от определения заданий и элементарных работ. (При этом самым нижним уровнем WBS считается пакет работ » самый нижний уровень, который менеджер проекта должен держать под своим прямым контролем. Отдельно от построения WBS в «Руководстве» описано дальнейшее деление пакетов работ на более низкие уровни элементарных работ вплоть до привязки к конкретным исполнителям конкретных действий, которые в свою очередь могут быть разбиты на задания.) В «Руководстве» данный вопрос чрезмерно усложнен. Я не думаю, что в мире много менеджеров проектов, которые не используют термины «задание», «конкретные действия» и «элементарная работа» как взаимозаменяемые. Поэтому меня всегда несколько огорчало, что «Руководство» пытается провести это необязательное разграничение. Было бы более логично, если бы WBS начиналась с уровня проекта, разбиваемого на подпроекты, и каждый подпроект разбивался бы на подподпроекты более низкого уровня до тех пор, пока бы не был достигнут уровень элементарной работы. Большинство менеджеров проектов составляет WBS, исходя из этих позиций, поэтому попытки ввести дополнительные разграничения могут привести к неразберихе.

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

Системный подход к иерархической структуре декомпозиции работ

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

Крайне важно, чтобы на каждом более низком уровне декомпозиции был назначен один и только один ответственный работник, вне зависимости от того, идет ли речь о пакете работ или элементарной работе. Наконец, указанная работа проделана, WBS построена. Мы определили вроде бы всю работу по проекту. На самом деле нам удалось определить примерно 90% от общего объема работ, которые реально необходимо проделать. Теперь нужно выявить, что нам еще, возможно, предстоит сделать в проекте.

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

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

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

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

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

Автор: Майк Ньюэлл,
вице-президент компании PSM Consulting
Источник: Опубликовано в журнал «Директор ИС», #03, 2001 год