Ваш проект идет херово, и результатов вы дать не можете. Что делать?
Когда проект идёт плохо, у многих включается первая реакция: спрятать, дожать, исправить самой, сделать вид, что всё ещё “под контролем”.
Особенно если проект твой. Особенно если есть люди в подчинении, внешняя команда, IT, юридические ограничения, бюрократия, медленные согласования и ощущение, что сейчас всё это каким-то образом станет твоей персональной виной.
Но взрослая управленческая позиция начинается не с того, что у вас никогда не горят проекты. Она начинается с того, как вы эскалируете, когда они горят и какие решения вы предлагаете.
Неудачный проект или сложность нужно эскалировать не как эмоциональную исповедь, а как управленческий кейс.
Не “у нас всё плохо, я не знаю, что делать”,
а:
“Ситуация такая. Проект зависит от X. Сейчас блокер находится в Y. Мы уже сделали A, B, C. Из-за ограничений процесс занял столько-то времени, и по текущей скорости займёт ещё столько-то. Это означает, что первоначальный результат в срок невозможен. Предлагаю три варианта: снизить scope, зафиксировать blockers as outcome или перевести проект в следующую фазу после решения зависимости. Мне нужно управленческое решение по варианту 1/2/3”.
В этом месте происходит важная вещь: вы перестаёте выглядеть человеком, который “не справился”, и начинаете выглядеть человеком, который управляет реальностью.
Большая ошибка — эскалировать слишком поздно. Многие думают: “Сначала я ещё попробую сама. Ещё напишу. Ещё подожду. Ещё попинаю процесс”. И так проходит неделя, потом две, потом дедлайн уже не риск, а факт.
В менеджменте плохая новость, сказанная рано, — это управление риском.
Плохая новость, сказанная поздно, — это уже репутационный ущерб, причем и вам, и вашему менеджеру, и вашей компании, если работаете с клиентами.
Чтобы сложность не выглядела как ваша ошибка, важно разделять три вещи.
Первое: что было в вашей зоне ответственности.
Например: поставить цель, организовать работу, нанять людей, выстроить коммуникацию, собрать требования, зафиксировать прогресс, подсветить риски.
Второе: что было внешней зависимостью.
Например: IT-restrictions, юридические согласования, доступы, безопасность, регламенты, невозможность использовать нужную инфраструктуру.
Третье: что вы сделали, чтобы управлять этой зависимостью.
Вот это ключевой слой. Руководству обычно не нужно слышать “это не моя вина”. Руководству нужно видеть, что вы не были пассивны.
Пример: “IT не дал доступ” заменяем на “Мы запросили доступ 10 августа, получили ответ 2 сент, предложили альтернативный вариант 4 сент, провели встречу с юристами 25 сент, зафиксировали ограничения письменно и подготовили fallback scenario”. Это совсем другой уровень разговора.
И таким образом вы спите спокойно, все основные люди осведомлены, и вашей репутации ничего не грозит.
Писать еще примеры таких неудобных коммуникаций? Если да, ставьте огоньки 🔥
