У меня есть простая аналогия для настройки процессов с точки зрения исполнителя.

Представьте себе продавца, который занимается холодным обзвоном. У него в CRMке специально для холодных обзвонов должен быть простейший интерфейс, состоящий из:

• Надо позвонить (стопка, из которой он берет верхнюю карточку)
• Звоню (карточка, скрипт)
• Прозвонил (возможно — «успех»/«неудача»)

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

Как вы думаете, какова будет продуктивность по сравнению с первым сценарием?

Во всех интерфейсах систем, которые предназначены для работы с задачами, стремитесь к однозначности:

• У каждого члена команды есть одна ссылка, на которую он нажимает, чтобы увидеть свои задачи.
• На доске нет мертвых задач, настроены быстрые фильтры.
• Все формулировки задач предельно однозначны, и подсказывают, что нужно сделать.

А у вас в таск-трекере порядок?

Мой первый опыт внедрения проектного управления в компании был провальным.

Я руководил проектным офисом — подразделением компании, отвечающим за разработку методологии проектного управления, формирование портфеля проектов, сбор отчетности по проектам и т. п. Я пытался заставить руководителей и кураторов проектов, не подчинявшихся мне напрямую, работать по новым правилам, например — проводить планерки по-новому, а они мне говорили: «Вася, ты будешь нам рассказывать, как планерки проводить? Мы и так отлично справляемся».

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

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

Проектный офис часто «лезет не в свое дело»

Часто я вижу, как представители проектного офиса лезут в проекты с «добрыми советами»: пытаются обучить, заставить правильно проводить планерки, управлять рисками и т. д.
Когда на неё нет запроса, эта работа проектного офиса воспринимается как то, что он лезет, куда не просят, и говорит: «Вы неправильно живете» — проект неправильно оформили, не по процедуре, и т. д. Это как минимум раздражает, даже если правда.

И если потом функциональные руководители приходят к биг боссам жаловаться на проектный офис, их административный вес обычно будет больше, даже если проектный офис прав. Потому что за каждым из функциональных руководителей стоит какая-то часть бизнеса, дающая очень конкретный и обычно измеримый вклад в общее дело. А проектный офис «координирует остальных участников», «задает правила игры»... а как конкретно помогает зарабатывать — очень сложно посчитать.

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

Надо четко очертить границы проекта и не лезть в них

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

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

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

3. Проекту нужны коммуникации с руководством и промежуточный контроль — все это понимают, все взрослые люди. Поэтому раз в период вы будете предоставлять отчетность вот по этой форме. Она единая для всех проектов, руководству удобно ее смотреть, вам ее удобно предоставлять.

4. Внутри этих границ вы вольны руководить проектами как бог на душу положит: вы — профессионалы, мы вам доверяем. Не хотите проводить планерки — ваше дело.

Чего я этим добиваюсь?

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

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

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

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

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

Например, не выполняется в срок контрольная точка из плана:
«2022-09-13 — Сдан в ОПЭ модуль „Бюджетирование“»
Мы можем 13 сентября сходить в бухгалтерию, и посмотреть своими глазами, сдан модуль в эксплуатацию или нет. И вот уже у нас есть неоспоримый факт: не соблюдена контрольная точка, и разговор проектного офиса становится гораздо конкретнее, и от него так не отмахнешься.
— Не выполнили контрольную точку? Вы должны инициировать процедуру переноса сроков, эскалации и т. д.
— Систематически не выполняются контрольные точки? Вот вам рейтинг руководителей или КПЭ, вы в нем в красной зоне. И вот уже руководителю проектов сложно сказать «я таких проектов сделал сотни, не надо меня учить». Глядишь, он и сам приходит на вебинар по управлению сроками, рисками и т. д.

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

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

Ко мне часто обращаются менеджеры, которым надо «навести порядок», «вернуть чувство руля», «систематизировать бизнес». Симптомы типичны:

• Каждый член команды усердно работает над своими задачами, но общий результат оказывается не достигнут.
• Задачи ставятся и теряются, находятся тогда, когда уже поздно.
• Очередной раз «перепрыгнули пропасть на 99%».
• Менеджер чувствует, что проект «разъезжается»: в шквале текучки теряется фокус на результатах и поддерживать его требует огромных усилий.

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

Менеджер должен регулярно «проверять домашку», иначе все забьют

Вспомните школьные годы. Если вы точно знали, что вас спросят домашнее задание на следующем уроке, каковы были шансы, что вы его подготовите? Для большинства людей — близко к 100%. Для взрослых это работает так же.

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

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

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

Регулярные совещания должны охватывать разные горизонты и аспекты управления

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

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

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

Также рисками можно управлять на нескольких горизонтах: выявлять риски проекта целиком, координировать действия по их предотвращению или подключать «план Б» на оперативном горизонте.

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

Как настроить график совещаний так, чтобы ничего не упускать?

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

1. Регулярность, длительность, участники, роли участников
2. Типовая повестка
3. Материалы, в первую очередь — отчетность, заточенная под повестку
4. Правила подготовки (в виде чек-листов)
5. Правила проведения совещания (Например, как делаем доклад? Как поступаем, если возникла посторонняя тема в обсуждении? Предусмотрено ли вообще обсуждение на встрече?)
6. Правила обработки результатов (ведение протоколов и пр.)

Вот пример таблицы с описанием совещаний. Внутри — чек-листы для подготовки, описание ролей и материалы.

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

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

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

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

За эту неделю закончили разработку модуля Х.
Пилотирование модуля задерживается из-за проблем на стороне департамента А. Они загружены отчетностью и не могут приступить к тестированию. Обещают на этой неделе начать.
На следующей неделе планируем пройти тестирование модуля Х.
Также приступаем к разработке бэкенд функционала для модуля 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 минут в неделю на заполнение, а на выходе получался отчет примерно как на последнем скриншоте. По-моему, вполне приемлемые трудозатраты. Планирую в дальнейшем опубликовать этот кейс.

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