Управление по исключениям или эскалация в проектном менеджменте +4


AliExpress RU&CIS

Известная всем «простая истина» гласит, что менеджер проекта всецело отвечает за достижение целей проекта (об этом говорит и PMBoK, и стандарты ISO). При этом в зависимости от масштаба и бюджета проекта различные группы навыков руководителей проектов выходят на разные уровни: маленький проект чаще всего предполагает сильные технические скиллы, крупные проекты – лидерские и стратегические навыки взаимодействия со стейкхолдерами и заинтересованными лицами.

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

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

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

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

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

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

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

  1. Выявите заинтересованность или ее отсутствие в решении проблемы путем диалога. Другими словами – попробуйте просто спросить почему нет (почему не решается проблема или у кого отсутствует интерес к ее решению).

  2. Открыто оповестите противоположную сторону о необходимости/потребности в эскалации, тем самым вы избавитесь от подковёрных игр и наращивания негатива в проекте после эскалации.

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

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

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




Комментарии (2):

  1. Ion_Storm
    /#23097276

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

  2. expat2by
    /#23097444

    Natalia, спасибо большое за статью, поделюсь ее со своими коллегами!

    Отличная статья и даны правильные методы эскалации.

    Хотелось бы обсудить и получить рекомендации по следующим моментам:

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

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

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

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