Нулевой этап проекта. Как подготовить команду к изменениям, не завалить проект, не потерять людей

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

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

Немного о нас. Мы – проектный офис компании Инфостарт.

Занимаемся проектами любой сложности и масштаба, в любой точке России, а скоро и за ее пределы тоже выйдем.

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

Во многих компаниях есть чек-лист подготовки проекта. Он у всех разный. У нас он включает:

• карту стейкхолдеров;

• матрицу ролей и решений;

• карту изменений;

• коммуникационный план;

• план обучения и поддержки;

• план загрузки;

• и метрики эффективности, по которым мы потом сможем понять – как вообще это работает или не работает, прижилось или не прижилось.

Все это мы готовим до старта проекта – независимо от выбранной методики запуска.

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

Как обычно начинается проект?

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

• пользователи вообще не в курсе, что их работа изменится – им об этом просто не сообщили или информировали по факту, директивно;

• команда пользователей вовлечена в проект по остаточному принципу: после основной работы, вечером, «если будет время»;

• в итоге согласования затягиваются;

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

Проект начинает буксовать, потому что любой проект – это изменения. А люди их не любят.

Пользователи сопротивляются, но не из вредности, а потому что выбирают понятное и безопасное. А изменения – это всегда неопределенность и риск.

Обычно на проекте выделяется три уровня изменений: инструменты, процессы и управление:

• При изменении инструментов – когда меняются формы, сервисы и отчеты – мы можем снять страх через обучение.

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

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

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

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

Почему возникает сопротивление? Люди боятся потерять свое профессиональное «я». Они понимают, за какой результат им сейчас платят, и боятся – что не смогут справиться с новой нагрузкой или вписаться в новую реальность после внедрения.

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

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

Ответы были разными – от «уволить» и «запугать» до «подкупить» и «объяснить». И тут важно: нет «правильных» или «неправильных» вариантов – все зависит от конкретной ситуации и подхода каждого.

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

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

Кейс: пример успешного успеха

Методика, о которой я расскажу, перекликается с подходом Jobs To Be Done, точнее с направлением Jobs as Activities и рекомендациями о том, как его запустить в компании.

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

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

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

Разберем, как это реализуется на практике.

Итак, кейс.

• Клиент – производственное предприятие, специализируется на ремонтно-эксплуатационных работах (названий не будет, потому что проект под NDA).

• Компания работает по всему миру: обслуживает и поддерживает различные объекты.

• Из-за географии возникают сложности с финансовыми потоками – особенно с поступлением денег из-за рубежа.

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

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

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

• Были попытки описать и оцифровать процессы, автоматизировать их, чтобы снизить зависимость от людей. Этим пытались заниматься и внутренняя ИТ-команда, и внешние интеграторы – даже разработали для них блок финучета в КА с нуля. Но Excel при этом никуда не делся, и даже разросся. У пользователей возник конфликт с ИТ и интеграторами, и они вернулись к привычным инструментам.

• Итог – разочарование и полное недоверие к любым внедрениям.

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

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

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

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

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

Расскажу, как проходили эти два дня по шагам:

• Сначала мы разобрали текущее состояние: что работает, что нет, чего не хватает. Мы не ограничивались вопросами систем и учета, а обсуждали в принципе все проблемы подразделения – плохие кондиционеры, неудобные стулья, шумную и медленную кофемашину, потери времени на работу с бумажными отчетами. Через это мы постепенно выходили на более глубокие вопросы – например, обсуждение проблем с «бумажками» привело к идее BI-дашбордов.

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

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

• Дальше – приоритизация (через голосование по матрице Эйзенхауэра).

• И финальный этап – спринт 20-20-20: короткие презентации идей внутри команд (20 минут на подготовку, 20 минут на создание слайдов и 20 минут на презентацию идей).

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

• карта процессов и их пересечений;

• список проблем и ограничений;

• список требуемых улучшений;

• приоритизированный бэклог;

• дорожная карта изменений, где прописаны первые шаги, которые мы делаем;

• и распределение ролей – кто чем будет заниматься.

Результат:

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

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

• Спонсирование было заранее согласовано.

• Мы выдали быстрый результат – в первые дни и недели. Это очень важно, иначе доверие и энергия просто сгорят, и пользователям проект будет неинтересен. Об этом мы, естественно, договорились с директором заранее – например, чтобы согласование спонсирования можно было подтянуть к результатам. Возможно, это фикция и театр, но люди в этот театр вовлекаются, и дальше прекрасно играют очень важные для проекта роли.

Главное – мы достигли исходной цели спонсора.

• Он получил прозрачный финансовый контур.

• Он получил снижение зависимости относительно экспертизы носителей знаний.

• Более того, он был готов пойти дальше – к разработке собственного продукта. Просто потому, что на рынке не существует подходящего готового решения, его в любом случае нужно создавать с нуля. И команда реально загорелась этой идеей: не просто дорабатывать очередную систему, а создавать полноценный продукт. Это воспринималось как что-то уникальное и значимое, потому что идея родилась у них самих. Мы лишь направляли, но по факту они действительно это сделали сами.

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

Такой подход дает нам следующие преимущества:

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

• Работа с людьми – это самая сложная часть проекта. Но когда пользователи становятся вовлеченными и адекватно настроенными, взаимодействие становится гораздо проще.

• Когда уровень конфликтов снижается, люди не выгорают и не уходят посреди проекта – ни со стороны клиента, ни со стороны команды.

• Люди становятся готовы к изменениям.

• Атмосфера меняется: появляется ощущение совместной работы. Проект перестает быть противостоянием «заказчик – исполнитель» и становится общим делом, где все движутся к одному результату. Такой формат общения значительно эффективнее для работы.

Чтобы проект не сорвался — начните с людей

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

Подробнее

Вопросы и ответы

В той компании что-нибудь живет до сих пор вне системы, в Excel?

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

На момент запуска часть Excel-файлов еще оставалась, но они использовались как временный вариант для обмена данными.

Когда вы говорили про сопротивление, вы лишь вскользь упомянули такое слово как саботаж. Но сопротивление и саботаж – это две разные сущности, и в каждом проекте есть люди, которые по каким-то причинам проект саботируют. Как работать именно с саботажем?

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

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

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

Можно ли проводить такие стратегические сессии онлайн?

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

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

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TEAM EVENT.