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

Понимание WBS в многолетних проектах

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

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

Стратегии эффективного внедрения WBS

1.Определить четкие этапы проекта

Многолетние инженерные проекты естественным образом попадают в фазы - осуществимость, детальная инженерия, закупки, изготовление, строительство, ввод в эксплуатацию и закрытие. Каждый этап имеет свои собственные результаты, профиль риска и потребности в ресурсах. WBS должен отражать эти этапы на самом высоком уровне (уровень 1 или уровень 2) для согласования с жизненным циклом проекта. Это выравнивание позволяет легко назначать вентили фазового управления и измерять прогресс в отношении этапных этапов. Например, уровень 1 WBS может включать в себя «Дизайн», «Закупки», «Строительство» и «Ввод в эксплуатацию». В рамках «Дизайн» следующий уровень может вспыхнуть «Гражданское проектирование», «Структурная инженерия», «Механические системы», «Электрические системы» и «Системы управления». Каждый из них затем разлагается до тех пор, пока рабочие пакеты не будут достаточно малы, чтобы их можно было планировать, бюджетировать и контролировать - обычно представляющие работу, которая может быть завершена за две-четыре недели.

Фазовое разложение также упрощает отчетность руководителям и клиентам. Их волнует общая картина: «Мы закончили с дизайном?» Фазовый шлюз WBS делает этот ответ однозначным. Кроме того, он поддерживает планирование прокатных волн, где краткосрочные фазы разлагаются подробно, а более поздние фазы остаются на более высоких уровнях, пока не станет доступна дополнительная информация. Это практическая необходимость для многолетних проектов, где детальное планирование работы на четыре года не только расточительно, но часто вводит в заблуждение.

2. Используйте иерархическую структуру для управления зависимостями

Иерархия WBS - это больше, чем просто способ организации задач - она создает структуру для понимания зависимостей и критических путей. В многолетних проектах зависимости часто охватывают месяцы или даже годы. Задержка в обзоре дизайна фундамента может пульсировать через закупки, изготовление и установку сайта. Структурируя WBS для отражения архитектуры продукта проекта (например, «Система трубопроводов процессов», «Электрическое распределение», «HVAC»), менеджер проекта может визуально отслеживать зависимости между системами. Например, если пакет работ «Бетонные основы» в отделении гражданского строительства должен завершиться до того, как «Установка оборудования» в отделении машиностроения может начаться, эта зависимость четко видна на уровне элементов WBS. Эта видимость позволяет планировщику построить логическую сеть, которая отражает реальность, а не желаемое мышление.

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

3. Включить гибкость для изменений

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

Гибкость также означает использование схемы нумерации WBS, которая позволяет вставлять новые элементы без перенумерации всей структуры. Типичный подход заключается в использовании дополнительных десятичных уровней (например, 1.1, 1.2, 1.2.1, 1.2.2). Если новый рабочий пакет должен быть добавлен между 1.2.1.1 и 1.2.1A, ему можно назначить 1.2.1.1 или 1.2.1A. Современное программное обеспечение для управления проектами обрабатывает это изящно, но конвенция должна быть установлена на ранней стадии и сообщена команде. Другой метод заключается в резервировании процента кодов WBS для будущего расширения. Например, в данной ветви используются только коды 1.1 - 1.9, оставляя место для 1,10, если это необходимо. Эти небольшие дизайнерские решения не позволяют WBS стать прямой рубашкой.

4. Установить четкое владение и подотчетность

Каждый элемент WBS должен иметь одного человека, ответственного за предоставление этой области. В многолетних проектах, кадровые изменения; менеджер контрольного счета, назначенный в год один, может быть упущен к третьему году. Структура собственности WBS должна быть задокументирована в матрице назначения ответственности (RAM), которая связывает элементы WBS с поименованными лицами или ролями. По мере вращения членов команды матрица обновляется. Эта практика гарантирует, что ни один рабочий пакет не становится осиротевшим и что отчетность остается ясной. Для крупных инженерных проектов контрольные счета обычно устанавливаются на уровне 3 или 4 WBS, где рабочие пакеты достаточно малы для точного отслеживания, но достаточно велики, чтобы оправдать выделенного менеджера. Каждый менеджер контрольного счета сообщает о прогрессе, дисперсиях и прогнозах для их назначенных элементов. Эта отчетность снизу вверх подпитывает общую панель производительности проекта, давая менеджеру проекта представление о здоровье в режиме реального времени на протяжении всей многолетней временной шкалы.

Инструменты и методы повышения эффективности WBS

Создание WBS — это только начало. Чтобы извлечь полную ценность из многолетнего проекта, команда должна интегрировать его с набором вспомогательных инструментов и процессов. Программное обеспечение для управления проектами остается основным средством. Такие системы, как Microsoft Project или Oracle Primavera P6, позволяют WBS напрямую связываться с графиком, планом ресурсов и базовым уровнем затрат. При обновлении рабочего пакета автоматически рассчитывается эффект ряби через зависимые задачи. Эти инструменты также поддерживают анализ «что-если», что является бесценным при оценке влияния потенциальных изменений области применения. Для команд, которые предпочитают облачное сотрудничество, такие инструменты, как Smartsheet или Asana предлагают шаблоны WBS и интеграцию диаграмм Ганта, хотя для многолетних инженерных проектов с тысячами рабочих пакетов обычно требуются решения корпоративного уровня.

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

Интеграция с инструментами планирования является еще одним критическим методом. WBS обеспечивает структуру графика; график добавляет временной размер. Без этой интеграции WBS становится статическим документом, который быстро игнорируется. Связывая каждый элемент WBS с запланированными мероприятиями, команда проекта может генерировать метрики управления заработанной стоимостью (EVM) на уровне пакета работ. Например, если пакет работ «Фундаментальное строительство» завершен на 60%, но потребляет 80% своего бюджета, индексы EVM будут отмечать перерасход средств на ранней стадии. В течение многолетнего срока раннее выявление таких тенденций позволяет корректирующие действия до того, как дисперсия станет неуправляемой. WBS является основой, на которой построен EVM.

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

Обычные подводные камни и как их избежать

Даже опытные менеджеры проектов попадают в ловушку при использовании WBS для многолетних проектов. Одна частая ошибка — создание WBS, который слишком ориентирован на процесс, а не на результат. Например, WBS, который перечисляет «Design Review» как элемент вместо «Structural Design Package» приводит к путанице в отношении того, что именно поставляется. Корректирующее действие — использовать существительные для элементов WBS (доставляемых) и глаголов для действий в расписании. Другая распространенная ошибка — неспособность обновить WBS по мере развития проекта. Многолетние проекты по своей природе требуют периодической реструктуризации. WBS, созданный в начале пятилетнего проекта, потребует уточнений на каждом фазовом переходе. Команды, которые рассматривают WBS как священный, неизменяемый документ, вскоре найдут его неактуальным. Реализуйте формальный процесс управления изменениями, который позволяет WBS обновляться при изменении объема, и запланируйте постоянный ежеквартальный обзор для оценки его продолжительной действительности.

Третья ловушка — сделать WBS либо слишком гранулированным, либо недостаточно гранулированным. WBS с тысячами пакетов работ для многолетнего проекта может стать административно обременительным, в то время как один с несколькими десятками элементов не может обеспечить достаточный контроль. Общее правило большого пальца — «правило 8/80»: пакеты работ должны требовать от 8 до 80 часов работы для завершения, или более практически, должны представлять собой промежуток от двух до четырех недель. Для очень больших усилий контрольные счета на уровне 3 или 4 могут содержать несколько пакетов работы. Менеджер проекта должен сосредоточиться на контроле на уровне контрольного счета и позволить менеджерам пакетов работ обрабатывать детали. Этот баланс предотвращает микроуправление при сохранении видимости.

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

Заключение

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

Для дальнейшего чтения о лучших практиках WBS, стандарт практики PMI для структур разбивки работы предоставляет всеобъемлющую ссылку. Для более глубокого взгляда на применение WBS к сложным капитальным проектам см. эта статья PMI о капитальных проектах . Кроме того, статья Engineering.com об управлении рисками для долгосрочных проектов предлагает дополнительные идеи. Наконец, для инструментов, которые поддерживают управление проектами на основе WBS, исследуйте Oracle Primavera P6 или Microsoft Project.