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

Отчетность в стиле «как мы провели прошлую неделю» работает очень ограниченно

Начнем с примера отчета, который менеджер проекта отправляет своему руководителю (например, спонсору/куратору проекта). Отчет я выдумал, но очень близко к тексту реальных отчетов, которые я видел в реальных компаниях с которыми работал.

За эту неделю закончили разработку модуля Х.
Пилотирование модуля задерживается из-за проблем на стороне департамента А. Они загружены отчетностью и не могут приступить к тестированию. Обещают на этой неделе начать.
На следующей неделе планируем пройти тестирование модуля Х.
Также приступаем к разработке бэкенд функционала для модуля Y.

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

Но можно ли из этого отчета сделать уверенные выводы о том,

1. Успеваем ли мы к важному дедлайну, вроде окончания этапа, проекта, старту продаж?
2. На что влияет задержка тестирования модуля Х? Задержка на неделю — это много или мало?
3. Насколько серьезные проблемы у проекта, надо ли руководителю вмешиваться?

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

Если у спонсора один-два-три проекта, с этим еще можно жить: все-таки память у него хорошая. Но можно ли так курировать десять, двадцать, пятьдесят проектов? Нет.

Каким же критериям должна соответствовать отчетность, лишенная этих проблем?

Отчет показывает прогресс, прогноз и отклонение

Прогресс надо показывать через соотнесение плановых, прогнозных и фактических значений. Пример:

Ранее мы договаривались, что разработка модуля Y должна закончиться к 30-му ноября. Это план.
Сегодня менеджер понимает, что команда успевает только к 6-му декабря. Это прогноз.
Модуль Х был разработан 16 ноября. Это — факт. А план был — 1 ноября.

Теперь мы видим следующую картину:

Разработка модуля Х. Готово. План: 01.11. Факт: 16.11
Тестирование модуля Х. В работе. План: 19.11. Прогноз: 26.11
Разработка модуля Y. В работе. План: 30.11. Прогноз: 06.12

Окей, стало лучше, появилась конкретика, но улучшения не драматические. Что неудобно? Во-первых, это по-прежнему текст, и нужная информация считывается не сразу. Во-вторых, непонятны масштабы проблемы.

Отчет подсказывает, куда смотреть и не жрет «мыслетопливо»

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

Стало лучше? Красные циферки прямо «прыгают в глаза».

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

Если мы представим, что у нас не один менеджер, а пять, и у каждого по три-пять-десять задач, или календарный план больше 1000 задач, то на планерке вы это никогда не обсудите. Зато вы можете обсудить только те, где ∆ больше 5 дней, например. Таких задач будет всего несколько штук.

Я проделывал такой фокус, когда настраивал планерку своего шефа в одной компании. Совещание департамента, которое длилось по полтора часа, стало проходить 15 минут, когда мы сфокусировали его на отклонениях.

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

Новые перспективы открывает календарно-сетевой график. Если работы в плане связаны с другими и, уезжая вправо по линии времени, толкают своих последователей, то мы можем заметить, что задержка тестирования модуля Х приведет к сдвигу опытно-промышленной эксплуатации (ОПЭ), а это уже живые деньги, которые мы могли бы заработать, начав применять систему. А если речь идет о запуске продаж? Олимпиады? Там даже один день просрочки — это очень дорогой провал.

Отчет помогает принять решение

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

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

Чтобы отчетность помогала принять решение, надо добавить контекст и комментарии или иные сигналы от менеджера, помогающие понять его мнение о причинах проблем и необходимых решениях.

Давайте добавим к нашему отчету индикатор «критичность» (заполняет менеджер проекта вручную) и комментарий.

Вот это уже другое дело. Тут можно понять: здесь — есть отклонение, но менеджер справляется, а тут — нужно повышенное внимание.

Отчетность должна быть полна, а не «тут отчитываемся, тут — забыл»

Чтобы быть уверенными, что мы ничего не пропускаем, надо убедиться, что отчетность формируется по четким правилам и по всем объектам, которыми мы управляем. Это отдельная большая история, для краткости сосредоточимся на маст-хэв любой проектной отчетности:

1. Календарный план.
2. Поручения.
3. Проблемы/открытые вопросы. Очень полезный инструмент менеджера проекта. Когда-нибудь напишу о нем отдельно. Если в двух словах, то это какая-то ситуация или вопрос, с которой нужно что-то делать, иначе будет плохо. Например, уволился разработчик — это проблема. Связанные задачи: «Написать бриф вакансии и отравить в эйчар», «Обзвонить своих знакомых разработчиков» и т. п.
4. Риски. В отличие от проблемы, это какая-то вероятностная штука, т. е. не факт еще, что произойдет. Например, «В январе может выйти новый ФЗ, который изменит требования к нашей системе, что увеличит объем работ». Добавлю, что идентифицировать риски и управлять ими довольно сложно, поэтому это продвинутый уровень РП.

Оставляю за скобками бюджет: финансовая отчетность — отдельная тема.

Принципы отчетности для всех этих объектов похожие: попал объект в реестр? Будь любезен, отчитайся. Например:

Все поручения попадают в реестр поручений и ответственные отчитываются по ним, только если просят перенос срока (или каждую неделю, что сделано, вне зависимости от сроков).

Или:

Менеджер пишет комментарий по тем работам календарного плана, где есть отклонение более 5 дней.

Вот, во что превращается наша секси-экселька.

Уже не очень секси, хотите сказать? Посмотрели бы вы на БДДС или БДР у финансистов. С любой отчетностью надо учиться работать. Но за счет того, что она единообразна, подсвечивает отклонения и компактна, вы довольно быстро к ней привыкнете, и сможете например, читать с листа А4 отчет о состоянии портфеля из 50 проектов.

Отчет должен быть многоуровневым

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

1. Руководитель проекта смотрит все работы календарного плана, все поручения и т. д.
2. Спонсор/куратор смотрит только важные вехи календарного плана: старт ОПЭ, сдача функционала, заключение контрактов, ключевые риски, отклонения по бюджету.
3. Топ-руководство в составе Проектного комитета интересует только когда результаты проекта начнут приносить пользу компании (генерить прибыль), поэтому им важны только окончания этапов и проекта в целом, а также сводные индикаторы по бюджету и рискам.

В сводном отчете по портфелю каждому проекту может быть посвящена вот такая строка:

Все индикаторы, из которых она состоит, собираются из предыдущих секси-табличек, которые я показывал.

Отчет формируем по графику, а не «когда есть, что показать»

Это не самая интуитивная мысль, но очень важная: отчетность должна формироваться по графику. Потому что если мы идем по дорожке «ну, что мы будем руководство беспокоить по таким мелочам, ничего же особого не произошло», то скоро возникает вопрос: кто оценивает, что же такого «особого» должно произойти, чтобы показать руководству? Не факт, что исполнитель или менеджер правильно этот момент определит.

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

Как сделать, чтобы это заработало?

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

Для тех, кого сочетание слов «отчетность» и «экселька» пугает, добавлю, что в идеальном мире, конечно же, эта отчетность формируется из системы управления проектами. Но, в принципе, я и на экселях настраивал такую систему, и она требовала от руководителя проекта 15-30 минут в неделю на заполнение, а на выходе получался отчет примерно как на последнем скриншоте. По-моему, вполне приемлемые трудозатраты. Планирую в дальнейшем опубликовать этот кейс.

Да, кстати, подписывайтесь на меня в Телеге, если еще не. Пишу туда довольно регулярно про проектное управление, управление собственной продуктивностью и лидерство.