1. Что такое структура разбивки работ?
2. Как создать WBS и в чем его важность?
3. Шаг 2: Разбейте каждое требование высокого уровня на основные категории результатов
4. Шаг 3. Разбейте каждый основной результат на одно или несколько измеримых действий.
5. Шаг 4. Просмотрите рабочие пакеты на предмет полноты охвата области.
6. Требуется ли WBS для каждого проекта?
7. Что можно и чего нельзя делать

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

Что такое структура разбивки работ?

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

Хотя это звучит так просто, СПП обладает огромной силой и влиянием, чтобы преобразовать сложные требования / объем в маленькие и более простые части для оценки, планирования и выполнения проекта. WBS:

Связанная статья: Управление рисками проекта в 12 вопросах

• Дает ясность в отношении потребностей проекта с точки зрения результатов и критериев успеха - он подчеркивает «что» в проекте
• Организует объем проекта, создает вокруг него определенную структуру разложения
• Дает больше простоты и разбивки деятельности, которая будет выполняться с использованием каждого иерархического разложенного уровня
• Последовательно делит область действия на управляемые компоненты с точки зрения размера, продолжительности и ответственности
• Структурированная диаграмма, изображающая иерархический список общих требований проекта к возрастающим уровням детализации
• Помогает в распределении обязанностей, распределении ресурсов, мониторинге и контроле проекта.
• Является важным инструментом для анализа разложенного объема (с определенными конечными результатами) с заинтересованными сторонами проекта. Это также дает значимое наглядное представление о масштабах и результатах проекта.

Как создать WBS и в чем его важность?

Шаг 1: Перечислите требования наивысшего уровня / предметную область.

Это одна из наиболее распространенных практик, когда первое утверждение области или объем работы, которую получает проектная команда, может содержать информацию в смешанном формате, и, следовательно, ее нельзя принять как есть и использовать для оценки и реализации проекта. Команда проекта должна обсудить область применения с клиентом / аналитиками клиента / пользователями системы, чтобы понять необходимость упомянутой области, а также основные цели / требования / результаты, которые ожидаются от проекта. Подразумевается, что эти разъяснения требований и обсуждения с командами Заказчиков требуются на протяжении всего проекта, как и когда это требуется с точки зрения оценки. Поместите эти цели / требования / результаты на первый уровень иерархии в диаграмме СПП (см. Рисунок 1). Этот шаг дает определенную отправную точку процессу оценки проекта путем преобразования документа области в первый набор требований высокого уровня. Один из моментов, о которых следует помнить, заключается в том, что разработка иерархической диаграммы предназначена только для простоты понимания и более быстрого понимания декомпозиции области. Разбитые компоненты могут быть перечислены и пронумерованы в любом формате и в любом инструменте (Word, Excel, MPP и т. Д.) И могут отслеживаться различными способами. Важен не формат, а связь и связь между родительскими и дочерними элементами области, которые делают структуру СПП одним из наиболее заметных и полезных инструментов для процесса оценки проекта.

Рисунок 1: Требования высокого уровня

Шаг 2: Разбейте каждое требование высокого уровня на основные категории результатов

Как только требования высокого уровня станут доступны, как определено в шаге 1 выше, для каждого из требований высокого уровня команды должны затем рассмотреть каждое из них по одному и начать копаться в сводки следующего уровня о том, что является продуктом или что такое продукты, которые необходимо создать / изменить / внедрить для удовлетворения требований. Вполне возможно, что для данного высокого уровня требований могут потребоваться изменения в четырех различных системах / компонентах, каждая из которых может быть реализована независимо. В рамках этого шага команда должна задавать себе вопрос - «что нужно сделать», чтобы выполнить это требование? Нужно быть уверенным, что создаваемый следующий уровень разделения должен относиться к продуктам / видам деятельности, которые необходимо определить далее (см. Рисунок 2).

Рисунок 2: Требования высокого уровня, разбитые на подкатегории

Шаг 3. Разбейте каждый основной результат на одно или несколько измеримых действий.

Следующим шагом является принятие каждого результата доставки / изменения системы, определенного на шаге 2, и создание определенных действий или рабочих продуктов для каждого из них с информацией, связанной с соответствующими усилиями, необходимыми для каждого из действий, вместе с уровнем риска и сложностью. для каждого из них. Одна вещь, которую необходимо помнить, заключается в том, что по мере продвижения по структуре СПП деятельность должна совершенствоваться до достижения разумной и измеримой активности. Теперь вопрос «каково правило для измеримой активности?». Я бы сказал, что такого подтвержденного правила не существует, и оно будет в основном зависеть от типа, размера и сложности проекта, организационного процесса, а также от уровня разделения, на котором строится СПП. Обычно деятельность с продолжительностью 40 часов или максимум до 80 часов рассматривается как измеримая деятельность, поскольку эти длительности достаточно разумны для мониторинга со стороны руководителя проекта или менеджера проекта. Создаваемые таким образом измеримые действия иногда называют рабочими пакетами, и один из принципов СПП заключается в том, что требования должны постоянно разлагаться до тех пор, пока мы не получим окончательный список рабочих пакетов, которые можно отслеживать. Вполне возможно, что каждый основной результат, который мы начали на этом этапе, может иметь больше рабочих пакетов, и в некоторых случаях может потребоваться разложить текущий результат на несколько подуровней, пока не будет достигнут определенный рабочий пакет. В этом случае структура СПП перейдет на более глубокие подуровни, что вполне допустимо, поскольку цель выполнения СПП состоит в том, чтобы гарантировать, что каждое требование успешно детализировано до его соответствующего окончательного результата / рабочего пакета (см. Рисунок 3).

Рисунок 3: Основные результаты, разбитые на измеримые виды деятельности / рабочие пакеты

Шаг 4. Просмотрите рабочие пакеты на предмет полноты охвата области.

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

Требуется ли WBS для каждого проекта?

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

Что можно и чего нельзя делать

Задание по построению команды: процесс создания СПП следует рассматривать как упражнение по созданию команды. Для проектов нормального размера WBS не может быть создан одним членом команды. Требуется, чтобы разные члены команды рассмотрели каждое требование высокого уровня в рамках данной области, обсудили его с другими членами команды, а затем каждый из ведущих членов команды должен представить детали разбивки задания / рабочего пакета, связанные с это конкретное требование. Аналогичным образом, подробности о деятельности поступают к другим членам ведущей команды, и команда проекта объединяет всю полученную информацию о результатах и ​​сопоставляет ее с полностью развернутой СПП, которая затем может быть использована для последующих этапов планирования и планирования проекта.

Не график проекта: СПП не является планом проекта или графиком проекта. Он предоставляет только подробную информацию о заданном начальном объеме и об окончательных результатах, которые необходимо реализовать для достижения целей и задач проекта. Следует понимать, что WBS помогает дать точные данные для создания расписания проекта посредством информации о задании / рабочем пакете.

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

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

В заключение, если следовать структурированному процессу или процедуре СПП, шансы на успешную оценку проекта, планирование и реализацию намного выше, что поможет глобальным проектным командам минимизировать риски проекта, а также извлечь выгоду из-за того, что они втянуты в ненужный контроль изменений. Обсуждения / scope-creep / project-delay, которые являются одними из наиболее распространенных проблем, которых можно избежать, сохраняющихся в пространстве управления проектами сегодня.

Спасибо за прочтение!

Не забудьте оставить свои комментарии ниже.

Похожие

Комментарии