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

Не следует путать СДР с множеством пугающих аббревиатур типа CWBS (структурная декомпозиция работ контракта), BOM (ведомость материалов, накладная на предметы материально-технического обеспечения) или OBS (организационная структура предприятия, ОСП). Эти инструменты столь же логичны и концептуально просты, сколь и СДР, но имеют иные цели. Например, CWBS (СДР контракта), которая обладает меньшей детализацией, используется для определения уровня отчетности, который подрядчик должен обеспечить заказчику в случае выполнения крупного контрактного проекта. Широко распространенная в производственных отраслях ведомость материалов представляет собой иерархическую структуру физических сборок, субсборок, компонентов, частей и всего остального, необходимого для выпуска продукта. И наконец, СДР отличается от ИСО (иерархической структуры организации): ИСО показывает, какие организационные единицы несут ответственность за выполнение тех или иных элементов СДР (базовая терминология приведена во врезке «Язык СДР»).

Рис. 5.6.Пример СДР проекта разработки аппаратуры

Рис. 5.7.СДР, выполненная в формате оглавления

Существуют два основных способа разработки СДР: «сверху вниз» и «снизу вверх». В этом разделе дано детальное описание подхода «сверху вниз», который является удобным инструментом в руках менеджера и команды, имеющих надлежащий опыт и представление о результатах проекта.

Сбор исходной информации.Разработка СДР станет более легким и осмысленным делом, если у вас будет следующая исходная информация:

•описание содержания проекта;

•технологическая карта выполнения операций (трудовые процессы);

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

•пул доступных ресурсов;

•конкретная проектная ситуация.

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

• Элементы работ.Любой результат в СДР называется элементом работ, состоящим из таких компонентов, как аппаратура, программное обеспечение, услуги или данные. Некоторые элементы являются прямым результатом работы, другие представляют собой объединение нескольких логически сгруппированных результатов.

•Уровень СДР.Уровнем принято называть иерархическое расположение элемента работ в СДР. Элементы работ, находящиеся на одной и той же стадии структурирования, относятся к одному иерархическому уровню. Универсальной системы для нумерации уровней не существует. Мы обозначаем уровень проекта цифрой 0, а последующие уровни – цифрами 1, 2 и т. д. Используя нумерацию уровней, вы можете присвоить уникальный код каждому элементу работ, что даст вам, например, основу для контроля стоимости.

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

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

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

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

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

Принцип, лежащий в основе построения СДР по фазам жизненного цикла, говорит сам за себя. Вы разбиваете проект на фазы жизненного цикла на уровне 1 СДР. Очевидно, что этот принцип следования естественному жизненному циклу проекта весьма популярен в некоторых отраслях. Хороший пример – проект разработки программного обеспечения, состоящий из таких фаз, как определение требований, высокоуровневое проектирование, низкоуровневое проектирование, написание кода и тестирование. Те менеджеры, которые не любят последовательные фазы, склонны делить проект на составляющие физические системы и отображать их на уровне 1 СДР. Например, в проекте разработки самолета системы, находящиеся на уровне 1 СДР, могут включать в себя фюзеляж, крылья и двигатель. Этот подход широко распространен в ряде традиционных производственных отраслей, в которых СДР напоминает ведомость материалов. Разбиение СДР по географическим зонам практикуется, в частности, в сфере строительства, где уровень 1 СДР проекта может состоять из здания A, здания B и т. д. Достаточно часто в СДР присутствуют и названия географических зон: например, северо-западная, юго-западная, юго-восточная и северо-восточная площадки.

Возможно, вы заметили, что при рассмотрении методов структурирования мы ограничились уровнем 1 СДР. А что можно сказать об уровнях 2 и более низких? Каждый способ структурирования допускает дальнейшее разбиение СДР, выполняемое по тому же принципу. Например, СДР, где уровень 1 структурирован по географическому принципу, может иметь географические зоны и на последующих, низших уровнях. Нет ничего плохого в том, чтобы использовать один и тот же принцип структурирования на всех уровнях СДР. Однако многие практикующие специалисты полагают, что гибридные СДР, сочетающие два или три метода, полезнее. В частности, они могут иметь СДР, структурированную по жизненному циклу проекта, на уровне 1, по системам – на уровне 3 и т. д. Некоторые даже смешивают два метода структурирования на одном уровне, допустим по системам и по географическим зонам для уровня 1.

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

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

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

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

•от трех до четырех уровней в СДР;

•от 15 до 40 пакетов работ;

•от 40 до 80 часов на средний пакет работ;

•длительность среднего пакета работ – от одной до двух недель;

•от 3 до 7% общего бюджета рабочих часов на средний пакет работ.

«Сколько уровней требуется в нашем проекте?» – этим вопросом задались люди, занимавшиеся разработкой процессов управления проектами. Чтобы получить удовлетворительный ответ, они сначала исследовали, какими проектами управляют, и выяснили, что у них от 10 до 15 проектов в год стоимостью от 100 тысяч до 5 миллионов долларов, причем главным образом по проектированию и сооружению электрических подстанций. После проведения бенчмаркинга разработчики остановились на варианте пятиуровневой СДР для каждого проекта. Вскоре после старта процесса управления среди менеджеров малых проектов начался тихий бунт, за которым последовал категорический отказ использовать разработанный процесс. Обоснование было очень простым. Объем работы по календарному планированию, бюджетированию и контролю 250 пакетов работ в пятиуровневой СДР приводил к застопориванию малых проектов. В результате менеджеры предпочли вернуться к старому бессистемному методу управления. Мораль этой истории такова: размер и структура СДР должны соответствовать размеру и структуре проекта.

Рис. 5.8.Пакет работ – ключевое звено в управлении иерархической структурой работ

В то же время для больших проектов в литературе приводятся следующие данные о степени детализации [23, 24]:

•пять и более уровней в СДР;

•от 80 до 200 часов на средний пакет работ;

•менее двух-четырех недель на средний пакет работ;

•от 0,5 до 2,5% общего бюджета проекта на средний пакет работ.

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

Структурирование СДР.Когда в вашем распоряжении оказывается вся необходимая информация, в том числе тип СДР и степень ее детализации, можно приступать к логическому построению СДР проекта (см. врезку «Золотые правила структурирования СДР»). Шаги структурирования СДР перечислены ниже:

1.Начать с идентификации основных результатов проекта. В зависимости от типа выбранной СДР это могут быть фазы, системы, географические зоны или их комбинации. В данной ситуации полезен подход, называемый связыванием с содержанием.В частности, при составлении описания содержания вы идентифицируете основные результаты, которые могут быть позаимствованы из него и использованы в качестве основных итогов СДР. Это поможет интегрировать описание содержания с СДР, связав бизнес-цели и цели проекта посредством основных результатов с результатами более низких уровней вплоть до уровня пакетов работ.

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

3.Выбрать способ представления СДР. В случае малых проектов изображение СДР в виде дерева обеспечивает лучшую наглядность и является предпочтительным (см. верхнюю часть рис. 5.6). По мере увеличения числа уровней растет также и сложность СДР, и сохранение формата дерева становится затруднительным. Спасти положение может использование формата оглавления. Например, на рис. 5.7 показана СДР в формате оглавления (того же проекта, что и на рис. 5.6). Этот процесс построения СДР выглядит до некоторой степени случайным. Привнесение упорядоченности в него возможно лишь при соблюдении определенных условий (см. врезку «Золотые правила структурирования СДР») [26, 27].

4.Убедиться в том, что СДР ориентирована на результаты. Так как в СДР речь идет о предметах поставки, в ней нет места операциям [28].

5.Удостовериться в том, что СДР включает в себя все работы проекта. То, что оставлено за пределами СДР, не будет учтено при распределении ресурсов и календарном планировании, а это рискованно.

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

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

8.Сформировать СДР, которая объединяет элементы работ или отдельные уровни до их слияния в той точке, где выполнение совокупности этих элементов эквивалентно завершению проекта.

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

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

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

• Включать в СДР только результаты;

• отображать все работы, входящие в проект;

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

• при необходимости использовать асимметричные ветви;

• рассматривать построение СДР как комплексное действие.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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