Функции матрицы ответственности в проектном управлении
Содержание
Когда мы определились с основными ролями в команде проекта, следует перейти к разработке весьма полезного документа, именуемого как матрица ответственности. Нам, уважаемый читатель, важно осознавать, что в ходе разработки матричной таблицы PM фиксирует комплекс не только ответственности членов группы, но и их полномочий. Предлагаю вам разобраться в этой теме подробнее.
Традиционные подходы и рекомендации
В руководстве PMBOK (пятое издание) матрица ответственности имеет также иные обозначения: «матричные диаграммы», «матрица RAСI». В отечественной практике этот инструмент часто звучит как матрица распределения ответственности. Под МО в PMI-руководстве понимается некая таблица, в которой показаны ресурсы, назначенные для каждого пакета работ. В ней отображаются связи между членами команды и этапами работ.
Для заполнения МО традиционно применяется методика RAСI. Это аббревиатурное название, сформированное по первым буквам слов: «Исполнитель» (Responsible), «Ответственный» (Accountable), «Консультант» (Consult before doing), «Наблюдатель» (Inform after doing).
В зависимости от масштаба проекта PMBOK допускает использование МО на различных уровнях с разной степенью проработки ответственности членов рабочей группы. Если мы рассматриваем МО высокого уровня, то для построения матрицы привлекаются группы и подразделения команды с одной стороны и крупные компоненты ИСР – с другой. Напротив, МО низкого уровня «спускаются» до детализации распределения ответственности конкретных участников команд вплоть до уровня операций.
Российскую практику проектирования часто отличает расширение вариантов ответственности вплоть до включения в МО также и полномочий. Это вносит разбалансировку в матрицу. Иллюстрацию такого подхода вы можете увидеть ниже.
Подзадачи и ответственность
Предыдущий пример наглядно демонстрирует ситуацию размытия фокусов на ответственности. Как избежать подобной ситуации? Вспомним, коллеги, подраздел, посвященный задачам управления. В нем мы разобрали важную категорию управления – «ответственность». Тогда мы установили, что ответственность ресурса предполагает его право принять и обязанность выполнить задачу, не ссылаясь ни на какие препятствия. Позвольте напомнить пример красноярского охотника, который взялся за задачу доставить к сроку шкурки белок, битых в глаз, но под условием, что число их будет не более 45 вместо 100. Таково было его правило: браться только за то, что он способен сделать реально.
Ответственным ресурсом уникальной проектной задачи выступает менеджер. В момент планирования проекта его руководитель обязан обеспечить декомпозицию результата на подзадачи, последовательное выполнение которых автоматически приводит к решению ключевой задачи. Такую декомпозицию целесообразно производить коллегиально, привлекая членов команды управления проектом к работе методом мозгового штурма. Результатами его должны явиться иерархическая структура работ, план по вехам.
Обычно состав формулировок элементов таблицы соответствует функциональной доктрине управления:
- разработка ТЗ;
- развертывание прототипа системы;
- опытная эксплуатация и т.п.
Гораздо действеннее получается, если применять методы управления от задач. Предлагаю вашему вниманию пример такой декомпозиции.
Данный пример показателен. Естественно, что за задачу верхнего уровня отвечает менеджер. И очевидно, что управление проектом устанавливает разделение ответственности по декомпозированным подзадачам между членами команды. Таким образом, закономерно созревает логика составления такой таблицы, как матрица ответственности. Ее построение начинается с формулирования задач.
Лично мне импонирует лаконичный подход к применению матричной модели, потому что обязательность как синоним предмета нашего исследования – это еще и состояние человека: либо она есть, либо ее нет. И самое главное, такое состояние не может быть распределено между несколькими людьми. В целях управления оно может иметь только единственного носителя. В противном случае, ответственность в той или иной степени утрачивается. Наш пример декомпозиции диктует следующую форму матрицы.
Ответственность и полномочия: как избежать ошибок?
Считаю, что особенно начинающим PM нужно научиться заполнять упрощенную матрицу и обеспечить ее работоспособность и контроль, а затем переходить к более сложным конфигурациям, избегая при этом типовых ошибок, которые иногда случаются. Независимо от числа вариантов ответственности (букв, применяемых в таблице для ее заполнения), следует руководствоваться определенными правилами заполнения. Построение МО проекта требует соблюдения важных правил:
- Работать над МО всей командой, стараясь заполнить ее в единственную сессию.
- Сначала заполнять все ячейки с ответственностью, исключить ситуацию, когда остаются строки без символа «О».
- Придерживаться методики RACI, избегая расширения состава полномочий из разряда «Исполнитель», «Согласование», которые, по сути, не несут в содержании ответственности.
- Исключить ситуацию пустых столбцов в МО.
- Составить несколько вариантов МО, начиная с верхнего уровня и соблюдая принцип лаконичности.
Если не учитывать специальных правил, изложенных выше, легко допустить ошибки, которые потом ухудшат возможности контроля, снизят эффективность управления проектом. Чтобы избежать такой ситуации, лучше сразу в ходе работы над МО, контролировать себя на возможность ошибиться. Построение МО может сопровождаться типичными ошибками:
- Допустить ситуацию, когда в одной ячейке проставлено два символа.
- Перегрузить МО символами, тем самым девальвируя ее работопригодность.
- После утверждения МО «положить ее под сукно» и забыть, тем самым исключив смысл применения МО в качестве инструмента прямого контроля промежуточных результатов и спроса с ответственных ресурсов по задачам проекта.
В данной статье, уважаемые коллеги, мы вместе с вами рассмотрели вопрос о понятии, сути и содержании матрицы ответственности как существенном элементе планирования и реализации проекта. Представлены традиционные методология и примеры построения МО. Заявлена авторская позиция о пользе более категоричного подхода к ответственности и ее распределении. Уточнены правила разработки МО и сопутствующие ошибки.
Я убежден, что менеджер проекта, который руководствуется при распределении ответственности правилом «Лучше меньше, да лучше» более успешен. Это происходит также благодаря тому, что построение МО реализуется в режиме однозначности. Поэтому каждому PM я советую начинать с более простых форм, постепенно усложняя практику применения.
(голосов: 9, средняя оценка: 4,11 из 5)
Загрузка...
