«По мнению окружающих, Руководитель проекта – это тот человек, который с помощью девяти женщин может родить ребенка за один месяц» — цитата из Интернета
Часто встречается ситуация, когда от руководителя проекта требуют успешно выполнить проект, не предоставляя достаточных полномочий для достижения цели.
На днях ввязался в теоретический диспут на тему, какие нужны полномочия руководителю проектов (РП) для успешного завершения проекта. Или, точнее, в формулировке, какие полномочия должны быть предоставлены РП в проекте, чтобы не было оправдания "их нехваткой" в случае неудачного завершения.
Ниже я привожу свои мысли, как я вижу ситуацию в теории, и как это чаще всего встречается в моей практике.
Терминология
Для начала следует определиться с ключевой терминологией. Предлагаю использовать терминологию из руководства PMBOK.
Спонсор — лицо (или группа лиц), предоставляющее ресурсы и поддержку для проекта и ответственное за достижение успеха. Устанавливает приоритет проекта в организации; предоставляет ресурсы; утверждает уровень приоритетности ресурсов. Хочу отметить, что, несмотря на то, что в русском языке слово спонсор ассоциируется в первую очередь с деньгами, и что финансирование очень важно для проекта, у спонсора так же есть другие не менее важные обязанности.
Заказчики — лица или организации, которые будут одобрять продукт, услугу
или результат проекта, а также управлять ими. Формируют требования к результатам проекта, принимают и одобряют конечные результаты.
Проектная команда – остальные члены команды, которые выполняют работу по проекту.
Успешный проект – проект, уложившийся в проектный треугольник (сроки, стоимость, содержание), при наличии удовлетворенного результатами заказчика.
Во время проекта основные взаимодействия РП происходят с Заказчиком, Спонсором и Проектной командой (не путать с каналами коммуникаций на проекте, которых намного больше). С этой точки зрения я и буду рассматривать требуемые полномочия для успешного завершения проекта.
Теория полномочий РП (идеальный проект в идеальной компании)
Я вижу следующую картину идеальных полномочий менеджера:
Коммуникационные полномочия
Свободное общение с Заказчиком
У РП должна быть возможность прямого общения с Заказчиком. Наличие таких полномочий существенно упрощает процесс взаимодействия, проведения встреч и эскалаций.
Доступность спонсора
РП должен иметь возможность регулярно общаться со спонсором для отчета о текущем состоянии проекта, и, при необходимости, для эскалации и решения проблем, которые выходят за пределы сферы влияния РП.
Также, зачастую приходится прибегать к помощи Спонсора в части закрытия проекта. Например, чтобы получить последнюю подпись на закрывающих актах (довольно часто это чисто политическая активность, и, к сожалению, в российских реалиях не всегда зависящая от РП).
Организационные полномочия
Участие РП на фазе инициации проекта
Согласование целей проекта при его инициации/старте дает возможность сформулировать, зафиксировать и согласовать цели проекта со всеми заинтересованными лицами (с Заказчиком, Спонсором и проектной командой) на старте проекта.
Project Management Institute (PMI, http://www.pmi.org) настаивает на том, и я всецело поддерживаю эту позицию, чтобы РП привлекался к проекту как можно ранее (фаза инициации). В идеале, до заключения контракта, чтобы можно было оценить реалистичность обещанного заказчику проектного треугольника (сроки, функционал, бюджет).
Чем раньше РП подключается к организации управления проекта, тем больше возможностей он имеет для формирования единого восприятия целей и задач проекта всеми участниками.
Официальное подтверждение статуса РП
Необходимо официальное разрешение (например, в уставе проекта) на привлечение ресурсов на проект. И, что самое важное, от Спонсора требуется официальное согласование приоритетов проекта в рамках организации или портфеля проектов, чтобы линейные руководители (в матричной структуре) не выделяли ресурсы на выполнение задач проекта по остаточному принципу, обосновывая это наличием более важных / срочных проектов.
Полномочия, связанные с командой
Один из ключевых моментов успешного завершения проекта является формирование эффективной команды. Для этого требуется:
Добавление и замена людей на проекте.
Если по каким-либо параметрам сотрудник не вписывается в проектную команду, то у РП должна быть возможность заменить сотрудника или вывести его из проекта. Да, я понимаю, что нужно уметь работать с теми, кто есть, но иногда эффективнее заменить сотрудника, чем тратить на него время, как в долго- так и краткосрочной перспективе.
В этот же пункт я отношу возможность добавления людей на проект. То есть, если РП может обосновать (на фазе планирования проекта, в случае изменения проектного треугольника, или в случае срабатывания риска) зачем нужны еще люди, то их выделят на проект. Ключевая фраза – «если РП может обосновать», так как не всегда добавление новых людей сокращает сроки или увеличивает производительность. К тому же, далеко не всегда есть «лишние люди» в компании, но почему бы и не попытаться :)
Возможность мотивировать людей:
Мотивация, требующая выделения финансовых ресурсов, которая, в свою очередь, делится на:
Финансовая мотивация — премии, оплата сверхурочных/выходных, бонусы…
Косвенно финансовая мотивация — проведение тимбилдингов, обучение, обеспечение более комфортных условий рабочих мест (то есть наличие бюджета на кофеварки, удобные столы/стулья, производительные компьютеры), совместное размещение сотрудников (collocation). В России используется термин "нефинансовая мотивация", хотя мне кажется более подходящим термин — "косвенно финансовая мотивация", так как все это требует финансовых затрат компании так или иначе.
Лидерская мотивация. Наличие тех самых «софт-скилы» руководителя проекта про которые любят рассказывать на различных тренингах – коммуникативные и управленческие навыки (умение убеждать, мотивировать, управлять, находить нужный подход к людям, и разрешать конфликтные ситуации). То есть, присущие хорошему руководителю навыки, которые применяются постоянно.
Практика (как это происходит в реальной жизни):
Все выше изложенное относится к максимально желаемым полномочий, и по каждому пункту я могу сказать, что мне этого не хватало когда-либо в моей проектной деятельности. Не то, чтобы это стало причиной неуспеха проекта, но дополнительные трудности возникали.
Мое стойкое убеждение, что в организациях, предоставляющие все перечисленные полномочия в 100% объеме, проект может быть доведен до конца и без участия РП. Скрам-мастер или вчерашний тим-лид вполне справятся с задачей. Возможно с трудностями, с задержкой сроков или неэффективным использованием ресурсов, но проект вытянут.
К сожалению, или к счастью для РП, в реальности таких организаций не существует. Во всяком случае, мне про такие слышать не приходилось.
Возникает вопрос, что же на самом деле минимально необходимо РП для успешного завершения проекта.
Все перечисленные выше пункты можно разбить на три типа:
- Финансовые – которые требуют финансовых вложений
- Организационные – которые регламентируются правилами компании
- Личностные – которые требуют применения личных навыков РП
В таблице ниже я привожу мое видение разбиения перечисленных полномочий на типы, а также на что, в первую очередь, влияет отсутствие этих полномочий. В последнем столбце я указал, чем, с моей точки зрения, можно компенсировать их отсутствие.
(*) — Здесь следует читать как «Более тщательным планированием» — криво, но по сути – так как РП и так должен тщательно планировать, а в данном случае еще «более тщательно».
Стоит отметить, что «компенсация» не означает полноценного замещения. Проект может быть таким, что без спонсора и его личных связей не подписать акт (мы работаем в условиях российских реалий) – все зависит от специфики проекта или проектной области.
С другой стороны, необходимость компенсировать отсутствующее полномочие потенциально взваливает на РП дополнительный объем работы. И на компенсацию отсутствия двух-трех полномочий может не хватить времени в сутках.
Таким образом можно сказать, что
- есть идеальный список полномочий
- есть варианты «как выкрутиться», в случае отсутствия того или иного полномочия
- полноценно компенсировать что-то отсутствующее — не получится
- универсального списка обязательных полномочий для любого проекта не существует, в виду специфики каждого проекта.
- Личные качества РП существенно помогают в успешном завершении проекта.
Поясню последнюю мысль подробнее.
Можно заметить, что у РП есть возможность, в основном, влиять на организационные полномочия. Личностные полномочия (софт-скилы) либо есть, либо нет, и успеть их развить за время проекта — маловероятно. С другой стороны, если они есть, то их никто не может забрать или «запретить» их применять на проекте.
С финансированием тоже очень сложно что-то изменить. Есть определенный бюджет, запланированный на проект, и крайне редко бывает возможность его увеличить при неизменном объеме работ.
Довольно часто удается успешно решить вопрос с отсутствием какого-то полномочия посредством личных качеств РП. Например, договориться со спонсором о выделении 15 минут в неделю, даже если в компании в отношении такой коммуникации «так не принято».
Моя практика этот вывод полностью подтверждает. Неоднократно наблюдал, что более успешными (с точки зрения успешности проектов) менеджерами являются те, кто ходят и требуют, уговаривают, и выпрашивают, стоя над душой. Кто договаривается с линейными руководителями о людях (сам привозил из Праги ящик пива в обмен на участие сильного аналитика на моем проекте).
Кто умудряется уговорить завхоза на более удобные столы/стулья, гарнитуры и телефоны…
Кто выпрашивает лучшие рабочие условия из руководителей, материальные и нематериальные поощрения сотрудникам.
Кто ловит и общается со спонсором о статусе и проблемах проекта (включая перехват спонсора у лифта, чтобы рассказать о насущном, и подключить к решению проблем).
Кто держит заказчика в курсе (даже несмотря на сопротивление со стороны заказчика), подключает его к обсуждению и решению проблем. Добивается, чтобы у всех (заказчика, команды, пользователей) было единое понимание целей и статуса проекта…
В целом, хочу подчеркнуть мысль, что ту самую проактивность, которую мы, руководители проектов, так любим видеть у своих сотрудников – очень полезно включать и у себя самого. Как минимум, это полезно для успеха проекта.
С уважением,
Олег Пономарев, PMP
Комментарии (5)
itwarwar
13.04.2016 20:39У себя в компании я обычно предоставляю заказчику «Еженедельный статус-отчет исполнения проекта» в табличной форме, с целевыми показателями, план/факт/отклонения, риски и т.д… Как пример, в нем в одной из таблиц (общая ситуация) может быть прописано, что стейкхолдер от заказчика заболел, а его зам (все роли прописаны в матрице RACI) был в командировке, в связи с чем заказчик не смог принять (официально) один из этапов (фазы, milestone) проекта и сроки проекта сдвинулись на несколько дней (что прописано в таблицах — отчет о выполненных работах за период такой-то, что повлияло на таблицы — отклонения в проекте, запланированные работы, риски).
И заказчик все это видит наглядно.
Я считаю, что обо всем можно договориться, желательно на берегу и всегда защититься документом (реально работающим и находящемся в работе с начала проекта). В случае если заказчик начинает в начале с данным документом (статус-отчетом) «буксовать» (типа — да зачем это надо, кто это будет читать, вы там всякого по напишите), то мы ссылаемся, что у нас «регламент и процессы и начальник ругается, и в связи с этим мы не сможем эффективно отрабатывать фазы и задачи вашего проекта», заказчик соглашается. А потом сам втягивается, были случаи когда настойчиво звонили-просили статус-отчет прислать до обеда в четверг, а не как обычно в пятницу к 16:00.
Могу сказать, что стараемся работать «по этим уже нашим» ITIL, PRINCE, PMBoK, ISO и прочим сводам знаний. Удобно, приятно и четко, просто стараемся мягко приучать заказчика и своих сотрудников переносить эти знания к себе work progress и status bar ))).
OldPilot
«держать заказчика в курсе, несмотря на сопротивление» — не выходит ли такое поведение «боком»?
Не раз сталкивался, что заказчик не желает погружаться в тонкости и проблемы реализации. А подобную активность расценивает как желание «переложить с больной головы на здоровую».
theHelg
Конечно, не всегда это работает. Если это не уровень заказчика, например, слишком технические детали, то не стоит.
Но если это принесет пользу проекту, когда заказчик просто «прячет голову в песок, мол вы там сами уж как-нибудь» — то подключение его к решению проблем втягивает его в процесс и облегчает принятие последующих менеджерских решений
mpopov
ИМХО заказчику не нужно знать тонкости и проблемы реализации. Но ему необходимо знать о проектных рисках связанных с проблемами реализации. Часто заказчик не понимает, что задержка одной из активностей (на критическом пути проекта) может сорвать весь проект. И необходимо напоминать ему о влиянии таких рисков всегда, когда вероятность риска повышается.
slowcountry2
Полностью поддерживаю, что не стоит оповещать заказчика о каждом шаге, сделанном командой на пути к решению его задач. Но! Отделываться общими фразами «Все ОК!» — тоже не к добру. Ибо если вдруг что — как вы объясните, почему сегодня «Все не ОК!». И вашу задачу мы решим не в оговоренный срок. Клиент может подумать, что вы вообще все это время ничего не делали, а только видимость работы создавали. И да, «Еженедельный статус-отчет исполнения проекта» — отличная мысль.
П.С. Первая фраза статьи — рассмешила. Спасибо.