7. Понятие матрицы распределения ответственности в проекте. Основные правила распределения обязанностей и ответственности в проекте.

Важная задача в управлении проектом, и вообще в менеджменте – четко определить, кто за что отвечает. Именно для этого и применяется инструмент «матрица ответственности» (responsibility matrix).

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

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

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

1) Ответственный. Для каждой работы обязательно должен быть указан один и только один ответственный.

2) Исполнители. Их может быть несколько, а может быть так, что сам ответственный является и исполнителем. Т.е. в одной ячейке может быть более одного обозначения.

3) Утверждающий. Тот человек, который утверждает некоторый документ (если данная работа связана с созданием документа). Он может быть только один.

4) Согласующий. Тот человек, который участвует в согласовании некоторого документа (если данная работа связана с созданием документа). Их может быть несколько.

Матрица ответственности может применяться не только в управлении проектами, но и в других сферах:

- В процессном управлении, там ее называют матрицей ответственности по бизнес-процессу.

- При описании работы подразделения может строиться матрица ответственности по нему, где с одной стороны перечисляют должности, входящие в подразделение, а с другой – функции данного подразделения. (файл МАТНИЦА ОТВЕТСТВЕННОСТИ)

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

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

Упр. предметной областью – это процесс управления, которые обеспечивает включение проекта тех и только тех работ, которые необходимы для успешного и эффективного достижения целей проекта СТАДИИ:

1. Планирование содержания - создание плана управления содержанием проекта, в котором документируется процесс формулирования, верификации и контроля содержания проекта, а также процесс создания и формулирования иерархической структуры работ (ИСТ).

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

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

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

2. Определение содержания - разработка подробного описания содержания проекта в качестве основы для принятия будущих решений по проекту

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

3. Создание ИСР(иерархи-я струк. работ) - разбиение крупных результатов поставки проекта н проектных работ на более мелкие, более управляемые элементы.

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

4 Подтверждение содержания - формализация принятия завершенных результатов поставки проекта.

Подтверждение содержания - это формальное принятие участником проекта завершенного содержания проекта и относящихся к нему результатов поставки.

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

5. Управление содержанием - управление изменениями содержания проекта.

Управление содержанием проекта- это воздействии на факторы, создающие изменения содержания проекта, и контролировании производимого этими изменениями эффекта.

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

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