В этой статье — неочевидный взгляд на эффективность совещаний в ERP-проектах: не количество совещаний или участников, а результат.
В отличие от муравейника, где муравьи на генетическом уровне знают, что им надо делать и как взаимодействовать (Рис. 1), на проекте внедрения ERP без совещаний не обойтись, т.к. создается новое окружение во взаимодействии большого числа участников и факторов.
Сразу перейду к главному тезису, на мой взгляд нет одного правильного подхода к совещаниям, все определяется контекстом: эффективность совещаний в проектах внедрения ERP систем объективно определяется исключительно результатами проекта.
Поясню, рассмотрим две крайности:
В ходе проекте было мало совещаний, с минимальным кол-вом участников, длительность строго ограничено и т.п., все участники довольны, но результат проекта не достигнут. В результате совещания проводились Неэффективно, т.к. не привели к результату и все время потрачено зря
Обратная ситуация в ходе проекта было много совещаний, с максимальным количеством участников, длительность произвольная неограниченная и т.п., большинство участников не довольны подходом к проведению совещаний, но результат проекта достигнут. В результате совещания проводились Эффективно, т.к. привели к результату и все время потраченное на совещания трансформировалось в ценность для бизнеса
Ниже попробую описать основные функции разных типов проектных совещаний, чтобы максимально способствовать эффективности проекта.
Управляющий комитет (далее – УК)
Регулярное совещание, в зависимости от потребностей проводится 1-4 раза в месяц с обязательным участием Топ-менеджмента Заказчика и Подрядчика.
Основные цели:
рассказать про крупные достижения\прогресс
попросить помощь у ТОПов в решение проблем
подсветить риски
Основная ошибка при подготовке таких совещаний - сглаживать «углы», не акцентировать внимание на проблемах. По опыту, участники склонны избегать обсуждения проблем на высоком уровне, поэтому, естественно не хочется идти с проблемами на УК, чтобы получить «развивающую обратную связь», но для эффективности проекта – это ошибка. Здоровая ситуация состоит в том, что Заказчику нужна ЕРП-система. Исполнителю, если внутренний, то премии, если внешний подрядчик – прибыльный проект. Т.о. когда ТОПы выделяют час в своем плотном расписании, чтобы погрузиться в контекст проекта и принять решения, которые входят в их зону ответственности, эффективно для проекта воспользоваться такой возможностью, в первую очередь речь о выделение ресурсов (бюджет, люди), сдвиге верхнеуровневых вех (а не относится как на Рис 2 из любимого «Ну погоди!»).
Есть вопросы в «серой зоне» (не утверждена детальная архитектура проекта, выделенный сотрудник не приступил к работе, подрядчик находится несколько недель в статусе «ТЗ почти готово» и т.п.), которые формально должны решаться не на ТОП уровне, но фактически решения по ним нет. Такие вопросы нужно пытаться решить самостоятельно до тех пор, пока они не начинают оказывать прямого влияния «deadline».
Хорошей практикой будет заранее обсудить на рабочем уровне с заинтересованными сторонами все вопросы, которые будут эскалированы на УК как проблемы, выслать презентацию за благовременно до УК, пригласить на совещание связанных с проблемой участников, которые не включены в постоянный состав УК. Ваша цель не искать виновников проблем, а устранить препятствия, которые мешают команде, достичь целей проекта.
Ежедневное совещание (daily)
Основные цели:
напомнить приоритеты команде
выявить стоп-факторы и прочие проблемы
синхронизироваться по связанным задачам
Желательно участие на дейли всех участников проекта, которые имеют существенное влияние на основные параметры проекта и выделяют на проект большую часть своего рабочего времени (тимлиды, ключевые пользователи, методологи, ведущие аналитики, архитекторы и т.п.).
Людям свойственно, закапываться в задачи, которые «ближе к телу», меняются способы достижения целей и промежуточных вех, у бизнес могут возникнуть изменения, вновь выявленные\появившиеся факторы – такие и похожие обстоятельства требуют изменения приоритетов.
Например, если вы планировали пройти к цели (ERP) по прямой (Рис. 3а), но оказалось, что она находится в лесу (Рис. 3б), то как только стало понятно, что цель в другом месте, необходимо сразу менять направление. Продолжение движения прямо приведет к потере времени и выгоранию, т.к. приложены огромные усилия, а результата нет.
Дейли должен быть жестко ограничен по времени и объему, лучше сделать 3 дейли по 20 минут для разных команд и тематик, чем один общий на 1 час. Например, развертывание инфраструктуры как правило, всегда можно выделить отдельно.
В условиях ограничения по времени одной из самых трудных задач становится найти баланс между решением конкретных проблем и выделением времени на обсуждение всего пула задач. Дилемма в том, что в большинстве случаев решение конкретных задач правильно выносить на отдельное совещание, но, если выявлен стоп фактор «на сегодня» и для решения его требуются те же участники daily, у которых больше нет свободного времени в календарях, соответственно, придется ждать общего свободного «окна». Такой подход приводит к непроизводительной потере времени – это не восполняемый ресурс в проекте. Правильного ответа здесь нет, по моему опыту в такой ситуации лучше пренебречь другими задачами дейли и устранить насущный «стоп-фактор» проекта.
Еженедельный статус по внедрению отдельного стрима\подсистемы\ бизнес-процесса верхнего уровня
Основные цели:
Обсудить прогресс с погружением в детали
Решить возникшие архитектурные или методологические вопросы (или договориться вынести на УК)
Разобрать вопросы\проблемы по стриму, которые накопились за неделю.
По сути это такой «deep dive» во все проблемы стрима. Важно, чтобы ответственными участниками к совещанию была проделана предварительная работа по анализу проблем (ы), сравнению вариантов решений, выявлению корневых причин и их устранению. Формат представления может быть разный, зависит от контекста и привычек, могу порекомендовать простой универсальный формат в виде таблицы: в заголовках колонок – описание вариантов решения, в строках – плюсы, минусы, риски, итог.
Это не исчерпывающий перечень совещаний, его можно взять за основу для понимания какие совещания есть на проекте и на чем держать фокус на таких совещаниях.
Как повысить отдачу от совещаний
В заключение хочу подсветить факторы, относящиеся ко всем видам совещаний.
На совещаниях должна быть обеспечена психологическая безопасность всех участников - атмосфера взаимного уважения, доверия и открытости, в которой каждый участник может свободно высказывать идеи, предложения или критику, честно признавать ошибки и просить о помощи, не боясь наказания или насмешек (подробнее, например можно прочитать про Project Aristotle в Google). Перефразируя книгу «Дети с небес» Джона Грея «Если ребёнок боится сказать правду, это сигнал для родителей пересмотреть методы воспитания.» можно сказать, что если участник проекта боится сказать правду, это сигнал для руководства проекта пересмотреть подход к проведению совещания (и скорей всего не только).
Это исключительно важно, т.к. вы не можете управлять прошлым, можете только будущим. Для принятия правильных управленческих решений необходимо максимально полно понимать честную текущую картину, какой бы не соответствующей ожиданиям она не была.
Даже в безопасной среде части участников комфортнее промолчать. Поэтому при обсуждении решений необходимо в явном виде привлекать всех погруженных в контекст проблемы участников (Помню кейс с восстановлением учета за длительный период, когда методолог с бизнесом договорились перепровести все документы за период. Решение уже фактически было принято, когда поинтересовался в явном виде у тимлида разработчиков, которые озвучил риски по длительности процедуры, мы «не попадаем» в deadline. В итоге придумали решение, которое укладывалось в срок. Опытным путем, все равно пришли бы к этому решению, но было потеряно бы несколько дней проекта).
На совещаниях (и не только) стремитесь всячески поощрять реальную заинтересованность всех участников проекта в достижении бизнес - результатов проекта, а не на выполнении отдельно персональных задач отдельных участников (как в комиксе про Гилберта рис 4). Это не дает сиюминутных результатов, но поможет выпутаться из непростых проблем, которые обязательно будут.
Отмечу, если совещания занимают большую часть рабочего времени- это значит, что неправильно определен объем проекта(фазы проекта), подробнее об этом поделился мнением в статье
Итог
Свел в таблицу основные виды совещаний.
Совещание | Цель | Частота | Обязательные участники |
УК | - рассказать про крупные достижения\прогресс - попросить помощь у ТОПов в решение проблем - подсветить риски | 1-4 раза в месяц | Топ-менеджмент всех участников проекта |
Daily | - напомнить приоритеты команде - выявить стоп-факторы и прочие проблемы - синхронизироваться по связанным задачам | 3-5 раз в неделю | Участники проекта, которые имеют существенное влияние на основные параметры проекта и выделяют на проект большую часть своего рабочего времени |
Статус по внедрению отдельного стрима | - обсудить прогресс с погружением в детали - решить возникшие архитектурные или методологические вопросы (или договориться вынести на УК) - разобрать вопросы\проблемы по стриму, которые накопились за неделю. | 1-2 раза в неделю | Участники ответственные за принятие решений по методологии и архитектуре |
На совещаниях сконцентрируйтесь на том, чтобы усилия проектной команды двигалась в направлении достижения бизнес-целей и устранению препятствий на пути их достижения. В таком случае всё время, потраченное на совещание, пройдёт с пользой.
