1.Теоретическая часть

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

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

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

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

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

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