Функции руководителя проекта

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

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

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

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

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

Разбиение проекта на подзадачи (рис. 6.2), по сути, является высокоуровневым планированием, в результате которого проект в первую очередь получает оценку ресурсов и контрольные точки, привязанные к временным отметкам (англ, milestones). Безусловно, рисунок схематичен и не представляет разнообразия декомпозиции систем и высокоуровневых контрольных точек, но дает представление об общей функции.

Рис. 6.2. Декомпозиция проекта.

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

Здесь мы говорим о том, что руководитель проекта определяет верхний уровень иерархии структуры работ (ИСР), или WBS (от англ, work breakdown structure). Дальнейшую детализацию выполняет при его участии команда проекта.

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

Следует отметить, что РМВОК данная функция описывается в основном как интеграция проекта — поддержание его целостности и взаимосвязи временных, ресурсных и технических компонент в ходе всей реализации. Однако до того как поддерживать компоненты проекта в необходимом взаимодействии, их сначала необходимо выделить.

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

Кроме того, следует отметить, что в данном случае мы говорим именно о высокоуровневом планировании. Такие планы называются контрольными, или базовыми. Они являются элементами «договора» руководителя проекта с заинтересованными сторонами (участниками, стейкхолдерами, от англ, stakeholders) и могут изменяться только по согласованию всех заинтересованных сторон. Ясно, что руководитель проекта, который не имеет необходимого опыта и квалификации, не сможет заключить недискриминирующий его «договор».

Детальные планы выполнения работ, называемые рабочими, могут составляться не руководителем проекта, а экспертами и исполнителями в ходе реализации проекта. Они согласовываются только исполнителями и рабочей группой и могут меняться без согласования с заинтересованными сторонами. В совокупности базовый план и рабочие планы образуют общий план проекта. Подробнее планирование проекта будет описано в отдельном разделе. Здесь отметим, что на практике оптимальным периодом между контрольными точками является месяц, а длительность работ в рабочих планах — две недели^[1].

• 3. Достижение контрольных точек проекта. Руководитель проекта, согласовывая декомпозицию проекта, предлагает заинтересованным сторонам инструмент стороннего контроля реализации проекта в виде контрольных точек. Это необходимый элемент его договоренности с заинтересованными сторонами. Достижение контрольных точек проекта входит в его базовые функции и набор обязательств. Не выполняя данную функцию, руководитель проекта не только увеличивает риски проекта, но и лишает заинтересованные стороны единственного эффективного механизма контроля проекта. Он, таким образом, отключает внешний контроль, что не является допустимым даже при условии его высокой приверженности целям проекта и подтвержденной квалификации.
• 4. Управление командой проекта. Команда проекта или иначе рабочая группа проекта — основной концентрированный исполнительский ресурс проекта. Современные проекты не могут быть реализованы в одиночку. Реальные ИТ-системы давно перешагнули в своей сложности возможности малых коллективов. Именно поэтому функция управления командой проекта является центральной для руководителя проекта. Без команды единомышленников-соисполнителей руководитель проекта не справится, скорее всего, даже с планированием задач. Их исполнение точно окажется за пределами его возможностей.

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

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

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

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

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

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

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

Для анализа причин подобной «токсичности» может быть повторно предложено обратиться к классификации психологических радикалов, приведенных в работе В. В. Пономаренко^[2]. Представьте, что в вашем подчинении как руководителя проекта обнаруживается ярко выраженный «эпилептоид» или «истероид». В первом случае каждое совещание или другая коммуникация с его участием будет превращаться в выяснение уровня подчиненности, а во втором — в «театр одного актера».

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

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

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

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

На практике в большинстве случаев следует поддерживать численность команды проекта в 8—10 человек. Такая численность диктуется ограничениями человеческого мозга и его способностью эффективного прямого управления коллективом (см. гл. 2).

Безусловно, проекты различаются масштабом и сложностью. Встречаются проекты, где достаточной является численность команды в 3—5 человек. Существуют проекты, где недостаточной численностью команды будет и 100 человек. Во втором случае необходимо переходить к иерархической организации работы, но иерархическая организация подразумевает и смещение от термина «команда». Уже на втором уровне иерархии деятельность участников будет скорее не проектной, а текущей. Таким образом, команда проекта сращивается с иерархическим построением организации и группы организаций, используя их ресурсы для реализации проекта.

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

5. Определение заинтересованных сторон проекта. К заинтересованным сторонам, или участникам проекта относят сотрудников и руководителей, принимающих участие в проекте или затрагиваемых его результатами. Они участвуют в определении целей проекта, его содержания, в исполнении работ, выделении ресурсов на проект. Задача корректного определения состава участников проекта является крайне сложной^[1]. Данному вопросу посвящен не один десяток страниц PMI РЫВОК. При этом «задачей» этот комплексный процесс назван не совсем корректно. Это не однократное выполняемое действие, а непрекращающийся набор действий, выполняемых командой проекта и руководителем проекта в ходе его жизненного цикла. В связи со сложностью и потребностью в задействовании специальных компетенций эта функция включена в список базовых функций руководителя проекта.

Типовые роли участников проекта приведены на рис. 6.3.

Традиционно выделяют следующие основные роли: заказчик, спонсор (в отечественной терминологии — куратор), руководитель проекта, команда проекта и исполнители.

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

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

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

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

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

Власть спонсора не привязана к отдельному проекту. Это команда отдельного проекта пользуется «административным ресурсом» спонсора, источником которого является его положение во властной иерархии. Здесь стоит обратить внимание на первую строчку табл. 5.3, в которой представлены основные факторы успешности проектов. По результатам анализа международной статистики, поддержка руководства (англ, executive support), обеспечивает около 15% вклада в успех проекта. Это максимальный уровень вклада из списка, выделенного статистикой.

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

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

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

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

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

Контекст данного пособия задается информационными технологиями, поэтому список типовых ролей несколько отличается от канонического, приводимого, например, в PMIРМВОК; основное отличие в том, что выделена роль службы защиты информации (СЗИ).

С одной стороны, СЗИ является соисполнителем по любому информационно-технологическому проекту. С другой стороны, это подразделение играет роль принимающей стороны — участвует в процедуре контроля результата проекта при его приемке. А если учесть, что современные ИТ-системы обычно содержат в своем составе функционал защиты информации, то данное подразделение оказывается и заказчиком проекта. Это же относится к подразделениям, сведенным под наименованием «эксплуатация».

6. Обеспечение принятия технических решений проекта. На практике часто приходится встречать подход, при котором руководителем проекта назначают руководителя бизнес-направления, сотрудника с недостаточными техническими знаниями. В этом случае происходит смешение понятий «спонсор» и «руководитель проекта» или «заказчик» и «руководитель проекта». То есть проект теряет реального руководителя проекта, и в связи с необходимостью выполнения большого объема административной работы, специфической для руководителя проекта, на эту роль назначают технического исполнителя, полностью подчиненного «узурпировавшим власть» неспециалистам в ИТ-области.

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

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

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

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

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

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

• [1] Верзух Э. Управление проектами: ускоренный курс по программе MBA.
• [2] Пономаренко В. В. Практическая характерология с элементами прогнозированияи управления поведением (методика «семь радикалов»).
• [3] Верзух Э. Управление проектами: ускоренный курс по программе MBA.