Что такое эскалация в управлении проектами и зачем она нужна?

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

Итак, что такое эскалация? Википедия дает универсальное определение – это постепенное увеличение, усиление, расширение чего-либо (например, коррупции во власти, или эскалация войны); наращивание (вооружений и т. п.), распространение (конфликта и т. п.), обострение (положения и т. п.).

Красиво, но связать с управлением проектами сложно, а ведь все очень просто.

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

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

Эскалация – это также один из основных инструментов, используемых в ходе управления рисками.

Мои правила эскалации:

1. Попробовать договориться без эскалации.
2. Если не удалось – честно предупредить, что раз мы не договорились – я вынуждена эскалировать вопрос на такого-то менеджера, потому что интересы проекта и все такое. После этого чудесным образом в половине случаев договориться удается.
3. Продумать внятную аргументацию с позиции влияния поднимаемого вопроса на проект и на его результаты/сроки/бюджет и другие ограничения.
4. Включить в письмо (поставить в копию) или позвать на встречу с руководителем вторую сторону конфликта, чтобы решать вопрос совместно. В случае если вопрос критически важен для проекта – не забыть включить в процесс спонсора проекта, заранее согласовав с ним свою позицию.
5. Получить результат, помня при этом, что отрицательное решение – это тоже результат. И если, например, мне в ходе эскалации не удалось получить нужный ресурс, это повод отразить это в плане управления рисками и отметить в протоколе, что в итоге влияние на проект такое-то.
6. Продолжать работать в обычном режиме, не делая выводов типа «все они неправы», «менеджер, не давший ресурс – негодяй», «да делайте тогда сами свой проект, кому из нас это вообще надо» и проч. Эскалация – рабочий процесс, в котором нет места личному восприятию. Хотя некоторые поправки в план управления стейкхолдерами после этого можно внести, так как теперь вы лучше представляете их мотивацию, влияние и проч.

Часто руководители проектов боятся самого слова «эскалация», почему-то считая, что в случае, если они вынесут проблему выше, они продемонстрируют свою некомпетентность, неумение управлять командой и проч. А зря, пока вы не генеральный директор – 100% влияния и власти у вас все равно не будет (да и в случае с генеральным директором тоже), а значит – ситуации, в которых понадобится эскалации, неизбежны. И лучше сделать это раньше, пока проекту не нанесен совсем уж большой урон.

Традиционный пример с ремонтом:

1. Идет ремонт в новостройке, на объекте работает бригада во главе с прорабом и дизайнер интерьера, осуществляющий авторский надзор за работами. Цель проекта вроде бы одна – сделать так, чтобы вы скорее въехали в свою уютную квартиру, сделанную в точном соответствии с дизайн-проектом. Закупки делают они же.
2. Ситуация 1: В магазине не оказалось той самой плитки, которая так хорошо смотрелась на визуализации. Неправильно: купить похожую плитку самим или заказать такую же, но ждать ее получения три месяца. Мне ничего не говорить, чтобы я не подумала, что они непрофессионалы, которые не в состоянии справиться с простой проблемой. Правильно: сформулировать, какие есть варианты (для варианта замены плитки – обновить визуализацию) и спросить меня. Типичный пример эскалации, все логично, но заменить плитку на закупку серверов с «не теми» характеристиками – и вот вам потенциальный срыв проекта из-за того, что кто-то побоялся вовремя эскалировать.
3. Ситуация 2: дизайнер считает, что розетки и выключатели должны быть сделаны ровно как в дизайн-проекте и на его чертежах, а прораб – что часть комплектующих надо заменить, они красивые, но нефункциональные по его опыту в других квартирах. Неправильно: поругаться, считать, что другой – некомпетентен и «просто не умеет их готовить», затянуть конфликт, но мне ни за что не говорить. Тоже неправильно – прийти ко мне по отдельности, «настучать» на непрофессионализм коллеги, попросить принять мою сторону. Я все равно буду слушать обоих, но «на карандаш» сам подход возьму. Правильно: сформулировать, почему будет неудобно пользоваться (возможно, для меня это не будет проблемой?), объяснить, что можно сделать и как это повлияет на проект в целом (придется докупать новые розетки на всю квартиру на 30 000 рублей? задержится срок на 2 недели?), привести примеры и дать контакты людей, у которых с этим комплектующими все работает красиво и удобно.

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

Купить курс за 2990 руб

Подробнее про курс

P.S. Перед новым годом был пост с хорошей картинкой в тему.