Почему руководство узнаёт о проблемах проекта последним

Плохая новость не спешит наверх

Проект отстаёт от графика. Руководитель проекта это видит, но наверх проблему не выносит. Он надеется исправить всё сам или ждёт, что подрядчик напряжётся и что-нибудь придумает. Куратор проекта тоже в курсе и тоже ждёт: рассчитывает, что команда мобилизуется и нагонит отставание. Никто не хочет выглядеть некрасиво.

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

Надежда эта не пустая, и в этом её коварство. Иногда команда действительно нагоняет, подрядчик находит выход и проект возвращается в график без единого неприятного разговора. Такой случай запоминается как подтверждение: правильно сделали, что не поторопились.

Если посмотреть на выбор глазами руководителя проекта, он почти очевиден. Сообщить сейчас - значит наверняка получить тяжёлый разговор: «Как так получилось?» и «Ну и как ты теперь предлагаешь выкручиваться?». Подождать - значит получить шанс, что разговор не понадобится вовсе. Куратор рассуждает так же. Только его тяжёлый разговор будет уровнем выше, и прийти туда с отстающим проектом хочется ещё меньше.

Каждый шаг по отдельности разумен, а вместе они складываются в задержку, которую никто не выбирал.

Эту проблему я встретил в канале Антона Субчева, директора PMO в Сбере. По его оценке, между тем, что реально происходит в проекте, и кабинетом владельца обычно стоят два-три уровня менеджеров. У каждого свои интересы и своё понимание того, как представить статус. Пока новость поднимается по этим уровням, исправление, которое на раннем этапе обошлось бы недорого, становится заметно дороже. И как пишет Антон «При смене команды картина повторяется».

Если считать задержку враньём, остаётся найти виноватого и заменить. Но если причина переживает замену людей, искать её надо в том, как устроена работа. Иначе новый руководитель проекта встанет перед тем же выбором.

Для проектного офиса здесь есть конкретная задача: сокращать время от обнаружения проблемы до решения руководства. Давайте разберемся, что тут можно сделать.

Что показывает статус

Допустим, руководитель проекта ничего не придерживает и честно приносит статус. Тогда всё зависит от того, на какой вопрос этот статус отвечает. Часто в отчёте есть процент готовности и интегральный цвет состояния проекта: зелёный, жёлтый или красный.

Про проценты точно пишет Сергей Колганов. Начинающий менеджер верит, что в словах о трёхдневной задаче, которая на второй день выполнена на 87%, есть смысл. Но для управления сроком важнее другое: сколько времени осталось до завершения по актуальной оценке.

С целым проектом происходит то же самое, только выглядит солиднее. Сам по себе процент готовности не говорит, когда работа закончится и во что обойдётся опоздание.

В разборе Epicflow есть показательный пример. Плановая дата окончания проекта остаётся прежней, 30 сентября. При этом прогноз с учётом загрузки специалистов уже показывает 7 октября. Если отчёт следит только за изменением плановой даты, отклонений в нём ещё нет. В прогнозе опоздание уже есть, а вместе с ним возможные финансовые последствия.

Такой статус может оставаться зелёным без всякого обмана. Просто он показывает, что план пока не меняли, а руководству нужно понимать, достижим ли этот план и требуется ли вмешательство.

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

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

Факты те же, а цвет остаётся зелёным, потому что прогноз сделан из надежды.

Хорошая форма статуса оставляет надежде меньше места, но убрать её не может. Остаётся вопрос, когда и с чем человек готов выйти наверх.

Сигналу незачем ждать плана

Отсюда легко прийти к жёсткому правилу: увидел проблему - сразу сообщи. Но руководитель проекта может возразить: сначала надо разобраться. Проблема без вариантов решения приносит комитету тревогу, а команде вопрос «Что вы пришли с пустыми руками?». Если таких сообщений много, руководство привыкает воспринимать их как шум.

Поэтому желание сначала подготовиться само по себе разумно. Проблема начинается, когда подготовка решения становится условием первого сообщения.

У нас это противоречие разрешается в два шага. Со сложной проблемой команда может выйти на очередной управляющий комитет со статусом «проблема выявлена», поделиться первыми гипотезами и получить поручение проработать варианты. Затем она возвращается с оценками и запросом на изменение проекта (ЗНИ).

Для руководителя проекта разница большая. С первого комитета он уходит с понятной работой и согласованным сроком. Плохая новость становится вопросом, о котором руководство знает и по которому ожидает продолжения.

На первом обсуждении комитет может повлиять и на саму проработку: предложить другой вариант, уточнить ограничения или потребовать более раннего решения.

Первый сигнал и готовый план - это два разных результата. Если требовать их одновременно, сигнал будет ждать, пока появится план.

Особенно заметно это при редких заседаниях. Большим достижением нашей компании я считаю регулярное проведение управляющих комитетов для ИТ-проектов: в стадии реализации они проходят не реже раза в квартал. Но даже такой порядок оставлял возможность надолго отложить разговор.

Раньше команды рассуждали так: если проблема выявлена за пару недель до УК, оценить варианты уже не успеем. Выходить без решения нельзя, значит, перенесём вопрос на следующий комитет. В результате рассмотрение альтернатив и принятие решения могли задержаться на четыре-пять месяцев.

Теперь неготовность вариантов не мешает вынести проблему на ближайший УК. Комитет узнаёт о ней раньше и видит предполагаемый срок подготовки решения. Если срок или первые гипотезы его не устраивают, он назначает отдельную дату и внеплановую встречу.

Это ещё не означает, что руководство узнаёт о каждой проблеме немедленно: ожидание ближайшего заседания остаётся частью пути. Но из него убирается дополнительная задержка (пропуск комитета только потому, что команда пока не готова предложить решение).

Что происходит после первого сообщения

Сам по себе такой порядок людей не убеждает. Руководитель проекта всё равно взвешивает, стоит ли выходить на тяжёлый разговор или лучше попробовать обойтись без него.

Если за первым сигналом без плана следует разнос, расчёт подтверждается. В следующий раз человек придёт позже — когда подготовит ответ на все вопросы или когда скрывать проблему станет невозможно.

Поэтому мы в проектном офисе отдельно прикладываем усилия, чтобы показать командам другой исход. Своевременное сообщение может принести помощь: у руководства иногда есть возможности, которых изнутри проекта не видно.

Одних формальных статусных встреч для этого недостаточно. Мы проводим отдельные сессии с командами: обсуждаем риски, разбираем, что может пойти не так, и стараемся говорить об этом до того, как угроза превратится в срыв.

У таких разговоров есть практическое следствие. Если выявленный риск соответствует нашим критериям, он уже влияет на цвет проекта, хотя срок ещё не нарушен. Руководителю проекта при этом не нужно объявлять, что он не справился. Достаточно показать угрозу и основания, по которым он считает её существенной.

Так у руководства появляется время вмешаться, пока вариантов ещё много.

Но доверие возникает только тогда, когда реакция на такие сообщения подтверждает сказанное. Команда быстро замечает, помогает ли ранняя открытость или лишь приближает неприятный разговор.

Сколько вопрос идет до решения

Чтобы понимать, где теряется время, нужны три точки:

1. Когда в команде появились достаточные основания считать, что цели проекта под угрозой.
2. Когда об этом впервые сообщили руководству.
3. Когда было принято решение о дальнейших действиях.

Между ними — время на сигнал и время на решение.

Долгий первый промежуток требует разобраться, почему угроза не стала видна раньше. Новость придерживали? Статус её не показывал? Команда до последнего считала, что справится сама? Или ждала подходящего случая, чтобы сообщить?

Долгий второй промежуток требует другого разбора. Чего не хватало для решения: оценённых вариантов, согласований, полномочий? Сколько времени заняла работа, а сколько вопрос просто ждал заседания?

Если смотреть только на общий срок, эти причины сливаются. Тогда легко начать требовать от команды более раннего информирования, хотя вопрос уже несколько месяцев находится у руководства. Или ускорять комитеты, до которых плохие новости всё равно не доходят.

В большой компании есть правило: всё, что не зафиксировано в мемо или протоколах, того не было. В нашем процессе сообщение проблемы на УК и принятое решение оставляют след в протоколах. На всех комитетах я физически присутствовать не могу, но через моё согласование проходят важные решения, и по заметкам можно восстановить историю вопроса. Как устроены эти заметки, я рассказывал в статье о работе с информацией по проектам.

С первой датой сложнее. Угроза редко становится очевидной в один момент: сначала возникает подозрение, потом появляются факты, затем становится трудно объяснять их случайностью. Люди могут добросовестно помнить этот путь по-разному. А признаваться, что основания для тревоги появились давно, бывает неприятно.

Поэтому вопрос «Когда вы это заметили?» полезен прежде всего для разбора процесса. Если использовать ответ для наказания, появится ещё одна дата, которую выгодно показывать красивее.

Нам важно понять, что помешало сообщить раньше и что нужно изменить, чтобы в следующий раз сигнал прошёл быстрее.

Чем в этих условиях может быть полезен проектный офис

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

Если команды видят в PMO только контролёра, который найдёт проблему и покажет на виноватого, они будут осторожнее делиться сомнениями. Проектный офис, к которому никто не приходит с плохими новостями, узнаёт о них вместе с руководством.

Поэтому помощь команде и достоверное информирование руководства связаны напрямую. Помогая увидеть угрозу, сформулировать её и вынести на обсуждение, проектный офис делает проблему видимой раньше.

На время до первого сигнала мы влияем непосредственно: через статусы с прогнозом и рисками, отдельные разговоры с командами и возможность прийти на УК без готового плана.

На время до решения влияем меньше. Но можем сделать его видимым: показать, сколько вопрос находится на рассмотрении, чего ему не хватает и где требуется вмешательство.

Решающим остаётся то, как куратор и комитет встречают первое сообщение. От этого зависит, придёт ли следующее. Если на слова «проблема выявлена» отвечают поиском виноватого, новый руководитель проекта снова будет ждать, пока подрядчик нагонит. Когда новость всё же дойдёт, часть вариантов уже исчезнет.

Руководство узнаёт о проблемах тем позже, чем дороже обходится сообщить ему первым. А цену первого сообщения назначает тот, кто его слышит.