Бунт на корабле или почему команда саботирует изменения
Всем привет! Сегодня про групповой саботаж. История начинается так: собственник или руководитель отдела понимает, что процессы буксуют, и решает навести порядок, например, внедрить CRM. Назначает инициатора. Тот горит идеей, находит подрядчика, запускает проект.
А дальше начинается «тихая оборона».
Участники проекта на каждом созвоне или тянут кота (ну вы поняли), или выдвигают все новые условия, которых не было в начале - это мое любимое :). Подрядчик получает разрозненные данные и бесконечные правки. Инициатор выгорает на внутренних согласованиях. А собственник через три месяца спрашивает: «почему проект стоит на месте?»
Почему люди так себя ведут? Причины почти всегда одни и те же:
- Страх, что автоматизация вскроет реальные показатели. Вдруг выяснится, что план выполняется не на 90%, а на 40% — просто раньше это было не видно за хаосом в Excel. - Нежелание менять привычные процессы. Человек десять лет работал по-своему, чувствовал себя незаменимым — а тут приходят какие-то люди и говорят, что всё можно иначе. - Угроза статусу. Если процесс станет прозрачным, исчезнет монополия на информацию. А вместе с ней и влияние внутри компании.
Как с этим бороться
- Прямой доступ к ЛПР. Если на проекте нет регулярного выхода на собственника или CEO — жди беды. Все промежуточные «фильтры» рано или поздно начнут искажать картину. - Фиксация договорённостей. После каждой встречи — запись встречи и письменный протокол с конкретными сроками и ответственными. «Я этого не говорил» и «мы это не обсуждали» перестают работать. - Пилот на малом объёме. Не нужно автоматизировать всё сразу. Возьмите один участок, покажите результат за две недели — цифры сложнее оспорить, чем обещания. - Открытая демонстрация прогресса. Каждые две недели — общая встреча с результатами. Когда прогресс виден всем, саботажнику сложнее играть в «у них ничего не получается».
Саботаж — это не всегда злой умысел. Часто это просто страх перемен и потерять свою значимость. А вы часто сталкиваетесь с саботажем?
· 26.07
Елена, отличный пост!
А что, если мы посмотрим с позиции управления? Мы увидим скрытые ловушки в методах борьбы?
Давайте обратим внимание на следующие связки:
Инициатор бегает к ЛПР за помощью - следствие фиктивного делегирования. Руководителю проекта дали ответственность, но не дали реальной власти.
Успешный пилот за две недели усилит сопротивление - следствие страха разоблачения. Для сотрудников это будет подтверждением худших опасений и они начнут саботировать еще изощреннее.
Протоколы превращаются в бюрократическую войну - следствие попытки лечить страх давлением. Жесткий контроль против страха перемен не работает, а лишь загоняет сопротивление в подполье.
Я думаю нужно посмотреть не в сторону лечения симптомов саботажа, а в сторону архитектуры управления проектом.
Как Вы думаете?
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 29.07
Спасибо! Хорошее замечание. Я во многом согласна: если в проекте изначально неправильно распределены полномочия и ответственность, то никакие протоколы или пилоты сами по себе проблему не решат. Я скорее описывала инструменты, которые помогают, когда сопротивление уже возникло. Если у руководителя проекта нет реальных полномочий, а первое лицо не поддерживает изменения, то никакие протоколы не спасут.
Но и полностью отказываться от пилотов и фиксации договорённостей я бы не стала - сами по себе они не создают сопротивление, а делают его заметным. А когда причина становится видна, с ней уже можно работать.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён
· 29.07
Елена! Пожалуйста, отнеситесь к моим словам не как к оценке ваших действий, а как к совместному поиску оптимального решения или рассуждению.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён