kimyuriyrussia-blog - Tumblr blog

kimyuriyrussia-blog · 8 years ago

Text

К1.4 Управление содержанием проекта

1. Введение

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

Компетенция «Содержание» включает следующие элементы:

· Определение содержания

· Определение структуры декомпозиции работ

· Определение работ/операций

· Управление содержанием проекта

Роли в УП и степень владения компетенцией:

СРП-4 Координатор проекта –

СРП-3 Руководитель простого проекта -

СРП-2 Руководитель проекта повышенной сложности -

СРП-1 Руководитель комплексного проекта -

2. Ключевые определения и концепции

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

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

Результаты (продукты) проекта - это материальные и нематериальные активы проекта, получаемые в результате реализации проекта, с помощью которых достигаются ожидаемые выгоды.

Ограничения - …

Предположения - …

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

ИСО ГОСТ 21500: Предметная группа процессов управление содержанием проекта включает процессы, обеспечивающие определение и включение в проект только тех работ и результатов, которые необходимы для успешного выполнения проекта.

Соответствующая область знаний и группа процессов также выделены в PMBOK.

Структурная декомпозиция продуктов (иерархическая структура продуктов, PBS) -

Структурная декомпозиция работ (иерархическая структура работ, WBS) - модель, представляющая проект в виде иерархической структуры элементов (работ), необходимых и достаточных для достижения целей проекта.

Словарь структурной декомпозиции работ -

Пакет работ -

Работа (операция) – определенный фрагмент деятельности в рамках плана проекта, выполнение которого необходимо для завершения проекта.

Расползание содержания –

Управление конфигурацией -

…

3. Элементы компетенции

Определение содержания

Определение содержания проекта включает определение продуктов и результатов проекта, а также работ, которые нужно выполнить для их получения.

Знания основные

Умения основные

Знает методы определения требований к продукту и результатам проекта

Способен определить требования к продукту и элементам продукта (результатам) проекта ограниченной сложности с учетом ограничений

Знает подходы к разработке иерархической структуры продукта проекта (ИСП, PBS)

Способен разработать иерархическую структуру продукта проекта (ИСП, PBS)

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

Определенные и зафиксированные ожидаемые результаты проекта являются основой для определения и планирования работ проекта. Профессионал должен быть способен провести анализ информации о целях и требованиях проекта (см. элемент компетентности «Требования и цели»), выявить и собрать недостающую информацию, определить и согласовать с заказчиком и, если необходимо, другими заинтересованными сторонами результаты проекта. Продукты и результаты проекта должны обеспечивать достижение целей проекта, но не быть избыточными. Не всегда заказчик готов четко сформулировать требования к результатам проекта. Если согласовать и зафиксировать все результаты проекта в условиях неопределенности в начале проекта невозможно, то процесс и методы планирования проекта должны быть адаптированы с учетом неопределенности. Например, возможно применение итерационных (гибких) методов планирования и реализации проекта.

Необходимо отличать понятия требования и ограничения.

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

Заказчик также может дополнительно формулировать ограничения. Ограничения могут накладываться как на решения, связанные с продуктом (применяемые материалы и т.п.), так и на процесс реализации проекта (например, организация команды, процесс принятия решений). Ограничения отражают какой-то опыт клиента, неизвестный команде, или они появляются из «неинженерных» (политических, финансовых, логистических и т.д.) соображений. Поэтому по поводу ограничений нужно каждый раз понимать, почему они были прописаны клиентом. Приоритет проекта - удовлетворить требованиям. Если предложенное вами решение лучше того, которое требуе�� заказчик в своих ограничениях, нужно попытаться убедить заказчика снять эти ограничения.

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

Определение структуры декомпозиции работ

Структурная декомпозиция работ является основой для разработки перечня работ проекта и дальнейшего планирования.

Знания основные

Умения основные

Знает основные методы построения структуры декомпозиции работ (СДР)

Способен разработать структуру декомпозиции работ (СДР) проекта ограниченной сложности

Понимает концепцию жизненного цикла проекта, понятие фазы проекта, типовые фазы проекта и взаимосвязи между ними. Знает отличие понятий ЖЦ проекта и группы процессов управления проектом.

Способен определить основные фазы (этапы) проекта, построить жизненный цикл проекта ограниченной сложности

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

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

· Привлечение экспертов в области технологий применяемых в проекте

· Использование опыта реализации похожих проектов и другие.

Ни один из методов не дает полной гарантии того, что все необходимые пакеты работ определены и ничего не забыто. Применение метода структурной декомпозиции работ позволяет наиболее системно подойти к процессу определения состава работ проекта. Метод декомпозиции работ позволяет разработать структурированное по уровням, упорядоченное по результатам представление всех работ проекта.

Создание СДР в начале работ по планированию позволяет руководителю проекта:

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

· Повысить полноту определения состава работ проекта

· Повысить точность оценок сроков и стоимости выполнения работ на детальном уровне и агрегированных оценок на уровне проекта в целом

· Указать на соответствующем уровне детализации ключевые результаты, которые должны быть ясно отражены в календарном плане

· Создать эффективную структуру отчетности

· Указать руководителей и исполнителей, ответственных за достижение ключевых результатов, и тем самым гарантировать, что достижение всех результатов будет контролироваться

· Обеспечить членам команды понимание их роли в контексте общей работы по выполнению проекта.

Метод структурной декомпозиции работ более подробно описан в разделе «Методы и инструменты».

Для проектов, реализующихся в условиях высокой неопределенности на уровне требований к результатам или на уровне технологий реализации, могут применяться итерационные подходы (гибкие методы) уточнения и структуризации содержания. Пример, определения содержания в проектах, управляемых по Agile, описан в разделе примеры.

Определение работ/операций

Определение работ и операций включает описание работы, которая должна быть выполнена.

Знания основные

Умения основные

Понимает подходы/ограничения к определению "глубины" (количества уровней) декомпозиции и длительности работ/операций

Способен разработать перечень работ/операций проекта ограниченной сложности и обеспечить распределение ответственности между участниками проекта

Понимает подходы к определению требований/критериев завершения работ/операций

Способен определить критерии завершения выполнения работ/операций.

Структурная декомпозиция работ позволяет определить пакеты работ (работы) на нижнем уровне декомпозиции. Пакеты работ (работы) назначаются ответственным исполнителям и поэтому должны быть четко определены и документированы. Документирование включает описание работы, ее результаты, длительность, стоимость, потребности в ресурсах.

…

Управление содержанием проекта

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

Знания основные

Умения основные

Знает методы контроля соблюдения требований к содержанию проекта (состава и объема работ)

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

Знает методы контроля выполнения требований к результатам и продукту проекта

Способен сформировать отчет о выполнении требований к содержанию, результатам и продукту проекта, релевантный потребностям получателя

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

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

Проекты реализуются в динамичном окружении, в котором постоянно возникают изменения, влияющие на содержание проекта. Даже незначительные неконтролируемые изменения могут постепенно приводить к значительным несоответствиям текущего содержания запланированному. Бесконтрольные изменения часто называются «сползанием содержания проекта». Процесс управления содержанием проекта также связан с контролем факторов, которые вызывают изменения проекта, и контролем влияния этих изменений на содержание и цели проекта. Целью управления содержанием проекта является максимизация положительного и минимизация отрицательного влияния изменений на содержание проекта. Управление содержанием проекта применяется для управления реализуемыми изменениями и осуществляется в связке с другими процессами контроля.

Управление конфигурацией особенно важно для итеративного («гибкого») подхода к реализации проекта, в котором оно ориентируется на получение ценности, а не на выполнение плана или задачи. Управление конфигурацией содержания часто выполняется как непрерывный процесс.

4. Методы и инструменты

1. Структурная декомпозиция работ (СДР)

Декомпозиция работ – метод последовательной детализации содержания проекта, путем разбиения (декомпозиции) основных результатов и задач на более мелкие и более управляемые пакеты работ и работы.

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

Для построения иерархической структуры работ, необходимо разбить каждую работу (элемент) на более маленькие, более простые элементы. Каждый из них, необходимо разбить на еще более мелкие и простые элементы, составляющие задачу.

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

Последовательность разработки СДР включает следующие шаги:

· Определение основы (единых принципов) декомпозиции работ на верхних уровнях СДР.

· Определение верхнего уровня декомпозиции. Разбиение всего проекта на наиболее значимые, с точки зрения управления, пакеты работ и работы.

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

· Обзор и проверка иерархической структуры работ на предмет полноты и неизбыточности. В СДР не должно быть пробелов или наложений. Каждый элемент может появиться в СДР только один раз.

��пределение основы декомпозиции работ заключается в выборе принципов, по которым весь проект и его задачи будут разбиваться на составляющие. Для каждого проекта может существовать несколько вариантов декомпозиции задач на более мелкие. Например, можно разбить весь проект на части по этапам жизненного цикла, а можно по составным элементам создаваемого продукта или по видам работ.

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

При разработке СДР необходимо придерживаться следующих правил:

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

· Каждый элемент СДР должен являться агрегированным результатом («суммой», «итогом») всех подчиненных «дочерних» элементов, на которые он декомпозирован (разбит). Правило 100% означает, что детальные работы каждого последующего уровня разбиения должны полностью обеспечивать выполнение работы и получение результата задачи вышестоящего уровня.

· Пакеты работ и работы должны быть уникальными и отличаться от других пакетов работ. Дублирование работ недопустимо.

· Родительский элемент должен иметь больше одного дочернего элемента. Это правило позволяет избежать избытка уровней и обеспечивает получение структуры, пригодной для выполнения операций агрегирования.

· СДР должна быть полной, но не избыточной. Все работы СДР – это работы, которые будут выполнены в ходе проекта. Работы, не включенные в СДР, в проект не входят и не выполняются.

· Сечение СДР на любом уровне детализации представляет полный перечень работ проекта определенного уровня укрупнения (в соответствии с уровнем, на котором произведено сечение). Каждый следующий уровень представляет следующую степень детализации операций проекта.

· Разработка СДР проводиться методом последовательного разбиения сверху-вниз, но может дополняться и методом снизу-вверх. Для типовых работ проекта могут использоваться стандартные технологические последовательности работ.

· Разбиение работ должно выполняться до тех пор, пока для каждой ветви структуры не будут определены элементарные результаты и работы проекта, обеспечивающие достижение всех целей проекта. Это правило не требует того, чтобы СДР имела симметричные ветви. Целью является разбиение работы таким образом, чтобы были определены ясные и поддающиеся контролю промежуточные результаты, и не более того.

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

В дополнение к СДР часто разрабатывается Словарь СДР - сопроводительный документ СДР, содержащий:

· ID работы – уникальный идентификатор работы в системе календарного планирования

· Описание пакета работ (работы) – необходимые пояснения к составу и содержанию работы, если она представляет собой большой пакет или комплекс задач

· Информация о контракте, согласно которому она выполняется

· Контрольные события и вехи

· Ответственный за выполнение работы

2. Управление конфигурацией

…

5. Примеры

Определение содержания в строительных проектах

…

Определение содержания в проектах, управляемых по Agile

0 notes