НОУ ИНТУИТ | Лекция | Планирование человеческих ресурсов проекта

«под микроскопом»: 4 ключевых роли в каждом проекте

Распределение задач — одна из основных обязанностей менеджера. Но на практике всё обычно выглядит иначе: руководитель просто назначает членов команды с расчётом на то, что специалисты сами решат, кто и что должен делать. Но что происходит, если были сорваны сроки или выпущен некачественный продукт? «Я этим не занимаюсь», «мне этого не говорили»… И никаких полезных действий.

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

A — accountable

«Подотчётный», или «ответственный» — это главный руководитель проекта. Именно он отвечает за то, чтобы поставленные задачи были выполнены в срок, с требуемым уровнем качества и в рамках выделенного бюджета. Кроме того, A:

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

C — consulted

Третья роль в матрице RACI — «консультант» (его иногда также называют «куратором»). Наряду с руководителем, он принимает участие в управлении проектом, но занимается в первую очередь решением стратегических вопросов:

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

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

I — informed

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

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

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

R — responsible

В переводе Responsible означает «исполнитель». Это сотрудник, на котором непосредственно лежит ответственность за выполнение определённого участка работы. При этом в большинстве случаев он не выбирает способы решения и подчиняется руководителю проекта.

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

Таких людей в команде может быть несколько. Кроме того, эта роль может комбинироваться с другими. Чаще всего встречается сочетание Accountable Resbonsible (в переводе — «ответственный исполнитель»).

А чем стратегический менеджмент хуже?

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

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

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

Важная особенность

Эта часть, во всех публикациях, как правило, отсутствует. По непонятной причине. Наверное по причине секретности.

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

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

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

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

Однако, если не удалось достичь согласованности, то следует участников разделить на группы (по 5-10 человек) и дать каждой группе задание сформулировать одну идеальную матрицу. После готовности единой матрицы, каждая группа представляет свой вариант всем участникам.

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

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

[1] Six sigma (Шесть сигм) — концепция управления производством, суть которой сводится к необходимости улучшения качества выходов каждого из процессов, минимизации дефектов и статистических отклонений в операционной деятельности.

[2] ITIL расшифровывается как IT Infrastructure Library. В общем случае это набор описаний наилучших практик по организации работы IT.

Матрица ответственности (raci)

Акроним RACI расшифровывается следующим образом:

• R(Responsible) – Отвечает. Специалисты непосредственно выполняющие работу для достижения поставленной задачи.
• А (Accountable) – Утверждает. Лицо, которое отвечает за правильное и полное выполнение задания. Это должен быть один человек, который часто является руководителем группы по реализации задачи.
• C(Consult) – Консультирует. Лица, которые предоставляют информацию для проекта и с которым существует двусторонняя связь. Это, как правило, несколько человек, часто эксперты по предмету.
• I(Inform) – Консультируется. Лица, которые должны получать информацию о ходе решения задачи. Как правило это люди, на которых влияет результат решения задачи.

На практике используют также:

RASCI = RACI S.«S» означает Support «Поддерживает»;

RACIO = RACI О. «O» означает Out of the Loop «Вне цикла» или «не участвует»

RACI-VS = RACI VS. «V» означает  Verify «проверяет» и «S» означает Signatory «Подписывает».

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

Общая схема подготовки матрицы следующая: 1. Перечислите действия (задачи), которые должны быть выполнены на одной стороне таблицы. 2. Перечислите всех участников процесса (заинтересованные стороны) на другой стороне таблицы. 3) Заполните сетку буквами, R, A, C, I. отвечающими роли каждого частника. Конец процесса, матрица готова.

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

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

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

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

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

Мне весьма импонирует замысловатый инструмент – матрица РАЗУ. Трехранговая, двухтабличная МО, позволяющая оценивать сравнительную трудоемкость всех операций и сравнивать ФОТ с экспертной оценкой результатов, а также многое другое. Просто любо-дорого и для PM, и экономиста-трудовика, курирующего проекты. Здесь привожу пример карты логических аспектов РАЗУ с тремя направления привязки.

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

Матрица РАЗУ – метод сложный, и от него никто не ждет простоты. Тем не менее, понять его не так трудно. Нужно вникнуть в содержание карты и выполнить несколько немудреных правил. Есть разрешенные сочетания знаков-символов, а есть запрещенные. Особенность этих правил в их безусловной обязательности.

1. Каждая строка имеет в своем составе хотя бы один символ из трио «Я», «!», «Р».
2. Прописные буквы из раздела «Управление работой» обязательны в любой строке хотя бы единожды, причем координацию можно опустить, если число подразделений, занятых в операции, меньше трех.
3. «!» и «Р» в каждой строке есть попарно.
4. «Я» и «Т» однозначно есть в каждой строке не более одного раза.
5. В строке символы «Я» и группа «!» и «Р» взаимно исключают друг друга.

Второй формой, включенной в метод РАЗУ, является так называемая таблица парного сравнения. Благодаря этой матрице достигается возможность оцифровки ответственности. Методика позволяет анализировать приведенные в первой таблице символьные значения и обеспечить вывод сравнительной трудоемкости представленных в ней видов.

Символы переименовываются в ряд К1, К2… К8 и попарно выстраивают в столбцах и в строках так, чтобы на пересечении одноименных ячеек всегда были проставлены «1», в другие ячейки сочетаний поставляются либо «2» (значимый)

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

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

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

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

Определение ролей проекта

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

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

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

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

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

Формируя команду управления проектом, необходимо определить ключевых лиц проекта, принимающих решения.

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

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

Ключевые роли со стороны исполнителя — руководитель проекта (менеджер проекта) со стороны исполнителя и бизнес-менеджер.

Бизнес-менеджер отвечает за успешное выполнение проекта и представляет исполнителя в его договорных отношениях с заказчиком. Менеджер проекта (руководитель проекта) отвечает как за успехи, так и за неудачи проекта.

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

В крупных проектах могут быть организованы комитет по управлению, комитет по контролю за изменениями, комитет по анализу спорных вопросов [8].

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

Состав команды управления должен быть достаточным, чтобы осуществлять [11]:

В состав команды проекта входят не только команда управления проектом, но и исполнители проекта. Примеры проектных ролей исполнителей, характерных для IT-проектов: функциональный архитектор, функциональный консультант, разработчик, администратор ИС, тестировщик, менеджер по качеству, системный аналитик.

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

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

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

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

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

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

На рис. 6.1 представлен пример организационной структуры проекта, документирования распределения ролей и ответственности членов команды проекта, выполненного в виде организационной структуры. Организационная структура является иерархической организационной схемой существующих подразделений организации (отделов, групп или команд).

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

Полезные советы

Чтобы матрица RACI выполняла свои функции и обеспечивала эффективную бесперебойную работу в компании, нужно помнить о нескольких важных моментах.

1. При заполнении таблицы учитывайте квалификацию работников. Так, бухгалтера не стоит назначать консультантом (C) на этапе вёрстки сайта как минимум потому, что он не разбирается в этой области.
2. На каждом участке должен быть только один Accountable (A). Если их несколько, указывайте условия. Например, A1 — ответственный за тестирование десктопной версии сайта, а A2 — мобильной.
3. У любой задачи обязательно должны быть Accountable и Responsible (в переводе — «Ответственный» и «Исполнитель»).
4. Старайтесь сформулировать каждую задачу максимально конкретно. Используйте глаголы — «опубликовать», «подготовить», «написать», «проверить», «обновить» и т. д. Желательно сразу же указывать необходимые результаты — не просто «Проверить скорость загрузки сайта», а «Убедиться, что скорость загрузки сайта не больше 0,8 сек».
5. Действия должны быть применимы не к конкретному сотруднику, а к должности в целом.
6. Составлять матрицу RACI лучше в команде, на основе разбора реальных рабочих ситуаций. Важно, чтобы каждый участник осознавал свою роль и задачи, которые перед ним стоят.

Построение матрицы ответственности

1. Перечислить основные работы проекта.

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

2. Перечислить группы/роли внутри проектной команды.

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

3. Закодировать матрицу ответственности.

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

   На коды, используемые в матрице ответственности, каких-либо ограничений не существует, но наибольшее распространение получил метод RACI (Responsible (R), Accountable (A), Consulted (C), Informed(I)), в котором приведено описание соответствующих кодов.

4. Инициировать использование матрицы и включить процедуру использования матрицы ответственности в документ «План управления проектом«.

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

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

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

Разновидности модели

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

RACI-VS

Здесь к стандартным ролям добавляются ещё две:

• Verifies (V) — сотрудник или специальная команда, которые проверяют, насколько результат реализации той или иной задачи соответствует утверждённым критериям.
• Signs off (S) согласует сдачу проекта с заказчиком, проводит презентацию и предоставляет отчёты. Обычно эту функцию выполняет ответственный за выполнение работы (Accountable), но RACI-VS для этого привлекают отдельного специалиста.

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

RASCI

В этом варианте в матрице появляется одна новая роль — Supportive (S). Её ключевые функции заключаются в обеспечении проекта дополнительными ресурсами, то есть поддержке руководителя и исполнителей.

Учимся строить raci-матрицу на примере

Поговорим о практической стороне вопроса. Как правильно составить диаграмму для распределения полномочий и ответственности?

1. Составляем to do-list

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

2. Выбираем участников команды

Здесь нужно ответить на вопрос: «Кто будет заниматься этим проектом?». По горизонтали необходимо выписать всех сотрудников и/или отделов, которые участвуют в реализации на всех этапах, — от планирования до презентации результатов и сдачи отчёта.

3. Заполняем таблицу

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

Возьмём за основу наш пример и остановимся на этапе «Дизайн». В данном случае R — исполнитель — только один. В процессе работы он ориентируется на предварительно подготовленный прототип сайта. Поэтому системный архитектор, который занимался его разработкой, на этом этапе выполняет функцию консультанта C.

Также свои пожелания могут высказывать аналитик и разработчик. Готовый дизайн утверждается с менеджером проекта (A). А вот тестировщики и системный администратор на этом этапе не принимают никаких решений, а лишь получают информацию о том, как идёт работа, а потому им присваивают роль информируемых — I.