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

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

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

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

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

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

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

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

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

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

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

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

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