Итак, мы определили результаты, которые должны быть достигнуты по завершении проекта, и согласовали их со всеми заинтересованными лицами. Однако мы не можем планировать проект, руководствуясь лишь перечнем этих результатов. Чтобы спланировать проект, необходимо определить, какие конкретные работы должны быть выполнены для достижения этих результатов, т. е. для успешного завершения проекта. Для этого и используется структура декомпозиции работ (СДР, или Work Breakdown Structure, WBS).
WBS является ключевым элементом плана проекта. Без нее невозможно определить работу, которую необходимо сделать для выполнения проекта, а значит невозможно определить ни стоимость проекта, ни его календарный план. А без этого нельзя рассчитать, какие ресурсы потребуются для выполнения проекта и в какое время эти ресурсы должны быть доступны.
Средства, выделенные на проект, будут получены вовремя только при условии тщательной проработки детального, поэтапного бюджета проекта. Наконец, не имея представления о том, какие работы должны быть выполнены в ходе проекта, невозможно удовлетворительным образом управлять рисками. Для решения всех перечисленных выше задач и необходима WBS.
Структура WBS СДР проекта в MS Project
В «Руководстве по управлению проектами» (Guide to the Project Management Body of Knowledge) WBS определяется как «ориентированное на результаты группирование компонентов проекта, которое определяет, какие работы должны быть произведены в проекте. Работы, не включенные в WBS, не входят в рамки проекта». Из этого определения мы можем извлечь метод выявления работ, которые надлежит выполнить для получения требуемых результатов проекта. Как мы увидим ниже, этот метод во многих проектах позволяет определить около 90% необходимых работ.
Методика составления структуры декомпозиции работ
Составить иерархическую структуру декомпозиции работ несложно. Прежде всего следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нужный уровень детализации. Его называют уровнем пакетов работ.
Это самый нижний уровень управления, который целесообразно отслеживать непосредственно менеджеру проекта. Вместе с тем другие члены команды проекта могут продолжить деление своих частей проекта на компоненты более низкого уровня.
Причина эффективности предлагаемой методики в том, что она основывается на принципе «разделяй и властвуй». Если вы попробуете собрать совещание, на котором предложите составить перечень всех работ проекта, результаты едва ли будут удовлетворительными. На этом совещании практически невозможно добиться сосредоточенности на решении такой задачи. Обсуждение наверняка будет вестись вокруг одного из возможных компонентов проекта в ущерб остальным, и перечень окажется однобоким.
Итак, поставленная выше задача может быть решена путем разбивки проекта на более мелкие проекты или соответствующие им продукты. (Заметим, что такой подход обеспечивает возможность эффективного применения проектного управления как методологии и в очень крупных программах, и в самых маленьких проектах.) Верхние уровни полученной иерархии, в особенности если проект крупный, иногда удобно рассматривать как декомпозицию конечного продукта проекта. Дело в том, что в крупных проектах результаты могут быть объединены в группы, которые мы и называем продуктами.
Что такое SDR приемник
Поскольку каждый из подпроектов сам по себе может быть рассмотрен как проект, любой крупный проект может быть представлен в виде ряда более мелких проектов, взаимосвязанных друг с другом.
На любом уровне получившейся иерархической структуры для каждого подпроекта должен быть менеджер, ответственный за выполнение этой части проекта. Для него это отдельный проект, за который он несет ответственность. Любой проект является частью какого-то более крупного проекта, и любой проект имеет подпроекты.
Все зависит от того, куда (вверх или вниз) смотреть с каждого элемента в иерархии структуры декомпозиции. В практическом плане топ-менеджеру программы или менеджеру проекта нет никакого смысла следить за всеми мельчайшими составляющими проекта. Ему, в сущности, нет необходимости даже знать о них.
Важно подчеркнуть, что данная методика является эффективной для проектов или программ любых размеров. Другими словами, WBS « средство, позволяющее превратить любой проект в серию более мелких проектов, которыми легче управлять.
Пример: проект «Аполлон»
В 60-е годы в США был реализован проект полета человека на Луну с последующим возвращением на Землю. В этом очень крупном проекте участвовали многие тысячи сотрудников. Руководитель проекта, о котором идет речь, жил в Вашингтоне и тратил большую часть своего времени на взаимодействие с Конгрессом США и другими правительственными структурами.
Когда программа »Аполлон« достигла своего апогея, в ее реализации единовременно оказались задействованы 40 тыс. человек. В эту программу входил проект создания двигателя первой ступени ракеты-носителя »Сатурн 5«. У проекта был свой руководитель и множество сотрудников. В проекте разработки двигателя ракеты-носителя было задействовано несколько организаций, расположенных в различных частях страны. В рамках проекта, над которым трудились несколько тысяч человек, были другие проекты: проект тестирования механизмов, проект топливных систем, проект систем охлаждения и т. д. и у каждого проекта был свой руководитель.
Хотя объем работ в рамках проекта создания двигателя ракеты-носителя был весьма и весьма значителен, речь идет лишь о малой части программы »Аполлон«. Поэтому в зависимости от места, занимаемого в иерархии руководителем какой-либо части программы, мы можем считать его менеджером программы, менеджером проекта или даже менеджером подпроекта.
Методика в подробностях
Подготовку структуры декомпозиции работ (WBS) можно считать законченной, когда определены мелкие индивидуальные части (элементарные) работы. Ответственность за каждую элементарную работу должна быть поручена одному и только одному члену команды проекта. Очень важно понять, что первоочередная задача составления WBS » разделить проект на подпроекты до той степени детализации, когда появится возможность распределить элементарные работы.
Если проект большой, WBS может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что начиная с этого уровня другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.
На самом нижнем уровне WBS должно быть описание элементарной работы, которая может быть выполнена одним человеком (или группой людей). Если этот человек (или группа) собираются выполнять работу, а не руководить ее выполнением, этот уровень может быть признан самым нижним уровнем WBS (в отличие от более высокого уровня « пакета работ, » определение которому дается выше). Этот же уровень называется уровнем задания или конкретных действий.
Вышеприведенные термины еще не вполне устоялись, что отразилось и на их трактовке в «Руководстве по управлению проектами», где подход к построению WBS отделен от определения заданий и элементарных работ. (При этом самым нижним уровнем WBS считается пакет работ « самый нижний уровень, который менеджер проекта должен держать под своим прямым контролем. Отдельно от построения WBS в »Руководстве« описано дальнейшее деление пакетов работ на более низкие уровни элементарных работ вплоть до привязки к конкретным исполнителям конкретных действий, которые в свою очередь могут быть разбиты на задания.) В »Руководстве« данный вопрос чрезмерно усложнен.
Я не думаю, что в мире много менеджеров проектов, которые не используют термины »задание«, »конкретные действия« и »элементарная работа« как взаимозаменяемые. Поэтому меня всегда несколько огорчало, что »Руководство« пытается провести это необязательное разграничение. Было бы более логично, если бы WBS начиналась с уровня проекта, разбиваемого на подпроекты, и каждый подпроект разбивался бы на подподпроекты более низкого уровня до тех пор, пока бы не был достигнут уровень элементарной работы. Большинство менеджеров проектов составляет WBS, исходя из этих позиций, поэтому попытки ввести дополнительные разграничения могут привести к неразберихе.
При построении WBS следует ставить перед собой одну-единственную цель: определить всю работу, которая необходима для выполнения проекта. Если вы попытаетесь одновременно с WBS разработать организационную структуру проекта, график финансирования или решить какие-либо иные организационные задачи проекта, весьма вероятно, что главной цели вам достичь не удастся.
Системный подход к иерархической структуре декомпозиции работ
Итак, мы разбили проект на подпроекты и продолжали декомпозицию до тех пор, пока не достигли уровня пакетов работ. Если проект небольшой, уровень пакетов работ может совпасть с уровнем элементарных работ. В более крупных проектах у пакета работ может быть свой менеджер, который продолжит детализировать работу до тех пор, пока не дойдет до уровня элементарных работ.
Крайне важно, чтобы на каждом более низком уровне декомпозиции был назначен один и только один ответственный работник, вне зависимости от того, идет ли речь о пакете работ или элементарной работе. Наконец, указанная работа проделана, WBS построена. Мы определили вроде бы всю работу по проекту. На самом деле нам удалось определить примерно 90% от общего объема работ, которые реально необходимо проделать. Теперь нужно выявить, что нам еще, возможно, предстоит сделать в проекте.
Подойдем к решению этой задачи, руководствуясь теорией управления системами. В данной концепции проект рассматривается в качестве системы, в которой работа является процессом превращения некоторых входных элементов в выходные. Иными словами, проект есть процесс превращения входных элементов (ресурсов, денег, трудозатрат) в выходные (результаты проекта).
Приложив данную теорию к нашей иерархической структуре декомпозиции работ, можно сказать, что каждая работа на самом нижнем уровне иерархической структуры есть процесс превращений входных элементов в выходные. Входные элементы » то, что исполнитель элементарной работы должен получить из какого-либо внутреннего или внешнего по отношению к проекту источника. Выходные элементы ? то, что должно быть передано в какую-то иную часть проекта, или то, что входит в результаты проекта.
Системный анализ позволяет сделать уточнения в определении работы, которую необходимо выполнить в рамках проекта. Каждый человек, отвечающий за выполнение элементарной работы, будет просматривать другие работы в поисках того, что необходимо для выполнения его работы. Он также будет изучать другие части проекта, которым должны быть переданы выходные элементы его работы.
Каждый входной и выходной элемент будет рассмотрен, по крайней мере, два раза. Все входные элементы должны исходить от чего-то внутри проекта или из внешнего источника. Все выходные элементы должны либо быть переданы в другую элементарную работу проекта, либо непосредственно являться частью результатов проекта.
К выявленным в WBS работам проекта нужно добавить работы по подготовке необходимых входных элементов, которые не были получены из внутренних или внешних источников. В качестве признака лишней работы следует рассматривать выходные элементы, которые не могут быть переданы другим компонентам проекта и не являются результатами проекта. Таким образом, вполне реально выявить практически всю необходимую дополнительную работу, еще не включенную в план, и определить всю лишнюю работу, от которой следует отказаться.
Наконец, есть возможность исключить элементарные работы, дублирующие друг друга, когда ответственный за выполнение работы находит более одной работы для обеспечения одних и тех же или почти одинаковых входных элементов.
Источник: forpm.ru
Структурная декомпозиция работ проекта
Успешное управление проектом зависит от способностей менеджера эффективно руководить командой проекта, достигая спланированных результатов. Если в документе «Паспорт проекта» сопоставить разделы «Продукт проекта» и «Результаты проекта», станет очевидно, что результатами проекта являются элементы декомпозиции продукта проекта. Именно поэтому при формировании плана выполнения проекта используют структурную декомпозицию работ. Существует несколько различных русскоязычных названий (англоязычный термин только один), которые, по сути, отражают одно и то же – структурная декомпозиция работ, структура декомпозиции работ, иерархическая структура работ, структура разбиения работ.
Структурная декомпозиция работ (СДР или WBS — Work Breakdown Structure) – это представление проекта в виде иерархической структуры работ, полученной путем последовательной декомпозиции. СДР предназначена для детального планирования, оценки стоимости и обеспечения персональной ответственности исполнителей.
Благодаря структурной декомпозиции работ менеджер проекта имеет:
· точное описание содержания работ;
· точное определение объема работ;
· измеримый результат выполнения работ.
Предназначение СДР
СДР является средством для разделения всех работ по проекту на управляемые пакеты работ. Это позволяет достичь такого уровня детализации информации, который соответствует потребностям руководства проекта для осуществления контроля. Под пакетом работ понимается комплекс работ, сгруппированных по заданным критериям. СДР позволяет свести цели проекта либо к иерархии средств их достижения, либо к иерархии результатов, предусмотренных проектом. СДР является также инструментом, позволяющим руководителю проекта получить описание конечного продукта проекта.
СДР обеспечивает выявление работ, необходимых для достижения целей проекта. Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта.
Разработка СДР имеет две основные цели:
1. обеспечение планирования всех необходимых работ проекта,
2. обеспечение отсутствия работ, не связанных с реализацией проекта.
Для руководителя проекта важны обе эти цели. Если в плане отсутствуют необходимые работы, проект будет задержан, бюджет, скорее всего, будет превышен. Если выполняются работы, не относящиеся к данному проекту – деньги заказчика тратятся нецелевым образом. Если СДР не объединяет обе эти цели, проект может потерпеть неудачу.
На основе СДР выполняются следующие процессы:
1. определение работ,
2. планирование ресурсов,
3. оценка стоимости,
5. определение рисков.
Рис. 1 Взаимодействие СДР с процессами реализации проекта (PMBOK Guide)
Таким образом, СДР является основой:
· Комплексного план-графика проекта – СДР обеспечивает основу для планирования объемов работ, стоимости, сроков и рисков. С помощью СДР работы структурируются и непосредственно связываются с графиком, а ресурсы распределяются и отслеживаются. При изменении содержания проекта СДР должна быть откорректирована. В рамках программных продуктов она также обеспечивает средство интеграции всех данных.
· Отчетности о выполнении проекта – с помощью СДР определяется состояние проекта и выдается в различные формы отчетности. Например, по стадиям жизненного цикла проекта; по результатам; по пакетам работ. Отчеты могут содержать данные по стоимости, срокам, рискам, объему, трудоемкости и качеству выполняющегося проекта или по сравнению с предыдущими аналогичными проектами (с такой же структурой).
· Комплексного контроля изменений – СДР обеспечивает идентификацию соответствующих точек контроля, которые используются для упрощения обмена информацией и контроля результатов.
· Организации взаимодействия между участниками проекта – СДР позволяет организовать направленную передачу информации между руководителем и участниками проекта на всех стадиях его жизненного цикла, с учетом принятых обязанностей и ответственности участников.
· Формирования организационной структуры – с помощью СДР можно связать определенный объем работ с элементом организационной структуры, субподрядчиками или отдельными исполнителями. Как только определяются работы, отдельные исполнители (включая субподрядчиков) назначаются ответственными за выполнение определенных элементов СДР в рамках назначенных бюджетов и определенных сроков выполнения.
Источник: studopedia.ru
Разработка структурной декомпозиции работ
Структура декомпозиции работ может разрабатываться «с нуля» либо с использованием компонентов уже созданных СДР- структур. При использовании существующих компонентов, элементы СДР составляются из элементов предыдущих проектов — аналогов или из стандартных шаблонов проектов, применяемых в данной организации, на основе удачных или типовых решений по аналогичным проектам.
Провести декомпозицию и составить СДР, по мнению некоторых авторов, очень легко: «Прежде всего, следует разбить проект на несколько подпроектов. Каждый из подпроектов, в свою очередь, может быть разбит на некоторое число подподпроектов. Так следует последовательно делить проект на составные части до тех пор, пока не будет достигнут нижний уровень детализации».
На самом деле, все не так однозначно. На стадии инициации проекта руководитель должен ответить на целый ряд вопросов:
· Что нужно сделать (определить продукты проекта);
· как это нужно будет делать (определить технологические этапы проекта);
· ктоэто будет делать (определить исполнителей, соисполнителей, субподрядчиков);
· кто и в какой форме будет оплачивать работы (определить, какие и с кем будут заключены контракты).
На какие подпроекты нужно разбить исходный проект? Что будет удобнее увидеть на первом уровне декомпозиции – компоненты конечного продукта проекта (программные, технические, информационные) или технологические этапы производства (концепция, ТЗ, проектирование)? А может быть, удобнее сгруппировать работы по исполнителям или заказчикам? Таким образом, мы подошли к трем вариантам построения СДР:
1. продуктовый подход – построение СДР по компонентам продукта проекта, когда в качестве элементов СДР выбираются элементы продукта проекта, его материальные результаты.
2. функциональный подход – построение СДР по функциональным элементам деятельности, когда в качестве элементов СДР выбираются операции технологического цикла производства продукта проекта.
3. организационный подход – построение СДР по компонентам организационной структуры, когда в качестве элементов СДР выбираются элементы структурной схемы организации.
Какой из трех принципов построения СДР выбрать, зависит от конкретного проекта. Например, если работы проекта выполняются в интересах различных заказчиков и в то же время финансируются различными инвесторами, то декомпозиция может выполняться либо по содержательному признаку отнесения работ к проектам, либо по формальному признаку отнесения работ к договорам финансирования.
Рисунок – Декомпозиция работ по различным основаниям.
Каждый из этих альтернативных взглядов имеет право на существование, но все они должны быть отражены в документации проекта и должно быть указано, какая точка зрения является главной.
Системный подход к СДР
Если при разработке СДР руководствоваться теорией управления системами, то можно рассматривать проект как процесс превращения входных элементов (ресурсов, денег, трудозатрат) в выходные (результаты проекта).
Приложив данную теорию к иерархической структуре декомпозиции работ, можно сказать, что каждая работа на самом нижнем уровне иерархической структуры есть процесс превращений входных элементов в выходные. Входные элементы – то, что исполнитель элементарной работы должен получить из какого-либо внутреннего или внешнего по отношению к проекту источника. Выходные элементы – то, что должно быть передано в какую-то иную часть проекта, или то, что входит в результаты проекта.
Системный анализ позволяет сделать уточнения в определении работы, которую необходимо выполнить в рамках проекта. Каждый исполнитель будет просматривать другие работы в поисках того, что необходимо для выполнения его работы. Он также будет изучать другие части проекта, которым должны быть переданы выходные элементы его работы. Все входные элементы должны исходить от чего-то внутри проекта или из внешнего источника. Все выходные элементы должны либо быть переданы в другую элементарную работу проекта, либо непосредственно являться частью результатов проекта.
К выявленным в СДР работам проекта нужно добавить работы по подготовке необходимых входных элементов, которые не были получены из внутренних или внешних источников. В качестве признака лишней работы следует рассматривать выходные элементы, которые не могут быть переданы другим компонентам проекта и не являются результатами проекта. Таким образом, вполне реально выявить практически всю необходимую дополнительную работу, еще не включенную в план, и определить всю лишнюю работу, от которой следует отказаться.
Наконец, есть возможность исключить элементарные работы, дублирующие друг друга, когда ответственный за выполнение работы находит более одной работы для обеспечения одних и тех же или почти одинаковых входных элементов.
Этапы разработки СДР
СДР разрабатывается путем итерационного рассмотрения целей и результатов проекта, критериев планирования/достижения функциональности, объема работ, реализации технических требований и других технических атрибутов. Верхние уровни СДР могут быть разработаны на ранней, концептуальной стадии проекта. Дальнейшая детализация СДР возможна, как только будет определен проект и подготовлены спецификации.
Основной процесс разработки СДР состоит из следующих шагов:
- Первый шаг – определение конечных результатов проекта – что должно быть произведено для обеспечения успешного завершения проекта. В качестве руководства рекомендуется проанализировать, рассмотреть документы, описывающие общий объем работ по проекту.
- Второй шаг – определение основных пакетов работ, необходимых для получения продукта проекта. Часто такими основными пакетами работ являются результаты, необходимые для создания продукта проекта, но вместе с тем, сами по себе они не являются целями проекта (например, технические требования к разработке ИС).
- Третий шаг – определение степени детализации в соответствии с внутренней системой управления и единой системой контроля. Такие элементы обычно связаны с четким и раздельным определением отдельных результатов (продуктов) проекта.
- Четвертый шаг – анализ и усовершенствование СДР. Этот шаг повторяется до тех пор, пока все участники проекта не будут согласны, что планирование проекта может быть успешно завершено, и можно будет успешно управлять, контролировать и регулировать получаемые результаты.
Подготовку структуры декомпозиции работ (СДР) можно считать законченной, когда определены мелкие индивидуальные части (элементарные) работы. Ответственность за каждую элементарную работу должна быть поручена одному и только одному члену команды проекта. Очень важно понять, что первоочередная задача составления СДР – разделить проект на подпроекты до той степени детализации, когда появится возможность распределить элементарные работы.
Если проект большой, СДР может иметь довольно общий характер. Можно остановиться на самом нижнем уровне, который отслеживает руководитель проекта. Этот уровень, напомним, принято называть пакетом работ. Следует учитывать, что, начиная с этого уровня, другие менеджеры, занятые на проекте, должны осуществить более подробное разделение проекта на части (подпроекты) до уровня элементарных работ.
На самом нижнем уровне СДР должно быть описание элементарной работы, которая может быть выполнена одним человеком (или группой людей). Если этот человек (или группа) собираются выполнять работу, а не руководить ее выполнением, этот уровень может быть признан самым нижним уровнем СДР.
Правила разработки СДР
При разработке СДР необходимо принимать во внимание следующие основные правила:
· Каждый элемент СДР должен обеспечивать достижение измеримого результата.
· Каждый элемент СДР должен агрегировать все подчиненные элементы.
· Результаты должны логически декомпозироваться до уровня, на котором можно определить, как они будут достигаться (проектирование, поставки, заключение договоров, производство).
· Результаты пакетов работ должны быть уникальными.
· Выполнение отчетов должно быть оформлено как выполнение отдельных пакетов работ.
· Все пакеты работ должны быть совместимы с организационной структурой и структурой затрат.
· Исключаются пакеты работ с несколькими ответственными за создание одних и тех же результатов.
· Результаты должны иметь размер, достаточный для эффективного управления, но не настолько малый, чтобы сделать затраты на контроль чрезмерными.
Источник: infopedia.su