stringtranslate.com

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

Пример из MIL-HDBK-881, который иллюстрирует первые три уровня типичной авиационной системы [1]

Структура декомпозиции работ ( WBS ) [2] в управлении проектами и системной инженерии представляет собой ориентированную на результат разбивку проекта на более мелкие компоненты. Структура декомпозиции работ — это ключевой элемент управления проектом, который организует работу команды по управляемым разделам. Свод знаний по управлению проектами определяет иерархическую структуру работ как «иерархическую декомпозицию общего объема работ, которые должна выполнить команда проекта для достижения целей проекта и создания необходимых результатов». [3] : 434  [4]

WBS обеспечивает необходимую основу для детальной оценки и контроля затрат, а также дает рекомендации по разработке и контролю графика . [5]

Обзор

WBS — это иерархическое и поэтапное разложение проекта на результаты (от крупных, таких как этапы, до самых маленьких, иногда называемых рабочими пакетами). Это древовидная структура , показывающая разделение усилий, необходимых для достижения цели, например программы , проекта и контракта . [6] В проекте или контракте WBS разрабатывается, начиная с конечной цели и последовательно разделяя ее на управляемые компоненты с точки зрения размера, продолжительности и ответственности (например, системы, подсистемы, компоненты, задачи , подзадачи и работа). пакеты), которые включают все шаги, необходимые для достижения цели.

Пример структуры разбивки работ, применяемой в структуре отчетности НАСА [6]

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

Иерархическая структура работ позволяет суммировать подчиненные затраты на задачи, материалы и т. д. в их «родительские» задачи, материалы и т. д. более высокого уровня. Для каждого элемента иерархической структуры работ приводится описание выполняемой задачи. генерируется. [7] Этот метод (иногда называемый иерархической структурой системы [8] ) используется для определения и организации общего объема проекта .

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

Разработка WBS обычно происходит в начале проекта и предшествует детальному планированию проекта и задач. ЧерезПрогрессивная разработка , итеративный процесс знаний по управлению проектами , детали плана управления проектом и объем информации увеличатся, [10] и первоначальные оценки таких элементов, как описание объема проекта, планирование, бюджет и т. д., станут более точными. [11] Это также помогает команде проекта составить более подробный план проекта. [12]

История

Концепция иерархической структуры работ была разработана Министерством обороны США (DoD) с помощью Методики оценки и анализа программ (PERT) . PERT был введен ВМС США в 1957 году для поддержки разработки ракетной программы Polaris . [13] Хотя термин «структура декомпозиции работ» не использовался, эта первая реализация PERT действительно организовала задачи по категориям, ориентированным на продукт. [14]

К июню 1962 года Министерство обороны, НАСА и аэрокосмическая промышленность опубликовали документ по системе PERT/COST, в котором описывался подход WBS. [15] Это руководство было одобрено министром обороны для принятия всеми службами. [16] В 1968 году Министерство обороны выпустило «Структуры декомпозиции работ для объектов оборонной техники» (MIL-STD-881), военный стандарт , требующий использования структур декомпозиции работ во всем Министерстве обороны. [17]

Документ несколько раз пересматривался. По состоянию на май 2023 года самой последней версией является F, выпущенная 13 мая 2022 года. История версий и текущая версия стандарта размещены на веб-сайте ASSIST Агентства оборонной логистики (DLA).[1] Он включает определения WBS для конкретных товарных систем оборонной техники и рассматривает элементы WBS, которые являются общими для всех систем.

Категории предметов оборонной техники из MIL-STD-881F:

Общими элементами, указанными в MIL-STD-881F, Приложение K, являются: интеграция, сборка, тестирование и проверка; Системная инженерия; Программный менеджмент; Тестирование и оценка системы; Данные; Своеобразное вспомогательное оборудование; Общее вспомогательное оборудование; Активация операционной/площадки; Логистическая поддержка подрядчика; Промышленные объекты; Первоначальные запасные части и ремонтные детали. Стандарт также включает дополнительные общие элементы, уникальные для космических систем, систем ракет-носителей и стратегических ракетных систем.

В 1987 году Институт управления проектами (PMI) задокументировал распространение этих методов на необоронные организации. В « Своде знаний по управлению проектами» (PMBOK) представлен обзор концепции WBS, а «Практический стандарт для структур иерархии работ» сопоставим со стандартом Министерства обороны, но предназначен для более общего применения. [18]

Принципы дизайна

100% правило

Важный принцип проектирования структур декомпозиции работ называется правилом 100%. [19] Оно было определено следующим образом:

Правило 100% гласит, что WBS включает 100% работ, определенных объемом проекта, и фиксирует все результаты – внутренние, внешние, промежуточные – с точки зрения работы, которую необходимо выполнить, включая управление проектом. Правило 100% — один из наиболее важных принципов, определяющих разработку, декомпозицию и оценку WBS. Правило применяется на всех уровнях иерархии: сумма работы на «дочернем» уровне должна равняться 100% работы, представленной «родителем», а WBS не должна включать в себя какие-либо работы, выходящие за рамки фактического объема работы. проекта, то есть он не может включать в себя более 100% работ. Важно помнить, что правило 100% распространяется и на уровень активности. Работа, представленная действиями в каждом пакете работ, должна составлять до 100 % работы, необходимой для завершения пакета работ. [20]

Взаимоисключающие элементы

Взаимоисключающие : в дополнение к правилу 100% не должно быть дублирования в определении объема работ между различными элементами иерархической структуры работ. Эта двусмысленность может привести к дублированию работы или недопониманию ответственности и полномочий. Такое дублирование может также затруднить учет затрат по проекту.

Планируйте результаты, а не действия

Если проектировщик структуры декомпозиции работ попытается отразить в WBS какие-либо детали, ориентированные на действия, он, скорее всего, включит либо слишком много действий, либо слишком мало действий. Слишком много действий превысят 100 % родительской области, а слишком малое число действий не достигнет 100 % родительской области. Лучший способ придерживаться правила 100% — это определять элементы WBS с точки зрения результатов или результатов, а не действий. Это также гарантирует, что WBS не будет чрезмерно предписывать методы, что позволит проявить большую изобретательность и творческое мышление со стороны участников проекта. Когда проект предоставляет профессиональные услуги, обычным методом является сбор всех запланированных результатов для создания WBS, ориентированной на результаты. [21] Структуры декомпозиции работ, которые подразделяют работу по этапам проекта (например, этап предварительного проектирования, этап критического проектирования), должны гарантировать, что фазы четко разделены конечными результатами, которые также используются при определении критериев входа и выхода (например, утвержденный предварительный или критический анализ проекта) . ).

Структура разбивки продукта (PBS)

Для проектов разработки новых продуктов наиболее распространенным методом обеспечения WBS, ориентированного на результат, является использование структуры разбивки продукта (PBS).

Разработка, ориентированная на функции

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

Уровень детализации

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

Комплекс работ

По данным Института управления проектами , пакет работ — это «самый нижний уровень иерархической структуры работ, для которого оцениваются и управляются стоимость и продолжительность». [4]

Пакет работ на уровне деятельности – это задача, которая:

словарь WBS

Если имена элементов СДР неоднозначны, словарь СДР может помочь уточнить различия между элементами СДР. Словарь WBS описывает каждый компонент WBS с указанием этапов , результатов, мероприятий, объема, а иногда и дат, ресурсов , затрат и качества. По данным Института управления проектами , словарь WBS определяется как «документ, который предоставляет подробную информацию о результатах, действиях и планировании для каждого компонента в иерархической структуре работ». [4]

Схема кодирования

Обычно элементы структуры декомпозиции работ нумеруются последовательно, чтобы выявить иерархическую структуру. Цель нумерации — обеспечить единый подход к идентификации и управлению WBS в аналогичных системах независимо от поставщика или услуги. [22] Например, 1.1.2 Propulsion (в примере ниже) идентифицирует этот элемент как элемент WBS уровня 3, поскольку имеется три числа, разделенных двумя десятичными точками . Схема кодирования также помогает распознавать элементы WBS в любом письменном контексте и позволяет сопоставлять их со словарем WBS. [23]

Практический пример схемы кодирования WBS: [24]

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 и организационной единицы создаются контрольные счета и пакеты работ, а производительность планируется, измеряется, регистрируется и контролируется. [25] WBS может быть выражена до любого уровня интереса. Минимально рекомендуется три уровня, с дополнительными уровнями для и только для элементов высокой стоимости или высокого риска [26] и два уровня детализации в таких случаях, как системное проектирование или управление программами, [27] со стандартом, показывающим примеры WBS. с различной глубиной, например, разработка программного обеспечения до 5 уровней [28] или системы управления огнем до 7 уровней. [29]

Соответствует нормам

Высшая структура WBS должна соответствовать любым нормам и шаблонам, существующим в организации или домене. Например, судостроение для ВМС США должно учитывать, что морские термины и их иерархическая структура, заложенные в MIL-STD [30] , встроены в военно-морскую архитектуру [31] и что соответствующие офисы и процедуры ВМФ были построены в соответствии с этой структурой военно-морской архитектуры. , поэтому любые существенные изменения нумерации или именования элементов СДР в иерархии будут неприемлемы.

Пример

Технология строительства WBS, использующая правило 100% при строительстве WBS.

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

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

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

Проект WBS может поддерживаться программным обеспечением (например, электронной таблицей ), позволяющим автоматически суммировать значения баллов. Оценки усилий и затрат можно составить путем обсуждений между членами проектной группы. Этот метод совместной работы позволяет лучше понять определения объема, основные предположения и прийти к консенсусу относительно уровня детализации, необходимого для управления проектами. [32]

Смотрите также

Рекомендации

  1. ^ Основы системной инженерии. Архивировано 11 февраля 2006 г. в издательстве Wayback Machine Defense Acquisition University Press, 2001 г.
  2. ^ «Глоссарий сокращений и терминов оборонных закупок: Структура иерархии контрактных работ (CWBS)» . Университет оборонного снабжения . Проверено 19 сентября 2017 г.
  3. ^ Керцнер, Гарольд (2009). Управление проектами: системный подход к планированию, составлению графиков и контролю (10-е изд.). Уайли. ISBN 978-0-470-27870-3.
  4. ^ abc Project Management Institute 2021, § Глоссарий, раздел 3. Определения.
  5. ^ Учебное пособие по управлению прибавочной стоимостью Booz, Allen & Hamilton, модуль 2: Структура иерархии работ, Управление науки, инструменты и ресурсы для управления проектами, science.energy.gov. По состоянию на 27 декабря 2011 г.
  6. ^ abc НАСА (2001). НАСА НПР 9501.2D. 23 мая 2001 г.
  7. ^ Модель стандартных возможностей системного проектирования Альянса электронной промышленности EIA-731.1
  8. ^ Стандарт Института инженеров по электротехнике и электронике для применения и управления процессом системного проектирования IEEE Std 1220-2005
  9. ^ «Как использовать иерархическую структуру работ как инструмент управления проектами» .
  10. ^ Руководство по своду знаний по управлению проектами (шестое издание). Институт управления проектами, Inc. 715. ИСБН 978-1-62825-184-5.
  11. ^ Рита, Малкахи. Подготовка к экзамену PMP (Девятое изд.). Публикации РМЦ. п. 88. ИСБН 978-1-943704-04-0.
  12. ^ «Руководство сообщества по адаптивному планированию PMI-ACP».
  13. ^ Флеминг, Квентин В., Джоэл М. Коппельман «Управление проектами с освоенным объемом» CROSSTALK: Журнал оборонной разработки программного обеспечения, июль 1998 г., стр. 20
  14. ^ Хоган, Грегори Т., Эффективные структуры разбивки работы, стр. 7-8.
  15. ↑ Министерство обороны и Руководство НАСА, Проектирование системы PERT/COST, июнь 1962 г.
  16. ^ Гамильтон, Р.Л., Исследование методов оценки PERT/системы управления затратами , MITRE Corporation , июнь 1964 г.
  17. ^ MIL-STD-881, 1 ноября 1968 г.
  18. ^ Хоган, Грегори Т., Структура распределения работ в государственных контрактах, Концепции управления, 2003 ISBN 978-1567261202 
  19. ^ Эффективные структуры разбивки работ Грегори Т. Хогана, опубликованные Management Concepts, 2001, ISBN 1567261353 , стр.17 
  20. ^ Практический стандарт для структур декомпозиции работ (второе издание) , опубликованный Институтом управления проектами , ISBN 1933890134 , стр. 8 
  21. ^ Свидерски, Марк А., PMP workbreakdownstructure.com, PMBOK-Структуры иерархии работ. По состоянию на 16 июня 2013 г.
  22. ^ MIL-STD-881C, Структуры декомпозиции работ для объектов оборонной техники, 3 октября 2011 г., п. 4.3
  23. ^ Эш, Кеннет, Структура работы, по состоянию на 23 мая 2016 г.
  24. ^ MIL-STD-881C, Структуры иерархии работ для объектов оборонной техники, 3 октября 2011 г., Приложение A, ¶A.3
  25. ^ MIL-STD-881C, Структуры декомпозиции работ для объектов оборонной техники, 3 октября 2011 г., п. 3.1.4
  26. ^ MIL-STD-881C, Структуры декомпозиции работ для объектов оборонной техники, 3 октября 2011 г., п. 1.4.1
  27. ^ MIL-STD-881C, Структуры декомпозиции работ для объектов оборонной техники, 3 октября 2011 г., п. 2.2.4.2
  28. ^ MIL-STD-881C, Структуры декомпозиции работ для объектов оборонной техники, 3 октября 2011 г., ¶Рис.3-6
  29. ^ MIL-STD-881C, Структуры декомпозиции работ для объектов оборонной техники, 3 октября 2011 г., ¶Рис.3-1
  30. ^ MIL-STD-881C, Структуры иерархии работ для объектов оборонной техники, 3 октября 2011 г., ¶Приложение E
  31. ^ Гилмер, Томас (4 августа 1982). Введение в военно-морскую архитектуру. Издательство Военно-морского института. п. 98. ИСБН 9780870213182.
  32. ^ Чикала, Гас (2020), «Разработка иерархической структуры работ», Руководство для менеджеров проектов по Microsoft Project 2019 , Беркли, Калифорния: Apress, стр. 119–148, doi : 10.1007/978-1-4842-5635-0_6 , ISBN 978-1-4842-5637-4, S2CID  219011411 , получено 7 июня 2022 г.

дальнейшее чтение

Внешние ссылки