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

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

КАК НАДО ПОСТУПАТЬ ПРИ ПОДГОТОВКЕ ОПИСАНИЯ СОДЕРЖАНИЯ – ПРОСТЫЕ ПРАВИЛА

1. Если описание содержания занимает несколько страниц, разделите его на две части: резюме объемом в одну страницу (как на рис. 5.5) и вспомогательную документацию.

2. Не повторяйте во второй части то, что уже изложено в первой.

3. Используйте повседневную лексику, а не сложную терминологию; расшифровывайте сокращения.

4. Включите в описание данные о функциональных группах, являющихся поставщиками ресурсов.

5. Добейтесь утверждения документа руководством.

КАК НЕ НАДО ПОСТУПАТЬ ПРИ ПОДГОТОВКЕ ОПИСАНИЯ СОДЕРЖАНИЯ – ПРОСТЫЕ ПРАВИЛА

1. Не приступайте к определению содержания, если не знаете, как его структурировать.

2. Не превращайте содержание в чисто техническое описание проекта.

3. Не используйте неточностей (например, «около, приблизительно»).

4. Не смешивайте большие и малые цели, результаты и контрольные события.

5. Не начинайте выполнение проекта до тех пор, пока содержание не будет рассмотрено независимыми экспертами.

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

Выгоды. Пользователи ценят описание содержания за то, чем оно является – первым инструментом в планировании проекта, направляющим все остальные инструменты в процессе планирования и контроля, выстраивающим структуру основных положений проекта, фиксирующим их и отображающим в удобном для восприятия виде. Формируя базовый план содержания и иерархическую структуру работ, описание содержания помогает проектной команде сохранять концентрацию на нужных аспектах, а обеспечиваемая им цельная картина задает общее направление и руководство. Как только базовый план будет сформирован, команда должна приступить к разработке плана контроля изменений (см. врезку «План контроля изменений задает направление контроля содержания»).

Преимущества и недостатки. Описание содержания обладает рядом не подлежащих сомнению преимуществ:

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

• простота. Простота описания упрощает понимание многочисленных переменных задач проекта;

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

К основным недостаткам описания содержания относятся:

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

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

Вариации. Описание содержания разработано как кросс-отраслевой инструмент с такой степенью обобщения, которая делает его пригодным для использования в максимально широком спектре проектов. Тем не менее практически в любой отрасли и в любом семействе проектов может возникнуть необходимость в изменении способа применения. Возьмем, например, разработчиков продуктов. Включение описания продукта в описание содержания (после определения целей проекта) здесь является обычной практикой. Подобное описание обычно содержит [21]:

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

• определение концепции продукта и выгод, которые должны быть получены;

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

• список характеристик, атрибутов, требований и спецификаций продукта (с расстановкой приоритетов по принципу «что нужно иметь», а не «что хотелось бы иметь»).

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

ПЛАН КОНТРОЛЯ ИЗМЕНЕНИЙ ЗАДАЕТ НАПРАВЛЕНИЕ КОНТРОЛЯ СОДЕРЖАНИЯ

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

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

2. Как определяется сфера полномочий по контролю за изменениями? Например, комитет уполномочен вносить значительные изменения, существенно затрагивающие содержание. Для обеспечения оперативного реагирования председателю комитета дается право утверждения модификаций, то время как остальные члены рассматривают (но не утверждают!) задачи, соответствующие их профессиональным знаниям. Изменения, не влияющие на содержание или влияющие на него незначительно, находятся в ведении менеджера проекта.

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

4. Как осуществляется управление управленческим резервом? Для ослабления риска изменений следует выделить некоторую денежную сумму в качестве управленческого резерва (см. раздел «План реагирования на риски» главе 9) и определить порядок его использования.

5. Каким образом утвержденные изменения реализуются на практике? Например, вполне приемлемым решением может быть назначение администратора.

6. В какой момент жизненного цикла проекта нужно начать и закончить использование процедуры запроса на изменение? Этот момент должен конкретизироваться с помощью контроля за изменениями (см. раздел «Запрос на внесение изменения в проект» в главе 11).

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

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

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

ПРОВЕРКА ОПИСАНИЯ СОДЕРЖАНИЯ

Убедитесь, что описание содержания:

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

• включает в себя все элементы, определенные форматом;

• обеспечивает согласованность всех элементов;

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

Структурная декомпозиция работ (СДР) – это ориентированный на результаты способ группировки элементов проекта, который упорядочивает и определяет общее содержание проекта[19]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. Сформировать СДР, которая объединяет элементы работ или отдельные уровни до их слияния в той точке, где выполнение совокупности этих элементов эквивалентно завершению проекта.

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

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

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

ЗОЛОТЫЕ ПРАВИЛА СТРУКТУРИРОВАНИЯ СДР

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

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

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

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

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