Не стоит недооценивать изменения, Ведь в сущности любой проект запускается для того, чтобы изменить что-то в организации. В этом посте я хочу поделиться методиками подготовки к изменениям, мы обсудим, почему изменения — это маленькая смерть, что такое «Долина слез», а также проследим весь путь принятия человеком изменений. Это очень важно, потому что в конечном счете успех внедрения изменений зависит от того, стали они частью нового формата мышления коллектива или нет.
Когда речь заходит об изменениях, в проектном упрвавлении обычно выделяется два аспекта работы с ними — это внедрение и контроль. С внедрением изменений на первый взгляд все понятно — нужно что-то изменить, и мы работаем над этим. Но для чего нужен контроль?
Контролировать изменения необходимо, когда мы работаем над комплексным и сложным проектом, когда у вас много задач и стейкхолдеров, когда для проекта характерны сложные процедуры согласования и требования, в компании применяются практики управления ресурсами, а любое изменений может значительно повлиять на план реализации проекта.
Представьте, что NASA проектирует космический модуль. Но внезапно один из инженеров предлагает заменить одну деталь на другую, более безопасную. Какими бы благими не были намерения, этого нельзя сделать сразу, ведь на этапе строительства уже готова конструкторская документация, сверстан бюджет. Если начать глубокие изменения, возможно придется сдвигать дату отправки космонавтов, что может повлиять на многие смежные проекты. Но допустимо ли это? И как контролировать вносимые изменения?
Одним из подходов может быть предложенный специалистами PMI (Project Management Institute). Книги института содержат практики и знания, накопленные большим количеством профессионалов, и если вам нужно контролировать изменения, их можно использовать как прямое руководство.
PMBOK (так называется свод знаний PMI) предлагает готовый набор лучших практик по внесению и контролю изменений в организации. Одной из них является создание совета по изменениям (Change Control Board), который представляет собой группу лиц с достаточными для принятия решений полномочиями.
Совет для принятия решения может заказывать экспертные оценки и обсуждения. После работы совета на выходе создается журнал предлагаемых изменений, перечень одобренных запросов, ну и конечно обновляется проектная документация и общий план управления проектом.
С контролем изменений я часто сталкиваюсь и в Acronis, потому что это привычный процесс для зрелой компании с большим объемом разработки. Например, для каждого релиза формируется scope, который включает все планируемые фичи. Когда scope утвержден, ничего не может быть добавлено в проект – ведь после просчета всех рисков и трудозатрат мы публикуем дату релиза.
Но мир непредсказуем, и запрос на важные для бизнеса изменения может поступить в любой момент. В этом случае неискушенный менеджер может пойти по одному из следующих сценариев:
- Занять жесткую позицию и стать «человеком по имени “нет”», отказываясь вносить изменения в утвержденный план. В короткой перспективе это может сработать, но на месте руководителя, стали бы вы долго терпеть такого упрямого и категоричного сотрудника?
- Принимать большую часть привнесенных изменений, заметно рискуя потерять контроль над проектом, его ресурсами и сроками. Не всегда эффективный подход.
Практика показывает, что лучший подход в таком случае может быть охарактеризован фразой «it depends»: по каждому конкретному случаю давать руководству принимать решения, предварительно проведя оценку последствий изменения с привлечением экспертов. Ведь подавляющее большинство изменений возможно, просто каждое потребует определенных “жертв”: например, новые функции можно добавить, если что-то выкинуть из релиза, сдвинуть даты сдачи или нанять аутсорсеров (соглашаясь на рост затрат).
А если финальное решение вносить изменения принято, то хорошей страховкой для менеджера будет официальный документ, подписанный всеми сторонами. Чтобы через несколько месяцев, когда многое забудется и руководитель придет с вопросом: «А почему мы сдвигаем сроки?» было чем обосновать свою позицию.
Безусловно, на маленьких проектах и в совсем небольших компаниях весь вышеописанный процесс может проходить незаметно, но чем крупнее проект и чем выше зрелость компании, тем формализованнее должны быть процессы внедрения изменений
Внедрение изменений
Но если контроль изменений присущ в основном крупным компаниям и проектам, то внедрение изменений — это процесс, с которым приходится сталкиваться даже стартапам.
Я уверен, что если раздать всем сотрудникам компании небольшую анкету с одним единственным вопросом “Хотели бы вы, чтобы ваша компания работала более эффективно”, то подавляющее большинство ответило бы “Да”. Но при этом изменения в работе компании всегда связаны с определенными трудностями: инстинктивно большинство сотрудников противятся изменениям, ведь изменения это когда «кто-то другой просит нас делать что-то новое».
Степень инерции в любом коллективе велика. И если вы никогда не внедряли новый процесс работы в коллективе, то, скорее всего, недооцениваете эту силу.
Руководители и менеджеры часто лучше чем персонал видят возможности, понимают стратегии и риски. И именно перед менеджерами стоит очень важная задача — объяснить всем, почему изменения необходимы.
Одну из моделей для понимания мотивов человека описал психолог Курт Левин, работавший в MIT в 40-х годах. Его модель «Поле силы изменений» предполагает, что на каждую личность (или организацию) действуют совокупность противоборствующих сил: побуждающие и ограничивающие. Именно от баланса этих сил и зависит текущее состояние.
Если чуть глубже посмотреть на эту модель, то можно сделать вывод, что залогом успешного внедрения изменений является работа с людьми, их мотивами и внутренними ограничениями. Например, новая побуждающая сила в виде мотивированного руководителя может сдвинуть организацию из застоя, но через какое-то время она ослабнет или столкнется с сопротивлением, устанавливая новый статус кво.
Изменения — как смерть
Это сравнение не случайно, ведь если верить подходу Элизабет Кюблер-Росс, на любые значительные изменения, будь то личная трагедия или просто изменения в организационной структуре департамента, человек реагирует схоже. Элизабет в процессе работы с пациентами, которые болели неизлечимыми заболеваниями, выделила следующие этапы принятия изменений:
- Шок — Именно это испытывают люди, когда слышат фразу “У нас реструктуризация, и сейчас вас объединят с другим департаментом”. В зависимости от конкретного человека шок будет протекать по-разному, но практически все будут переживать из-за нарушения статуса-кво, испытывая разные негативные эмоции — от волнения до испуга
- Отрицание — Люди задаются вопросом: “А зачем это? Они ничего не продумали! Это плохая идея!” Что характерно, в этом периоде люди мало и плохо работают, потому что их энергия направлена на то, чтобы избежать изменений, на поиск контр-аргументов
- Разочарование — Люди тратят свое время на попытки убедить себя и окружающих в том, что нужно все вернуть как было, что стало хуже. И, что характерно, продолжают неэффективно работать
- Депрессия — Этот период можно считать переломным, потому что человек понимает неизбежность изменений, но еще не понимает, как вести себя в новой ситуации
- Эксперимент — Происходит попытка отказа от старых моделей поведения, но новых все еще нет. В этот момент важно ускорить процесс, стимулировать сотрудников искать подходы к решению новых задач, приспосабливаться к новым реалиям. На этом этапе также существует риск застрять в «Долине слез». Этот термин описывает ситуацию, когда после неудачных попыток примерить новые правила, мы скатываемся к предыдущему этапу к депрессии. И этот цикл повторяется, пока не будет найден новый подход и методы работы
- Решение — Новые модели поведения найдены, происходит их наработка, формирование лучших практик. На этом этапе люди все меньше ошибаются, создаются новые паттерны, компания приближается к обновленному статусу Кво
- Интеграция — Если мы говорим о внедрении изменений в компании, то после всего этого требуется встраивание изменений в корпоративную культуру
Все эти стадии условно можно разделить на три более крупные категории:
- Размораживание – Разочарование в текущих установках
- Движение – Поиск новых подходов
- Заморозка – Фиксация работающих практик
Но о том, как менеджер проектов может должен вести себя на каждом из этапов, как добиться максимального приятия, с какими сотрудниками работать и как ускорять внедрение изменений, я расскажу в следующем посте. Также мы познакомимся с моделями внедрения изменений и методикой оценки вероятности успеха внедряемых изменений. Так что не забывайте подписаться на наш блог, если вы этого еще не сделали. А я буду очень рад, если вы расскажете в комментариях об опыте внедрения изменений в вашей компании.
wmgeek
Наивысшим приоритетом для нас является удовлетворение потребностей заказчика. Изменение требований приветствуется, даже на поздних стадиях разработки. Управление изменениями это не столько об отклонениях от первоначального плана, сколько о взаимодействии и сотрудничестве.
VolCh
Мне показалось, что тут больше об изменениях в организации — структура, процессы и т. п. Нет? Или "что у кого болит..."
voskanov Автор
Да, верно. Но тут и тема требований тоже по касательной затронута.
Управление изменениями требований в классических проектах – это отдельный процесс, который позволяет проекту развиваться предсказуемо. Удовлетворение заказчика даже на поздних этапах и приветствие изменений, конечно, часто является базовой ценностью, но это ближе уже к гибким подходам и Agile Manifesto. Тут еще важно помнить про управление ожиданиями.
Но большая часть статьи конечно про организационные, процессные и иные изменения в компании.