Wbs element что это
Преимущества Иерархической Структуры Работ (WBS) для менеджеров ИТ проектов
Имеющие дело со сложными ИТ проектами руководители подтвердят, что разделение задач на более мелкие и управляемые части делает рабочий процесс намного проще. В этой статье расскажу о процессе, который поможет структурировать каждый этап проекта и учитывать все поставленные задачи. Речь идет об иерархической структуре работ WBS (Work Breakdown Structure).
Если вы помните, как использовать Agile-методологию управления проектами, определять критический путь и ставить SMART-цели, то пришло время перейти к новому уровню компетенции в управлении проектами.
Что такое иерархическая структура работ WBS?
Иерархическая структура работ WBS, или структура декомпозиции, представляет собой схему, где задачи проекта отражают их отношение друг к другу и к проекту в целом. Термин был впервые употреблен в США в 1993 году.
WBS основана на графической природе, которая помогает менеджерам проектов предсказать результаты, основанные на различных сценариях. Процесс часто описывается как структура ответвления, которая охватывает все этапы проекта в организованном порядке. WBS также может быть представлена в виде табличного списка задач и элементов в плане разбивки работ диаграмм Ганта.
Менеджеры используют структуру декомпозиции, чтобы структурировать и делить проекты на легко управляемые компоненты. Они, в свою очередь, разделяются до тех пор, пока они не назначаются конкретному специалисту в команде.
Почему стоит использовать WBS:
Планирование: исследование, планирование бюджета, согласование и утверждение плана, вопросы координации.
Питание: меню, закупки, приготовление пищи, обслуживание.
Площадка и активности: столы и посадочные места, посуда, декорирование и оборудование, брендинг.
Участники/гости: приглашения, список гостей, особые случаи.
Персонал: водители, повар, официанты, уборщики.
Хедлайнер: приглашение, вопрос логистики, согласование сценария/ плей-листа.
Компоненты WBS
Согласно иерархической структуре, необходимо пройти несколько этапов (компонентов) для того, чтобы оптимизировать и упростить процесс управления:
5 шагов для разработки простой структуры WBS
Чтобы достичь целей проекта, необходимо следовать определенному плану выполнения WBS.
Начните с концепции проекта и утверждения главных моментов в верхушке иерархии. Определите все необходимые задачи, от которых будут зависеть результаты. В идеале, в процесс планирования и определения концепции должны быть вовлечены усилия всей команды. Тем не менее, каждый специалист должен отвечать за выполнение конкретной задачи.
1. Утвердите и распишите проект
Это может быть просто предложение или абзац, описывающий концепт и функции проекта после завершающей стадии. Эта стадия WBS представляет собой основу любого проекта и, как правило, разрабатывается всей командой.
2. Выделите все ключевые этапы
После того, как первый этап завершен, можно приступать к следующим.
Может быть, вам придется делить задачу на множество этапов в зависимости от характера вашего проекта. Как правило, это зависит от требований, возможностей бюджета и временных рамок. 
3. Определите конечные результаты
Сформулируйте для себя все моменты, которые должны быть завершены в течение каждого этапа. Все они должны иметь конечные результаты. Вы должны их достичь полностью, прежде чем перейти к следующему этапу. Каждый конечный результат также должен иметь свое описание, цели и функции.
4. Разделите конечные результаты на управляемые задачи
После создания списка конечных результатов добавьте еще один уровень иерархии для расчета деталей. Задачи проекта должны быть выполнены в виде секций. Любой член команды или небольшая команда будет иметь возможность легко управлять ими.
5. Распределите задачи
Назначение ответственного за каждую часть работ является последней стадией иерархии. Конкретный специалист будет отвечать за конкретную задачу. Он/она будет участвовать в каждом этапе работы, что приведет к качественным результатам.
В видео показан легкий способ создания WBS.
Кто может использовать WBS?
Как правило, менеджеры используют структуру при разработке коммерческих, жилищных и строительных проектов. С ней инвесторам и клиентам проще понять, что и как происходит в развитии проекта.
Разработчики ПО тоже сперва утверждают концепции и создают требований на ее основе. Это придает WBS черты идеального инструмента для разработки.
Если попробовать классифицировать команды, которые могут использовать инструменты WBS, получим такой список:
Преимущества структуры WBS для менеджеров ИТ проектов
Структура WBS стала популярной и широко используемой в разработке программного обеспечения благодаря ее очевидным преимуществам. Руководители проектов смело ее применяют. И вот почему:
1. Усиление коммуникации в команде проекта
Неважно, имеет ли ваш ИТ проект внутреннюю или внешнюю направленность. Иерархическая структура работ включает в себя коммуникационные акты на каждом шагу.
2. Поле для творчества
Похоже на стереотип, но люди думают, что разработка программного обеспечения – это только аналитическая работа. Нет, здесь еще есть пространство для развития творческих способностей. При определении концепции проекта члены команды могут использовать WBS и предлагать творческие идеи для развития проекта.
3. Фокусировка на конечных целях
WBS помогает держать всю команду в фокусе и сосредоточенной на конечной цели. Это сводит к минимуму вероятность выполнения ненужной работы.
4. Детализация
Каждая деталь тщательно рассматривается, поэтому в проекте ничего не теряется.
5. Предвидение появления проблем
Когда проект будет готов, могут возникнуть непредвиденные проблемы. Иерархическая структура работ помогает сократить их число, поскольку все детали учитываются перед выполнением.
6. Коллективный мозговой штурм
Менеджеры используют структуру для мозгового штурма, чтобы найти полезные идеи и решения. С ее помощью их легко собрать, а затем из них вычеркивать ненужные.
7. Вопросы планирования
С помощью WBS легко определить, какие из запланированных задач отстают от графика.
8. Управление рисками
Если вы используете WBS, вы уменьшаете риски и управляете ими с самого начала. Это помогает распределить все ресурсы: денежные средства, время и трудозатраты.
9. Распределение задач
Когда вы структурировали свой проект, становится легче назначать задачи конкретным людям.
10. Гибкость для различных команд
Иерархическая структура работ используется в различных сферах. Не имеет значения, сколько людей в команде: WBS всегда будет поддерживать процесс выполнения проекта. Она также может стать отличным инструментом для привлечения клиентов, так как показывает процессы изнутри и помогает их лучше понять.
WBS + диаграмма Ганта = улучшенный процесс планирования
Для отображения иерархической структуры работ широко распространена практика применения диаграмм Ганта. Именно они четко отображают всю структуру, причем в очень удобном виде. Диаграммы Ганта используются во многих программах и сервисах для управления проектами, таких как GanttPRO, MS Project, Wrike и т.д.
Вот, как это выглядит на примере GanttPRO.
Диаграмма Ганта позволяет расширить функционал иерархической структуры работ. Так, благодаря ей четко видны сроки начала и окончания задачи, ее полная протяженность, кто ее выполняет, каков прогресс выполнения, зависимости между задачами. Кроме того, можно обозначить вехи — важные события, влияющие на проект, а также критический путь.
Онлайн диаграмма Ганта подходит и для управления командой проекта. Под каждой задачей можно оставлять комментарии, прикреплять файлы, делиться самим графиком, экспортировать его в популярные форматы, просматривать историю изменений — командная работы действительно удобна. Впрочем, как и отслеживание других процессов, связанных с управлением проектами.
Подведем итоги
Иерархическая структура работ — распространенный и удобный способ планирования ИТ и любых других проектов. А если отобразить ее диаграммой Ганта, то в таком виде она значительно упрощает процесс не только планирования, но и управления. С ней можно:
СОДЕРЖАНИЕ
Обзор
Структурная декомпозиция работ обеспечивает общую основу для естественного развития общего планирования и контроля контракта и является основой для разделения работы на определяемые приращения, из которых может быть составлено техническое задание, график, стоимость и рабочее время. отчетность может быть установлена.
Разработка WBS обычно происходит в начале проекта и предшествует подробному планированию проекта и задач.
История
К июню 1962 года Министерство обороны, НАСА и аэрокосмическая промышленность опубликовали документ для системы PERT / COST, в котором описывался подход WBS. Это руководство было одобрено министром обороны для принятия всеми службами. В 1968 году Министерство обороны выпустило «Структуры аварийного отключения для оборонных материалов» (MIL-STD-881), военный стандарт, требующий использования структур аварийного отключения по всему Министерству обороны.
Документ пересматривался несколько раз, последний раз в 2018 году. Текущую версию этого документа можно найти в разделе «Структуры разбивки работ для элементов оборонных материалов» (MIL-STD-881E). Он включает определения WBS для конкретных товарных систем оборонного оборудования и обращается к элементам WBS, которые являются общими для всех систем.
Категории предметов военной техники по стандарту MIL-STD-881E:
Общие элементы, указанные в MIL-STD-881E, Приложение K: Интеграция, сборка, тестирование и проверка; Системная инженерия; Программный менеджмент; Системное тестирование и оценка; Данные; Своеобразное вспомогательное оборудование; Общее вспомогательное оборудование; Оперативная / активация сайта; Материально-техническое обеспечение подрядчика; Промышленные объекты; Первичные запчасти и запчасти. Стандарт также включает дополнительные общие элементы, уникальные для космических систем, систем ракет-носителей и стратегических ракетных систем.
В 1987 году Институт управления проектами (PMI) задокументировал распространение этих методов на не оборонные организации. В Руководстве по совокупности знаний по управлению проектами (PMBOK) представлен обзор концепции WBS, в то время как «Практический стандарт для структур декомпозиции работ» сопоставим со стандартом DoD, но предназначен для более общего применения.
Принципы дизайна
100% правило
Важный принцип проектирования структурной разбивки работ называется правилом 100%. Это было определено следующим образом:
Взаимоисключающие элементы
Планируйте результаты, а не действия
Уровень проработанности деталей
Надо решить, когда перестать разбивать работу на более мелкие элементы. Для большинства проектов достаточно иерархии от двух до четырех уровней. Это поможет в определении продолжительности действий, необходимых для получения результата, определенного WBS. Есть несколько эвристик или «эмпирических правил», используемых при определении подходящей продолжительности действия или группы действий, необходимых для получения конкретного результата, определенного WBS.
Схема кодирования
Практический пример схемы кодирования WBS:
1.0 Авиационная система
1.1 Воздушный транспорт 1.1.1 Планер 1.1.1.1 Интеграция, сборка, испытания и проверка планера 1.1.1.2 Фюзеляж 1.1.1.3 Крыло 1.1.1.4 Оперение 1.1.1.5 Гондола 1.1.1.6 Другие компоненты планера 1..n (указать) 1.1.2 Движение 1.1.3 Подсистемы автомобиля 1.1.4 Авионика 1.2 Системное проектирование 1.3 Управление программой 1.4 Системное тестирование и оценка 1.5 Обучение 1.6 Данные 1.7 Особое вспомогательное оборудование 1.8 Общее вспомогательное оборудование 1.9 Операционная / активация сайта 1.10 Промышленные объекты 1.11 Первоначальные запасные части и запасные части
Терминальный элемент
Соответствует нормам
Структура WBS более высокого уровня должна соответствовать любым нормам или шаблонам, существующим в организации или домене. Например, судостроение для ВМС США должно учитывать, что морские термины и их иерархическая структура, заложенные в MIL-STD, встроены в военно-морскую архитектуру и что соответствующие офисы и процедуры ВМС были построены в соответствии с этой структурой военно-морской архитектуры, поэтому любое существенное изменение Нумерация или именование СПП-элементов в иерархии недопустима.
Пример
На соседнем рисунке показана техника построения структурной декомпозиции работ, демонстрирующая правило 100% и технику «прогрессивной проработки». На уровне 1 WBS он показывает 100 единиц работы как общий объем проекта по разработке и созданию нестандартного велосипеда. На уровне 2 WBS 100 единиц разделены на семь элементов. Количество единиц, выделяемых на каждый элемент работы, может зависеть от усилий или затрат; это не оценка продолжительности задачи.
Дизайн WBS может поддерживаться программным обеспечением (например, электронной таблицей ), чтобы обеспечить автоматическое объединение значений точек. Оценки трудозатрат или затрат можно получить в ходе обсуждений между членами проектной группы. Этот метод совместной работы позволяет лучше понять определения содержания, исходные допущения и консенсус относительно уровня детализации, необходимого для управления проектами.
Что такое WBS проекта, и зачем она нужна
Хорошо, что лето в разгаре, заказчики по отпускам, и можно потеоретизировать. Сегодня у нас на очереди статья о том, что такое WBS проекта и зачем она нужна. Опытные РМы – пропускают, ничего нового там не будет. Новички – читают в обязательном порядке.
Что такое WBS проекта
WBS проекта (она же Work Breakdown Structure или ИСР, Иерархическая Структура Работ) – это разбиение проекта на конкретные результаты, которые должны быть достигнуты для достижения целей проекта.
Как правило, на верхнем уровне указывается сам проект, под ним (на первом уровне) – основные результаты, каждый из которых, в свою очередь, детализируется, то есть следующий уровень всегда меньше предыдущего по объему работ и, как правило, включает 2 и более пакетов работ. При этом в разных ветках WBS может быть разное количество уровней в зависимости от нужной степени детализации.
На словах, как всегда, мало что понятно, поэтому любимый пример с ремонтом (картинка большая, для детального просмотра ее лучше открыть в новой вкладке):
В конце поста будут ссылки на скачивание этого и других примеров WBS!
Важно понимать, что в WBS собираются именно результаты работ, а не задачи, которые нужно выполнить для получения этих результатов.
В классическом подходе все блоки WBS (так называемые Work Packages) нумеруются, но в жизни я таких ответственных РМов видела буквально несколько раз. Сама я, как правило, нумеровать не то что бы ленюсь – просто не вижу смысла, так как после завершения планирования WBS использую как инструмент оперативного управления, и при нумерации становится сложнее поддерживать корректную интеграцию в проекте.
Зачем нужна WBS
WBS – крайне полезная вещь в планировании проекта и вот почему:
Уже на этом этапе хорошо бы донести до заказчика вашу позицию «Если задач нет в WBS – их нет и в проекте». Во-первых, все постараются при разработке или при согласовании немного больше, а во вторых – у вас появится хороший рычаг влияния на будущее.
Группировка и декомпозиция WBS
Первый вопрос, который возникает в начале создания WBS – как группировать элементы WBS, по какому принципу?
Способ группировки, как правило, выбирается в зависимости от проекта, основной критерий тут – чтобы было понятно вам и команде.
Классические варианты группировки WBS:
Одним словом – можно любой свой вариант придумать, лишь бы было удобно.
Второй любимый вопрос начинающего PMа – до какой степени нужно детализировать WBS? Забавно, но правильного ответа на этот вопрос не существует. Степень декомпозиции зависит как от размера, так и от типа проекта, а также от количества времени, которое вы можете потратить на проработку.
Поэтому ответ очень простой – при планировании проекта и разработке WBS нужно просто определиться, какой объем работы на нижнем уровне для вас приемлем, чтобы вы могли ее контролировать. Слишком большие задачи – плохо, так как не будет понимания реальной картины, слишком маленькие – тоже плохо, так как найти время на контроль станет сложнее (например, если вы контролируете результат раз в неделю – нет смысла бить задачу на однодневные результаты, проверить все равно сможете только в комплексе).
При подготовке к сдаче PMP в книжке Риты Малкахи приводятся такие усредненные рекомендации:
В жизни такой идеальный баланс найти не всегда удается, поэтому в WBS попадают как небольшие задачи, результат которых критически важен для проекта, так и крупные. Так, например, в примере с ремонтом есть как «закрытие договора с текущим ЖЭКом» длительностью максимум 30 минут (ЖЭК у меня на 1м этаже сидит в соседнем подъезде), так и штукатурка по маякам, которая несколько дней займет (но мне с этим комфортно, так как проконтролировать промежуточный результат или как-то всерьез повлиять на скорость высыхания штукатурки я все равно не смогу).
В работе лично я стараюсь ориентироваться на планку «8 часов на нижнем уровне WBS».
Самый простой критерий, по которому можно проверить, что вы достигли «дна» WBS – это возможность поставить конкретную задачу одному исполнителю для выполнения указанного пакета работ. Если исполнителей несколько и выделить среди них единого ответственного нельзя – значит, нужно декомпозировать дальше.
К слову, декомпозиция может идти как сверху вниз (мы детализируем высокоуровневые результаты) или снизу вверх (у нас есть разрозненное понимание отдельных задач, и мы их компонуем в более высокоуровневые для облегчения понимания и управления).
Третий вопрос, отражающий веяния времени – что делать, если проект выполняется по гибкой методологии и результаты вы получаете итерационно?
Правильного ответа тоже нет, но есть варианты:
Инструменты для разработки WBS
Единственное правило тут – разрабатывать в том, в чем удобно. Если у вас есть какой-то инструмент для построения диаграмм – отлично, если нет – подойдет любой другой, например, Mind Manager, Excel, MS Project, Visio или любой онлайн-аналог.
Я последние пару лет перешла от диаграмм к майнд-мепам (ментальным картам), на мой взгляд, формировать структуру работ там очень удобно из-за гибкости инструмента. Самый неудачный выбор, на мой взгляд – это Excel или MS Project, так как они сводят создание WBS к работе со списками и не дают нужной наглядности.
Типовая ошибка тех, кто делает WBS в MS Project – одновременно пытаться описать результаты и указать зависимости (в самых тяжелых случаях – еще и трудоемкость и ресурсы). Цель WBS – получить именно полное содержание проекта, а не закрыть задачу планирования одним махом. А еще так легко что-то упустить, так как представление в MS Project не наглядное.
WBS Dictionary или Словарь ИБС
WBS Dictionary (он же Словарь ИБС) – это описание на страничку А4 (или подробнее) для каждого пакета работ, включающее код пакета работ, его наименование, детальное описание результата, критерии приемки, ответственного (это, наверное, самое ценное в словаре), ограничения и допущения и вообще все, что кажется вам полезным.
Я сама в жизни это использовала буквально 2 или 3 раза, слишком уж трудозатратная вещь, тем более в очень динамичных проектах разработки ПО. В какой-нибудь стройке или энергетике, наверное, без этого никуда.
Это, наверное, все, что нужно знать о создании и использовании WBS для старта. Удачи!
P.S. И да, неполная, недостаточная и не совсем правильная WBS все равно гораздо лучше, чем ее отсутствие
Информация полезна? Поддержи развитие проекта!
На кофе и новые материалы для читателей блога 🙂
Wbs element что это
Используемые в данном тексте термины имеют следующие значения:
Work (Работа) – непрерывное физическое или умственное усилие, направленное на преодоление препятствий и достижение целей или результатов; специфическая задача, обязанность, функция или задание, часто являющиеся частью фазы или другой, большей по объему работы; что-то, производимое или выполняемое в результате усилия или применения навыков (квалификации).
Breakdown (Декомпозиция) – разделение на части или категории, выделение простых составляющих.
Structure (Структура) – фиксированное упорядоченное множество объектов и отношений между ними, классификация чего-либо по заданному основанию.
Эти определения означают, что Структура Декомпозиции Работ (WBS) имеет следующие характеристики:
1.2. Обзор
WBS является средством для разделения всех работ по проекту на управляемые, определяемые пакеты работ, позволяющие достичь уровень детализации предоставляемой информации, соответствующий потребностям руководства проекта в контроле. WBS позволяет определить работу по проекту с точки зрения жизненного цикла проекта.
WBS позволяет свести цели проекта к иерархии средств их достижения, или, что то же, получения результатов, предусмотренных проектом. WBS является так же инструментом, позволяющим руководителю проекта получить описание конечного результата (продукта, услуги) проекта и всех подпроектов, в результате которых будет достигнут запланированный результат. Далее WBS может разделяться (и результаты подразделяться) на части для специализации видов и объемов работ участников проекта, координации их действий и закрепления ответственности за объемами работ, вплоть до уровня, обеспечивающего управляемость и надлежащее администрирование проекта.
WBS обеспечивает выявление работ, необходимых для достижения целей проекта. При таком подходе проект определяется в терминах иерархически взаимосвязанных ориентированных на результат элементов (пакетов работ – комплексов работ, сгруппированных по заданным основаниям/критериям). Каждый следующий уровень декомпозиции обеспечивает последовательную детализацию содержания проекта, что позволяет производить оценку выполненных объемов работ, освоенных денег и выполнения по срокам. На нижних уровнях пакетам работ соответствуют сравнительно меньшие объемы работ. Это упрощает оценку процента выполнения и дает возможность более четко определять действия, необходимые для достижения целей проекта. Предложенный подход декомпозиции работ формирует необходимую основудля определения измеримых показателей (трудоемкости, стоимости), а также позволяет с высокой степенью достоверности говорить о том, что цели, связанные с данным пакетом работ могут и будут достигнуты.
1.2.1. WBS для определения результатов проекта
«Измеряемый, осязаемый (материальный); поддающийся проверке и контролю результат или позицию (изделие), которые должны быть произведены для завершения части проекта или всего проекта в целом. Часто используется в более узком смысле по отношению к внешнему результату, определяемым инвестором проекта или его заказчиком (PMBOK, 1996).»
WBS, как концептуальное понятие, рассматривается в самом широком смысле, какой может быть заложен в понимании результата проекта. Кроме того, WBS обеспечивает основу для последующей интеграции частных пакетов работ и результатов с другими аспектами инициации, планирования, контроля, выполнения и завершения проекта.
1.2.2. WBS для организации коммуникаций
WBS позволяет организовать направленную передачу информации, в соответствии с конкретными задачами по разработке и выполнению проекта, между руководителем и участниками проекта на всех стадиях его жизненного цикла, с учетом принятых обязанностей и ответственности участников. К участникам проекта, относятся все, кто непосредственно участвует или заинтересован в результате проекта, в том числе:
1.2.3. WBS как инструмент документирования
WBS является одним из основных инструментов (средств) в механизме управления проектом, с помощью которого измеряется степень (в абсолютной или относительной шкале) достижения результатов проекта., представляется информация на соответствующие уровни детализации, в формате и структуре, доступный и принятой теми, кто выполняет и контролирует работы,
1.2.4. WBS для формирования отчетности
С помощью WBS определяются различные представления состояния проекта и выдаются в формы отчетности, отражающие различные аналитики. Например:
Отчеты могут содержать данные по стоимости, срокам, рискам, объему, трудоемкости и качеству выполняющегося проекта или по сравнению с предыдущими аналогичными проектами (с такой же структурой)
1.2.5. WBS как средство управления
С помощью WBS поддерживается эффективное управление проектом по стадиям жизненного цикла. Это обеспечивается за счет:
1.2.6. WBS при формировании организационной структуры
С помощью WBS можно связать определенный объем работ с элементом организационной структуры, субподрядчиками или отдельными исполнителями. Как только работы и область ответственности определяются, отдельные исполнители (включая субподрядчиков) назначаются ответственными за выполнение определенных элементов WBS в рамках назначенных бюджетов и определенных сроков выполнения.
1.2.7. WBS при определении уровней
В учебно-справочной литературе по управлению проектами для проектов средней сложности рекомендуется использовать до 6 уровней WBS: 3 верхние уровня для предоставления информации уровня заказчика, 3 нижние уровня для детализации информации уровня исполнителя. Глубина детализации WBS зависит от размера и сложности проекта, поскольку должна обеспечивать четкую формализацию целей и результатов работы, которые необходимо выполнить. Каждый пакет работ включает весь объем работ, выполняемый основной организацией, ответственной за данный пакет работ, так же, как и организациями, с которыми заключены подрядные договора.
1.2.8. Резюме
2. Необходимость использования WBS
PMBOK описывает WBS, как средство (инструмент) определения содержания проекта (PMBOKGuide 1996, 54). Он определяет управление содержанием проекта как «процесс, направленный на гарантированное обеспечение того, что проект включает все необходимые работы, и только те работы, которые необходимы для успешного завершения проекта». Основываясь на этом определении, разработка WBS имеет две основные цели:
a. обеспечение планирования всех необходимых работ проекта,
b. обеспечение отсутствия ненужных (лишних) работ, работ, не связанных с реализацией проекта.
Для руководителя проекта важны обе эти цели. Если в плане отсутствуют все необходимые работы, проект будет задержан, бюджет скорее всего будет превышен. Если выполняются работы, не относящиеся к данному проекту – деньги заказчика тратятся не целевым образом. Если WBS не объединяет обе эти цели, проект может потерпеть неудачу.
Рис.3.5 в PMBOKGuide (в данном документе воспроизведено частично и изменено см. Рис. 2‑1) иллюстрирует, как проект разворачивается вокруг WBS. WBS является основным «стрежнем» для четырех основных и одного вспомогательного процессов:
a. определение работ,
b. планирование ресурсов,
c. оценка стоимости,
e. определение рисков.
Рис. 2‑1 Взаимодействие WBS с процессами реализации проекта (PMBOK Guide 1996)
Как показывает рис. 3.5 PMBOKGuide (Рис. 2‑1), план проекта строится на базе этих процессов. Т.о., WBS является основой:
Успешное управление проектом зависит от способностей руководителя проекта эффективно руководить командой проекта, определяя содержание работ проекта в терминах его результатов. С помощью WBS работы структурируются и непосредственно связываются с графиком, а ресурсы распределяются и отслеживаются.
3. Разработка Структуры Декомпозиции Работ
3.1. Правила разработки WBS
При разработке WBS необходимо принимать во внимание следующие основные правила:
3.2. О чем нужно не забыть
К сложностям, связанным с разработкой WBS, относятся
3.3. Определение соответствующего уровня детализации
Разработка WBS является итерационным процессом разбиения проекта на составные элементы с выделением последующих уровней до тех пор, пока не будет достигнут уровень, обеспечивающий необходимую и достаточную детализацию информации для эффективного управления. В разделе 3.3.1 приведены вопросы для определения необходимости в дальнейшей детализации WBS. Если ответы на большинство пунктов в данном опросном листе являются положительными, необходима дальнейшая декомпозиция WBS. Чем больше количество положительных ответов, тем более обоснованным является дальнейшая детализация WBS.
3.3.1. Определение необходимости в дальнейшей детализации
Нужно ли дальше детализировать WBS?
Как было определено ранее, уровень детализации WBS зависит от размера и баланса между сложностью, риском, и требованиями руководителя проекта к контролю проекта. Уровень детализации может также изменяться в процессе жизненного цикла проекта.
Для краткосрочных проектов на начальной стадии можно разработать всю WBS до достаточного уровня детализации, в то время, как долгосрочные проекты и проекты с высоким уровнем сложности могут не декомпозироваться полностью на начальной стадии. Полностью WBS для таких проектов можно описать в процессе их реализации. С другой стороны, это может означать, что для конкретного проекта, отдельные пакеты работ могут иметь различные уровни детализации. В частности, это верно при разработке «развертывающихся» проектов, когда план детализируется для работ, которые должны непосредственно начаться, а работы будущих периодов определяются укрупнено, на верхнем уровне, до тех пор, пока на более поздней стадии жизненного цикла проекта можно будет прописать их более детально.
3.4. Рассмотрение жизненного цикла WBS
3.5. Взаимосвязь между риском проекта и WBS
Для проектов с высоким уровнем риска настоятельно рекомендуется разработка более детальной WBS. Рисковые случаи – ситуации, которые могут повлиять на достижение результатов проекта – необходимо оценивать для определения и квалификации рисков.
Риски проектов связаны с вероятностью возникновения событий, позитивно или неблагоприятно влияющих на цели проекта, включающие основные элементы такие, как технические характеристики, качество, стоимость и сроки реализации. Подход к декомпозиции WBS может помочь в определении и уменьшении рисков. Например, проекты, требующие получения разрешительных документов и лицензий от надзорных органов, могут иметь высокую степень риска. Так как рисковая ситуация может возникать не для всего проекта в целом, а только для некоторых пакетов работ, для руководителя проекта удобнее анализировать ее влияние на каждый пакет работ, обособляя таким образом риски, обеспечивая их обработку, что, в конечном счете обеспечивает более эффективное управление рисками.
Первый шаг при использовании такого метода – анализ каждого из пакетов работ до уровня, на котором можно выделить рисковое событие. Такой анализ должен учитывать критические области (проектирование и конструкторские работы, технологию, логистику и т.д.) и элементы, которые могут помочь в описании рисковых событий. Используя информацию из различных источников таких, как планы программ, предыдущие оценки рисков, анализ экспертов и тому подобное, обследуются рисковые случаи и определяются характерные риски для каждой критической области. Затем они анализируются для определения вероятности их наступления, степени влияния и взаимозависимости.
Риск, связанный с объемом работ, может также определить необходимый уровень детализации. Дополнительная детализация пакета работ с высоким уровнем риска, обеспечивает лучшую оценку рисковой ситуации, а также более точную оценку стоимости и сроков. Это вынужденное структурирование позволяет определить предполагаемые и ожидаемые показатели на контролируемом уровне.
Метод объединения планирования рисков и разработки WBS позволяет определить работы-последователи, на которые могут повлиять изменения, произошедшие в случае возникновения рисковой ситуации. Длительность «рисковых» работ определяется таким образом, чтобы компенсировать степень неопределенности и потенциального влияния рискового события. Например, работа, для которой существует возможность возникновения рисковой ситуации, должна быть определена в качестве последующей для работы, на которую она может оказать влияние. В этом случае длительность работы, на которую оказывается влияние, определяется в соответствии с нормальным сроком выполнения, а длительность «влияющей» работы определяется с учетом вероятности и влияния риска задержки.
3.5.1. Взаимосвязь риска проекта и WBS
При учете рисков проекта каждый уровень WBS должен быть проанализирован с точки зрения следующих вопросов:
3.6. Взаимосвязь планирования и контроля ресурсов и WBS
WBS декомпозируется до уровня, необходимого для планирования и контроля. В общем случае это будет детализация до уровня, по крайней мере, на один уровень ниже, требуемого для отчетности – позволяющего осуществлять эффективное планирование, контроль, и измерение выполнения отдельных работ с однозначно определяемыми ресурсами.
Хотя полное определение ресурсов будет возможно позднее на стадии детального планирования, нужно в целом понимать, как это будет выполняться, и что данный уровень детализации WBS поддерживает необходимый объем работ.
3.6.1. Планирование и контроль ресурсов
Чтобы соответствующим образом подготовиться к планированию ресурсов в соответствии с WBS, необходимо рассмотреть следующие вопросы при определении уровня детализации WBS:
3.7. Разработка WBS
WBS разрабатывается путем итерационного рассмотрения целей и результатов проекта, критериев планирования/достижения функциональности, объема работ, реализации технических требований и других технических атрибутов. Верхние уровни WBS могут быть разработаны на ранней, концептуальной стадии проекта. Дальнейшая детализация WBS возможна, как только будет определен проект и подготовлены спецификации.
Основной процесс разработки WBS состоит из следующих шагов:
3.8. Заключение
Как только закончена разработка WBS, можно приступать к определению детальных работ и к назначению ответственных исполнителей за пакеты работ. Взаимосвязь между техническими требованиями, WBS, содержанием работ, ресурсными планами, директивным и детальными графиками обеспечивает предоставление комплексной информации по стоимостным данным, данным по с