Как руководителю начать экономить свое время до 30% на ежедневном принятии решений и микроменеджменте? Как перестать контролировать каждого сотрудника и перестать тревожиться, что без вас что-то пойдет не так? Рассказываю про свой авторский метод и 3 шага, как создать такие правила управления проектами, которые решат проблему узких мест и помогут вашим сотрудникам действовать автономно.
Начну эту статью с самого простого и наглядного примера. Почему в Макдональдсе, несмотря на высокую текучку, качество продукции остается неизменным?
Система работы выстроена таким образом, что в компании нет незаменимых сотрудников. Люди приходят и быстро обучаются внутренней технологии, а процесс производства остается стабильным, независимо от того, кто стоит за кассой или у плиты.
Да, управление проектами это вам не котлеты жарить, но… В любой успешной компании, независимо от отрасли, стабильность качества достигается за счет технологии. И в нашем случае – это единые правила управления проектами, которые позволяют:
подстраховаться от ухода ключевых сотрудников и потери знаний
ускорить процесс онбординга новых руководителей проектов
быстро передать проект джуниору, если опытного руководителя нужно поставить на более важный, крупный проект
Но самое главное это то, что единые правила помогают руководству высвободить время и энергию, которые приходится тратить на принятие решений. Без них приходится каждый раз проходить весь цикл принятия решения с нуля, а именно:
понять, в чем проблема и какие у нее последствия
выбрать подходящее решение из множества возможных альтернатив
договориться с заинтересованными сторонами, чтобы избежать сопротивления
внедрить решение и убедиться, что оно работает
Например, что делать, если уходит ключевой сотрудник, как "вытащить" знания из его головы по проектам, которые он вел? Можно каждый раз собираться и тратить время на поиск решения, а можно – следовать правилам, которые созданы для такой ситуации:
когда руководитель проекта достигает определенного уровня, "прикреплять" к нему младшего сотрудника для передачи опыта
по завершении проекта организовывать презентацию кейса с отсылками на все необходимые материалы
внедрять чек-листы по передаче дел, которые сотрудник должен заполнить при увольнении и т.д.
Потому что правила – это и есть уже принятые решения по действию сотрудников в конкретных ситуациях.
Но есть нюанс. Каждый руководитель, осознавший необходимость единых правил управления проектами, рано или поздно приходит к мысли: «А может, посмотреть, как работают другие и внедрить то же самое у нас?» Ведь успешные компании уже выстроили свои процессы, значит, их можно просто скопировать?
Но это работает не совсем так, и ниже я поясню, почему слепое копирование чужого опыта – плохая идея.
Все лучшие практики являются лучшими только потому, что они хорошо работают в конкретной компании и учитывают корпоративную культуру, внутренние процессы, правила взаимодействия. Сейчас часто даже «лучшие практики» переименовывают в «хорошие» (имея в виду, что не стоит их слепо копировать).
Например, в одной компании процедура согласования документов занимает 3 месяца – для них это норма, встроенная в бизнес-процессы. А для вас такие сроки – катастрофа, которая парализует работу.
В другой компании регламенты и бизнес-правила создаются в электронной доске (типа Miro) или презентациях – быстро, удобно, наглядно. Но у вас такой формат не работает, потому что презентация не считается формальным документом – регламенты должны быть подготовлены в соответствии с внутренними стандартами предприятия и правилами документооборота.
Если мы говорим о внедрении новой корпоративной ИТ-системы, то в некоторых компаниях в рамках чендж-менеджмента успешно применяют индивидуальные сессии с сотрудниками для коучинга и сбора обратной связи. Но если в вашей компании руководители, проводящие подобные сессии, не обладают необходимыми навыками, а встречи тет-а-тет для сбора обратной связи не сочетаются с корпоративной культурой, то лучше пока забыть про эту практику.
Я не говорю о том, что не нужно смотреть, как делают другие. Но если вы хотите создать единые правила управления проектами, то опираться вам в первую очередь нужно не на чужой опыт, а на свой. И только после этого смотреть, что есть у других, что можно использовать у вас.
Чтобы создать единые правила управления проектами, которые:
будут работать на успех проектов без постоянного вмешательства руководства
не станут бесполезной бюрократической надстройкой, в которой никто не видит смысла
будут понятны и приняты всеми сотрудниками, что поможет им работать автономно
…дисстилируйте уже имеющийся успешный опыт, обогатите его лучшими внешними практиками, которые подходят контексту организации, и превратите его в правила управления проектами для всех участников – от исполнителей до высшего руководства.
Ниже расскажу, какие шаги вам нужно пройти, чтобы это сделать.
Шаг 1. Определяем типы проектов в организации и важные области внимания для достижения их целей
Например, есть несколько типов проектов, все они одинаково важны, но области внимания, которые нужно контролировать для достижения их целей, различны. Для коммерческого проекта в компании наиболее важны сроки реализации, маржинальность и удовлетворенность заказчика, а для внутренних проектов по совершенствованию процессов – приживаемость результатов.
Этот шаг критически важен, потому что разрабатываемые правила управления – это набор работающих инструментов, но их работоспособность будет зависеть от того, как именно вы их применяете.
А именно: не нужно применять все инструменты одинаково ко всем проектам. Если вы часто делаете масштабные проекты с большим количеством заинтересованных сторон, возьмите из этого набора инструментов реестр стейкхолдеров и используйте его, чтобы не упустить чьи-либо интересы. Но если в вашей компании ведутся и небольшие коммерческие проекты, зачем вам применять реестр стейкхолдеров и заниматься никому не нужной бюрократией?
Расскажу еще один пример. Для одного моего заказчика (ИТ-дочка крупной девелоперской компании) было важно формализовать фазу проработки концепции проекта, потому что раньше часто возникали ситуации, когда было трудно предугадать судьбу какой-либо инициативы. А именно: внутренний заказчик приходил в ИТ-отдел с идеей, а что будет дальше – неизвестно: то ли разработчики сразу начнут прорабатывать ее концепцию, то ли положат в долгий ящик, то ли скажут – у нас сейчас другие приоритеты, извините.
Мы помогли создать правила разработки концепции, но с гибким подходом: когда есть понятный или типовой проект и ИТ-отдел сразу говорит, что может его сделать, то стадию концепции можно пропустить. Но вот когда заказчик приходит с нетривиальным проектом (например, переход с Jira на российский аналог), где трудно оценить объем ресурсов, эффекты, стоимость… Здесь проект отправляется на проработку концепции к методологу и после этого снова возвращается к айтишникам – уже с описанием бизнес-процессов и требований, дающих представление о трудоемкости реализации.
Определяя типы проектов, вы определяете важные области внимания (аспекты). Это позволяет подобрать работающие инструменты для каждого из них и собрать свой набор, который станет основой для создания единых правил управления проектами.
Что дальше? Ниже описываю следующий шаг.
Шаг 2. Проверяем, что уже хорошо работает, чтобы управлять важными областями внимания, а что нет
А именно: какие инструменты (артефакты и события) уже хорошо работают для управления важными областями вниманием (аспектами), какие работают иногда, а какие не работают вовсе.
Чтобы управлять какой-либо областью внимания (мы называем ее аспектом), используются два вида инструментов – артефакты и события.
Артефакты – то, что отображает какой-либо результат (например, отчет о состоянии проекта), а событие – это любой вид встречи (совещания, ретроспективы, проектный комитет) с обсуждением данных из этого артефакта для принятия дальнейших решений, например, в случае отклонений, а в отдельных случаях – процедуры (например, передача ПО на поддержку).
И если на предыдущем шаге мы выяснили, какие области внимания нам важно контролировать для достижения целей каждого типа проектов, то здесь нам нужно проверить, какие инструменты (артефакты и события) уже показали свою эффективность.
Например, в компании хорошо работают ретроспективы (событие), где команда обсуждает и фиксирует, какие проблемы возникали на проекте, как их решали и как их избегать в будущем. И по окончании каждой ретроспективы команда заполняет реестр с описанием выявленных проблем и извлеченных уроков (артефакт) на данном типе проекта, а также планом мероприятий по учету их в работе на новых и идущих проектах.
Как понять, что эта практика хорошо работает? Если ее результат – конкретные внедренные решения, которые помогают избежать допущенных ошибок в будущем, минимизировать риски, например, касаемо неудовлетворенности заказчика или сроков проекта.
А вот другой пример, когда от какой-либо практики нужно отказаться.
Если реестр рисков всегда заполняется формально (риски нарушения сроков, превышения бюджетов и неудовлетворенности заказчиков), а то и вовсе игнорируется, потому что организация еще не дозрела до такого продвинутого уровня, зачем его оставлять?
Да, вести реестр рисков и заранее прорабатывать меры их устранения это полезная и успешная во многих компаниях практика. Но вы должны трезво оценивать уровень зрелости проектного управления в вашей компании, а потому должны остаться только те инструменты и практики, которые компания в состоянии использовать и которые реально будут влиять на успех проектов.
И, конечно, бывает так, что некоторые инструменты работают только в отдельных случаях, далеко не всегда. Тут нужно проанализировать, почему так происходит и что нужно сделать, чтобы повысить эффективность такого инструмента. Пример, который я уже приводил выше – реестр стейкхолдеров будет работать только если применять его в масштабных проектах с большим количеством заинтересованных сторон, в других случаях он будет бесполезен.
Шаг 3. Используем полученный дистиллированный опыт компании для создания правил управления проектами
Проанализировав, что в вашей организации работает хорошо, от чего нужно отказаться, а что можно улучшить (например, внедрив новые практики, но важно их адаптировать), вы получаете дистилированный опыт компании и проверенный набор инструментов, который станет основой для создания единых правил управления проектами. И которые можно смело внедрять, не опасаясь сопротивления, потому что:
каждое правило использования артефакта или события обосновано необходимостью управлять важной для организации областью внимания (аспектом)
нет бесполезной бюрократии, бесцельных или нерелевантных артефактов или событий, которые не покрывают ни один из аспектов или неуместны для конкретного типа проекта. Потому что правила управления применяются гибко, не одинаково ко всем проектам, а только когда они действительно нужны
сотрудникам не надо ничего навязывать, долго обучать их, потому что новые правила управления базируются на уже имеющемся успешном опыте
И, конечно, разработав правила управления проектами по такому методу и внедрив их, вы, как руководитель, сможете наконец минимизировать свои усилия и нагрузку и переключить свое внимание на задачи своего уровня.
Если вам интересен этот метод разработки правил управления, рекомендую посмотреть мой вебинар на эту же тему. Дайте знать в комментариях, если хотите продолжения.
Коллеги, приглашаю вас в свой телеграм канал Андрей Малахов | От проектов к изменениям, где я регулярно провожу методологические экскурсии на примере кейсов моих клиентов.
Кроме этого, в канале вы найдете много полезного для себя: проверенные инструменты, лайфхаки, кейсы, личные наработки за 20+ лет управления проектами и изменениями. А еще я там рассказываю про собственные разработки: мой авторский гибридный метод управления проектами Парацельс ПМ и ИТ-инструмент ресурсного планирования. Подписывайтесь!
