Матрица ответственности проекта реферат

Обновлено: 03.07.2024

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

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

Степеней ответственности может быть много. Например, РМВОК определяет 4 вида ответственности:

1. Ответственный (О)- полностью отвечает за выполнение задачи и вправе принимать решения по способу ее реализации

2. Исполнитель (И) - исполняет задачу, но в обшем случае, не несет ответственности за способ ее решения.

3. Консультант (К) - смотрит за ходом исполнения задачи и высказывает свои соображения по спосбу и качеству реализации. Несет ответственность, если не заметит явного ляпа.

4. Наблюдатель (Н) - то же самое что и консультант, но ответственности не несет.

Матрица ответственности выглядит таким образом:

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

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

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

7 Разработка концепции проекта

8Жизненный цикл проекта.

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

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

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

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

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

Рис. 10. Факторы влияния на проект

По уровню влияния наиболее вероятен их следующий рейтинг:

 тип проекта – самое большое влияние;

 финансовые возможности – следующий фактор;

 технологические особенности реализации проекта – третья позиция;

 и выбранная стратегия реализация проекта.

Многие жизненные циклы проектов имеют ряд общих характеристик:

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

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

Рис.11. Типичный пример изменения уровня затрат и численности задействованного персонала в течении жизненного цикла проекта

 способность участников проекта повлиять на конечные характеристики продукта проекта и окончательную стоимость проекта максимальны в начале проекта и уменьшаются по ходу выполнения проекта. Это показано на рис. 12. Главная причина этого состоит в том, что стоимость внесения изменений в проект и исправления ошибок в общем случае возрастает по ходу выполнения проекта;

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

Рис. 12. Влияние участников проекта в течение проекта

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

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

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

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

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

Типичный жизненный цикл инвестиционного или технического проекта состоит из 4 фаз (рис. 13):

 начальная фаза – разработка миссии (концепции проекта);

 фаза разработки – планирование проекта;

 фаза реализации – поэтапный процесс исполнения проекта;

 фаза завершения – процесс выхода из проекта.

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

Рис. 13. Четырехфазный жизненный цикла проекта

Начальная фаза. Главным содержанием работ на этой фазе является разработка концепции проекта, включающая:

 сбор исходных данных и анализ существующего состояния (предварительное обследование);

 выявление потребности в изменениях (проекте);

 определение основных параметров и характеристик проекта:

o цели и стратегия их достижения, задачи, результаты;

o основные требования, ограничительные условия, критерии;

o уровень риска;

o окружение проекта, потенциальные участники;

o требуемые время, ресурсы, средства и др.

 определение и сравнительная оценка альтернатив;

 представление предложений, их апробация и экспертиза;

 утверждение концепции и получение одобрения для следующей фазы.

Фаза разработки. Главным содержанием этой фазы является разработка основных компонент проекта и подготовка к его реализации.
Общее содержание работ этой фазы:

 назначение руководителя проекта и формирование команды проекта, в первую очередь ключевых членов команды;

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

 развитие концепции и разработка основного содержания проекта:

o конечные результат(ы) и продукт(ы);

o стандарты качества;

o структура проекта;

o основные работы;

o требуемые ресурсы.

 структурное планирование, в том числе:

o декомпозиция проекта;

o календарные планы и укрупненные графики работ и обеспечения;

o смета и бюджет проекта;

o потребность в ресурсах;

o процедуры управления проекта и техника контроля;

o определение и распределение рисков.

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

 организация выполнения базовых проектных и опытно-конструкторских работ по проекту;

 представление проектной разработки;

 получение одобрения на продолжение работ.

Фаза реализации проекта. Главное содержание этой фазы следует из ее наименования – выполнение основных работ проекта, необходимых для достижения цели проекта. Основными работами этой фазы являются:

 организация и проведение торгов, заключение контрактов;

 полный ввод в действие разработанной системы управления проектом;

 организация выполнения работ;

 ввод в действие средств и способов коммуникации и связи участников проекта;

 ввод в действие системы мотивации и стимулирования команды (участников) проекта;

 детальное проектирование и технические спецификации;

 оперативное планирование работ;

 установление системы информационного контроля за ходом работ;

 организация и управление материально-техническим обеспечением работ, в том числе запасами, покупками, поставками;

 выполнение работ, предусмотренных проектом (в том числе производство строительно-монтажных и пусконаладочных работ);

 руководство, координация работ, согласование темпов, мониторинг прогресса, прогноз состояния, оперативный контроль и регулирование основных показателей проекта:

o ход работ, их темпы;

o качество работ и проекта;

o продолжительность и сроки;

o стоимость и другие показатели;

 решение возникающих проблем и задач.

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

 планирование процесса завершения проекта;

 эксплуатационные испытания окончательного продукта(ов) проекта;

 подготовка кадров для эксплуатации создаваемого объекта;

 подготовка документации, сдача объекта и конструкторской продукции заказчику;

 оценка результатов проекта и подведение итогов;

 подготовка итоговых документов;

 закрытие работ и проекта;

 разрешение конфликтных ситуаций;

 реализация оставшихся ресурсов;

 накопление фактических и опытных данных для последующих проектов;

 расформирование команды проекта.

Заметим, что последние три фазы могут выполняться с совмещением работ во времени – по последовательно-параллельной схеме.

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

 фаза обоснования направлений организационно-экономических изменений (концептуальная фаза);

 фаза планирования проекта;

 фаза реализации проекта;

 фаза завершения проекта;

 фаза постпроектного сопровождения организации и развития проекта.

Фазы проекта

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

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

Жизненный цикл проекта обычно определяет следующее:

 какие технические работы должны быть проведены в каждой фазе (например, в какой фазе должно быть проведено проектирование);

 в какой момент каждой фазы должны быть получены результаты поставки и как проходит проверка и подтверждение каждого результата поставки;

 кто участвует в каждой фазе (например, одновременно проводимые инженерные работы требуют, чтобы те, кто их выполняют, участвовали в определении требований и проектировании);

 как контролировать и подтверждать каждую фазу.

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

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

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

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

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

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

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

9Фазы реализации проекта.

Жизненный цикл проекта – промежуток времени между моментом появления проекта (началом его реализации) и моментом его ликвидации. Жизненный цикл проекта составляют: фазы, стадии, этапы.

Выполнение основных мероприятий по проекту:

· разработка технико-экономического обоснования (ТЭО) и рабочего проекта,

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

Традиционные подходы и рекомендации

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

Подзадачи и ответственность

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

Обычно состав формулировок элементов таблицы соответствует функциональной доктрине управления:

разработка ТЗ;
развертывание прототипа системы;
опытная эксплуатация и т.п.

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

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

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

Ответственность и полномочия: как избежать ошибок?

Считаю, что особенно начинающим PM нужно научиться заполнять упрощенную матрицу и обеспечить ее работоспособность и контроль, а затем переходить к более сложным конфигурациям, избегая при этом типовых ошибок, которые иногда случаются. Независимо от числа вариантов ответственности (букв, применяемых в таблице для ее заполнения), следует руководствоваться определенными правилами заполнения. Построение МО проекта требует соблюдения важных правил:

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

В результате внедрения проекта создания маркетинговой службы на предприятии даже при неизменном объеме закупок и продаж продукции, при снижении закупочных цен на 20 рублей за тонну, общий финансовый результат экономии средств при проведении торгово-закупочных операций составит 6 053 851,4 рубля. С учетом проведенных маркетинговых исследований, участия новых менеджеров по купле-продаже в процессе… Читать ещё >

проект создания маркетинговой службы на предприятии ооо "элита"

Матрица ответственности проекта ( реферат , курсовая , диплом , контрольная )

Матрица ответственности проекта по организации отдела маркетинга.

Директор по производству.

Начальник отдела кадров.

1.4. Правовое оформление.

О — ответственный, И — исполнитель, У — участник.

4 Диаграмма Ганта Составим график реализации проекта.

График Ганта проекта по организации деятельности отдела маркетинга.

1.4. Правовое оформление.

5 Обоснование экономической эффективности проекта Рассчитаем затраты на организацию работы маркетинговой службы.

Расчет затрат на маркетинговую службу.

Затраты на планируемый год тыс.руб.

Найм помещения под офис.

Обучение новых сотрудников (10 часов).

Маркетинговые исследования (по договору).

Минимальная заработная плата новых 6 сотрудников.

Проведем факторный анализ изменения себестоимости продукции Чернышев Ю. Г. , Тузей В. А. Комплексный экономический анализ хозяйственной деятельности. Ростов-на-Дону.:Феникс. 2006. С. 63 — 65 в результате создания маркетинговой службы.

1. Для факторного анализа затрат на 1 рубль продукции используем формулу:

где Зед. — затраты на 1 рубль Кi — количество продукции i-вида С i — себестоимость единицы продукции i-вида.

(Себестоимость = энергоносители + зарплата + амортизация (коэффициент 12) + прочие расходы) Ц i — цена единицы продукции i-вида.

себестоимость тонны продукции i-вида (руб.) С0.

цена тонны продукции i-вида (руб.) Ц0.

затраты на 1 рубль.

2. Рассчитаем влияние изменения себестоимости отдельных видов продукции с учетом затрат на создание маркетинговой службы по формуле:

Себестоимость тонны продукции i-вида (руб.) С1.

Таким образом, затраты на организацию маркетинговой службы увеличат затраты на единицу продукции на 0,003.

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

Сделаем расчет со снижением закупочных цен как минимум на 20 руб. за тонну. Используем формулу:

количество продукции i-вида (тонн).

Себестоимость тонны продукции i-вида (руб.) С1.

Среднее ДЗед. ц1.

В результате снижения закупочных цен затраты на единицу продукции снизятся в среднем на 0,008.

Рассчитаем баланс влияния факторов:

ДЗед.ц + ДЗед. с1 = - 0,008 + 0,003 = - 0,005.

В результате фактические затраты на рубль продукции снизятся на 0,005.

Фактический объем реализации продукции при запланированных ценах.

количество продукции i-вида (тонн).

Фактический объем реализации продукции (руб.).

121 077 028 х (- 0,005) = - 6 053 851,4.

Еще один пост для начинающих РМов про нужный и полезный инструмент – RACI матрицу.

Что такое матрица распределения ответственности или RACI матрица?

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

Часто понятие “матрица распределения ответственности” сокращают до просто “матрица ответственности”, но идеологически это не совсем верно. Даже в оригинале инструмент называется Responsibility assignment matrix, то есть подчеркивает то, что его цель – назначить или распределить ответственность. Но называть можно как угодно, вас в любом случае поймут.

Расшифровка RACI:

R (Responsible) – тот, кто будет делать работу. Например, модуль Х будет писать разработчик Вася. Для каждой задачи должен быть как минимум один “R”, можно больше.
A (Accountable) – тот, кто примет итоговую работу и будет нести за нее ответственность. Принимать у Васи модуль Х и отвечать перед руководителем проекта головой за то, что он заработает, будет его тимлид Петя. “А” для каждой задачи должен быть только один, отсутствовать “А”, также как и “R”, в задаче не может. В исключительных случаях (обычно для совсем маленьких команд) “А” и “R” будут одним и тем же человеком, тогда достаточно указать просто “А”. Но вообще это нехорошая практика.
C (Consulted) – тот, кто будет в обязательном порядке консультировать остальных при выполнении задачи. Чтобы модуль Х работал как надо, и Васе и Пете надо будет согласовать свои идеи по реализации с Инной, главной за информационную безопасность в компании, и Еленой, архитектором проекта. “C” в задаче может быть, а может и не быть.
I (Informed) – тот, кто должен быть в курсе принимаемых решений или хода выполнения задачи, но влиять на них никак не будет. Руководитель поддержки Иван, которого пользователи уже запинали в ожидании модуля Х, будет грустно читать статусы и рассылки о ходе разработки модуля, смотреть таски в JIRA и тяжело вздыхать. По аналогии с “C”, “I” в задаче может быть, а может и не быть.

Пример матрицы распределения ответственности

Самый простой и наглядный пример RACI матрицы проекта “поездка на дачу” (как всегда, взято в сети):

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

А вот более “корпоративный” пример:

Тут, как вы видите, приведены уже роли, а не люди, плюс используется цветовая кодировка (что лишнее, как по мне).

Как и где используется матрица распределения ответственности?

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

Итак, где может быть полезна матрица распределения ответственности?

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

Разработка матрицы распределения ответственности

Построить RACI матрицу несложно, все, что нужно, это:

Определить и выписать по вертикали задачи/промежуточные результаты проекта, шаги бизнес-процесса или другой набор действий, для которого вы хотите обозначить ответстенных.
Определить и выписать по горизонтали все роли или конкретных людей.
Проставить “А” для каждой задачи. Этот пункт, кстати, здорово прочищает мозги, так как сказать, “кто будет делать – легко”, а вот “за кем будет последнее слово” – уже сложнее.
Проставить “R” для каждой задачи.
Посмотреть на остальные роли/людей, прикинуть, нужно ли будет с ними консультироваться или хотя бы держать в курсе происходящего, и проставить соответствующие буквы.

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

Поздравляю, ваша матрица распределения ответственности готова!

Само составление – примитивнее некуда, а вот согласование – гораздо интереснее. Тут же начинается политика и прочие замечательные вещи, поэтому при разработке RACI матрицы стоит эту перспективу сразу учитывать.

Другие виды матрицы распределения ответственности

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

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

Вот такие варианты можно встретить чаще всего:

RASCI – к обычной RACI добавляется S (Support), то есть тот, кто будет помогать ответственному (R) выполнять задачу.
RACIQ – к обычной RACI добавляется Q (Quality), то есть тот, кто будет проверять результат на предмет соответствия заявленному качеству.
RACI-VS – к обычной RACI добавляется V (Verifier) и S (Signatory), которые, соответственно, будут принимать продукт с точки зрения критериев приемки и согласовывать передачу его в эксплуатацию.
RACIO (или CAIRO, просто буквы в другом порядке) – к обычной RACI добавляется O (Out of the loop), или тот, кого в задаче видеть вообще не хотят (чтобы сразу его выпилить, ну, например, не хотим мы, чтобы архитектор Елена мешалась под ногами у разработчика Васи). В жизни такого не видела, но очень хотела бы.
И так далее.

Еще есть куча вариантов с другими буквами и проч., но концепция остается все той же.

Основные ошибки при построении матрицы распределения ответственности

Вариантов “как из RACI матрицы сделать бессмысленную бумажку” много, но вот самые частые и поэтому самые любимые:

Указываем везде спонсора (ну или хотя бы заказчика или любого топ-менеджера на выбор) в качестве “А”. В итоге большим дядям не до вас, ничего толком не принято, ответственных нет.
Пихаем по несколько букв в одну клетку матрицы. Нет, такие редкие исключения, конечно, бывают, но если у вас вся матрица пестрит A/R и C/I – значит, вы сами не разобрались то ли с инструментом, то ли с ответственностью.
Всех информируем изо всех сил. Или со всеми консультируемся. И в итоге получаем массу лишней коммуникации и генерацию белого шума в проекте или процессе.
Использование имен вместо ролей. Мало того, что придется переделывать при любом изменении в команде, так еще и потом для истории этот документ будет бессмысленным.

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

Используете RACI матрицу у себя? Расскажите!

Шаблон шаблоном, но вообще RACI матрица – это одновременно про управление рисками и про работу со стейкхолдерами, а не просто бумажка ради бумажки.

Если вы хотите узнать больше о рисках и о том, как с ними работать – вы можете приобрести наш большой курс по управлению рисками. Шаблон реестра рисков проекта и чек-лист для идентификации рисков в подарок!

А если вы хотите лучше работать со стейкхолдерами и уметь на них влиять – то посмотрите наш большой курс по управлению стейкхолдерами. Пакет шаблонов в подарок!

Информация полезна? Поддержи развитие проекта!

На кофе и новые материалы для читателей блога :)

Еще статьи

' data-post_id="5783" data-user_id="0" data-is_need_logged="0" data-lang="en" data-decom_comment_single_translate=" комментарий" data-decom_comment_twice_translate=" комментария" data-decom_comment_plural_translate=" комментариев" data-multiple_vote="1" data-text_lang_comment_deleted='Комментарий удален' data-text_lang_edited="Отредактировано в" data-text_lang_delete="Удалить" data-text_lang_not_zero="Поле не NULL" data-text_lang_required="Это обязательное поле." data-text_lang_checked="Отметьте один из пунктов" data-text_lang_completed="Операция завершена" data-text_lang_items_deleted="Объекты были удалены" data-text_lang_close="Закрыть" data-text_lang_loading="Загрузка. ">

Добавить комментарий

2 комментария

Как раз в связи с пуском большой программы проектов в компании пытаемся наладить работу с RACI матрицей руководителей проектов и использование ее в практике управления проектами, и вот тут возникло небольшое непонимание:

1. На уровне руководства решено было представить верхнеуровнево матрицу распределения ответственности по отделам- Эксплуатация, Производство, Внедрение, а вот роль РП отдельно выделили. На вопрос, почему бы тогда не отразить и роли других участников, поступил ответ: тогда матрица получиться очень масштабной и плохо читаемой. Цель была укрупненно представить какое подразделение за что отвечает. Мне кажется, что эта практика не очень полезная, даже в укрупненном масштабе, т.к. дьявол всегда в деталях, и как правило много “политических” вопросов возникает, когда начинаешь решать конкретные задачи, хотя на верхнем уровне вроде бы как и все отлично выглядит.

2. “если у вас вся матрица пестрит A/R” – как раз по роли РП такая ситуация очень частая, если говорить о задачах, связанных с управлением проектом. Возможно, здесь нужно рассмотреть конкретные ситуации, что бы понять, где такая практика допустима, где показывает, что “вы сами не разобрались то ли с инструментом, то ли с ответственностью”.

Светлана, отвечу по пунктам:
1. Я категорически против такой коллективной безответственности, толку от этой матрицы примерно ноль. Попробуйте предложить тогда уж указать в матрице руководителей этих департаментов, а с них уже конкретное делегирование стрясти. В письменной форме, конечно же, тогда хоть будет на кого пальцем показать при необходимости=)) Вот сколько таких матриц видела – ни одна не работала, и спасибо еще, если не вредила.
2. A/R – вариант нормы, если для вас это работает, более того – чем меньше проект, тем чаще это норма. Другой вопрос – что в это A вкладывается. Действительно ли РМ у вас “A” за, например, финансовый план проекта, как РМ сделает – так и будет? Или все-таки спонсор и заказчик в итоге его утвердят и перед менеджментом отвечать будут, если что? Ну и так далее.

Читайте также: