Матрица оценки уровня вовлеченности заинтересованных сторон проекта

№ п/п	Заинтересованная сторона	Не осведомлен (Unaware)	Сопротивляется проекту (Resistant)	Нейтральная позиция (Neutral)	Поддерживает проект (Supportive)	Ведущая роль в проекте (Leading)
1	2	3	4	5	6	7
1	Заинтересованная сторона А			С	D
2	Заинтересованная сторона B		C	D
3	Заинтересованная сторона С				CD

Примечание:

«Не осведомлен» – не знает о проекте и его потенциальном воздействии;

«Сопротивляется» – знает о проекте и его потенциальном воздействии и сопротивляется изменениям;

«Нейтрален» – знает о проекте, но не поддерживает и не сопротивляется;

«Поддерживает» – знает о проекте и его потенциальном воздействии, поддерживает изменения;

«Ведущая роль» – знает о проекте, его потенциальном воздействии и активно участвует в обеспечении успеха проекта;

«С» – текущий уровень вовлеченности (current);

«D» – желаемый уровень вовлеченности (desirable).

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

Задание 2.3. Идентифицировать значимость заинтересованных сторон проекта с помощью модели особенностей (рис. 2.1) и представить результаты на обсуждение.

 

 Рис. 2.1. Модель идентификации значимости заинтересованных сторон

(«Модель Митчелла», или «Модель особенностей»)

 

Модель особенностей классифицирует заинтересованные стороны на основании сочетания трех параметров (характеристик):

· власть – способность оказывать влияние, диктовать свою волю;

· легитимность – уместность (целесообразность) и правомерность вовлечения заинтересованной стороны;

· срочность – срочность реагирования на требования заинтересованной стороны с точки зрения критичности временного фактора (необходимости в немедленных действиях).

В зависимости от указанных характеристик заинтересованные стороны распределяются на три класса и семь групп:

· группы 1, 2, 3 – обладают лишь одним признаком, их определяют как латентные (временно скрытые) заинтересованные стороны, они, в свою очередь характеризуются как бездействующая (группа 1 – обладает властью), дискреционная (группа 2) и требующая (группа 3);

· группы 4, 5, 6 – демонстрируют наличие двух признаков, их определяют как ожидающие заинтересованные стороны и среди них выделяют: доминирующие (группа 4 – власть и правомерность), опасные (группа 5) и зависимые (группа 6);

· группа 7 – обладающая тремя признаками, определяется как безусловная (имеющая решающее значение).

Очевидно, что представители группы 7, вне зависимости от значимости признака, составляют группу влияния и требуют пристального внимания руководителя проекта. Ожидающие заинтересованные стороны (группы 4, 5, 6), требуют более серьезного отношения команды проекта, чем латентные (группы 1, 2, 3). Субъект, не обладающий ни одним из предложенных параметров, не является заинтересованной стороной проекта.

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

УПРАВЛЕНИЕ СОДЕРЖАНИЕМ ПРОЕКТА

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

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

· сбор требований – процесс определения, документирования и управления потребностями и требованиями заинтересованных сторон для достижения целей проекта;

· определение содержания – процесс разработки подробного описания проекта и продукта;

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

· подтверждение содержания – процесс формализованной приемки результатов проекта;

· контроль содержания – процесс мониторинга состояния содержания проекта и продукта, а также управления изменениями базового плана по содержанию.

3.1. Сбор требований

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

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

Задание 3.1. Разработать матрицу отслеживания требований (табл. 3.1) и представить результат на обсуждение.

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

1) каждое требование добавляет бизнес-ценность (связывая требование с целями организации и проекта);

2) требования, одобренные в документации по требованиям, выполнены в конце проекта.

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

Таблица 3.1

Матрица отслеживания требований

Код	Описание требования	Источник	Предъявитель требования	Приоритет	Порядок проверки	Подтверждение проверки	Текущий статус
1	2	3	4	5	6	7	8
1	Требования к проекту
1.1
1.2
2	Требования к продукту (и/или к решению)
2.1
2.2

Примечание:

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

«Источник» указывает на обоснование требования. Источниками требований могут быть бизнес-потребности организации, цели проекта, ИСР и т. д.

«Предъявитель требования» – лицо, предъявляющее требование.

«Приоритет» указывает на степень значимости требования (соответствующая цифра/буква разработанной шкалы приоритета).

«Порядок проверки» – описывается, каким образом проверяется требование (критерии проверки и в какой фазе).

«Подтверждение проверки» – указывается, проведена проверка или нет.

«Текущий статус» – отражается информация о состоянии требования, например: активно, отменено, отложено, добавлено, одобрено, назначено, выполнено. Формулировка «текущий статус» означает, что работа с требованиями – это итерационный процесс, осуществляемый на протяжении работы над проектом.

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

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

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

Задание 3.2. Описать содержание проекта (табл. 3.2) и представить результат на обсуждение.

Таблица 3.2

⇐ Предыдущая123456Следующая ⇒

Поделиться: