Первый шаг Джона Коттера

Джон Коттер и спасённый пингвинВчера на вебинаре Константин рассказывал, среди прочего, про замечательную модель Джона Коттера. Наверняка о ней все слышали, а многие даже применяют. Мы вот используем её в больших задачах, так что могу ответственно заявить — модель работает.

Напомню кратко те восемь шагов, которые автор, он же Джон Коттер, считает критически важными для любого крупного изменения:

  1. Создание ощущения срочности
  2. Создание коалиции
  3. Разработка видения и стратегии
  4. Коммуницирование видения
  5. Старт преобразований на всех фронтах
  6. Создание быстрых побед
  7. Консолидация и усиление изменений
  8. Закрепление изменений

Особенно мне симпатичен шаг номер один. Мой опыт показывает, что он является чуть ли не самым основным — в том смысле, что его вклад в успех мероприятия сильно выше любого из остальных шагов (хотя и они важны, конечно же).

Так вот, создание ощущения срочности и неизбежности изменения — мощный мотиватор на то самое изменение. На мой взгляд, первый шаг Коттера складывается из четырёх компонент:

  1. Объяснение необходимости изменения. Затрагиваемые сотрудники должны понимать от чего вдруг настала пора меняться, почему именно сейчас и что будет, если изменение не произойдёт. Хорошее подспорье здесь — SWOT-анализ. Даже в простом варианте он даст направления к размышлению о чём, кому и как говорить.
  2. Разрушение текущих комфортных условий и практик. Например: "Теперь мы так работать не можем. Вы не можете. Никто не может". Или: "С этого момента такие-то действия подлежат такому-то согласованию". Или "Мы прекращаем приём запросов на доработку такого-то ПО. Оно выводится из эксплуатации". Данное действие, разрушение, перекликается с первым этапом модели изменений Курта Левина — "Разморозка", а также с первой фазой модели Вильяма Бриджеса — "Завершение и потеря".
  3. Воодушевление на изменение. Изменение — не всегда один сплошной негатив, для кого-то ведь найдутся и положительные стороны. Воодушевление помогает быстрее пройти фазу принятия необходимости изменения персоналом — то есть, конечно, можно никого ни на что и не воодушевлять, только дольше и сложнее получится.
  4. Поощрение коммуницирования срочности в коллективе. Уже на самых ранних этапах, ещё до создания команды (направляющей коалиции, как называет её Коттер) полезно приложить некоторые усилия по информированию затрагиваемых сотрудников. Очень здорово, если такое информирование будет задействовать не один, а несколько каналов.

Джон Коттер советует использовать такой критерий успешности своего первого шага: более 75% руководителей согласны с тем, что текущие практики необходимо менять как можно скорее.

От себя могу добавить, что очень мощно работает следующий простой приём: создание внешнего несдвигаемого крайнего срока. Видел, как его применяют ИТ-руководители; читал, как его применяют предприниматели; часто мы используем этот приём и в своей практике. Обратная сторона медали в этом случае — сильный удар по качеству. Фиксируя срок (одну из связанных метрик) мы неизбежно влияем на качество, стоимость или охват (другие связанные метрики). По моему опыту первым из перечисленной тройки начинает страдать именно качество. Но это заранее известная, хорошо прогнозируемая ситуация, поэтому можно придумать к ней контрмеры.

А вы используете советы Джона Коттера? Помогают?

Dead end, left turn only

NB. И первый, и остальные семь шагов Коттера, и многое другое мы обсуждаем в новом учебном курсе "Организационные изменения". Ближайшие даты — 13 и 14 декабря, затем только в следующем году.

Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInEmail this to someone

ITIL ITIL Intermediate: Release Control and Validation

Учебный курс: преобразование и контроль ИТ-услуг, управление изменениями, релизами и конфигурациями, а также построение CMDB — в ITIL и на практике.
 

Узнайте больше!

Комментарии и мнения

  1. Alexander Peshkov

    Согласен с предыдущим оратором. Но есть и обратная сторона, про которую так вкрадчиво рассказал Олег. К рассказу Олега, кстати есть вопрос — а охват — это не качество? А то мое сознание испытало удивление после столь изящного преображения треугольника компромиссов в соответствующих квадрат. С геометрией спорить очень сложно.

    0
    0
    1. Олег Скрынник Автор

      Зачем квадрат? Пирамида, так веселее. Трёхмернее. Вот, например, слайд из игры «The Challenge of Egypt»: www.realitsm.ru/wp-content/up..._constraints.png

      Предположим сроки, деньги и качество фиксированы, но работу сделать не получается. Чем остаётся жертвовать? Объёмом (он же охват, он же границы, он же scope в оригинале). То есть: «сделаем за эти деньги, в эти сроки, с заданным качеством, но меньше». Это если считать качество самостоятельной характеристикой, а не производной от сроков-денег-охвата.

      А вообще картинок можно придумать много больше, вплоть до звезды Давида: en.wikipedia.org/wiki/Pro...agement_triangle

      0
      0
      1. Alexander Peshkov

        Да, картинки бывают очень разные, иногда даже сильно напоминающие жизнь. Прошу прощения за офтопик, не могу удержаться: cs5220.vkontakte.ru/u3208...4/x_dcd05305.jpg.

        Про пирамиду — интересная мысль, но, как мне кажется, немного натянутая (в части границ или объема), так как объем можно выразить через качество. Или наоборот, как Вам больше нравится. «Наша программа будет работать только в Сомали», или «только для лиц традиционной ориентации», или «будет способна обработать только половину транзакций».

        Пока не могу найти подходящего примера, чтобы нельзя было выразить ЭТО (объем или границы) через качество. «Такой функционал нужен, но не сейчас» — классические границы проекта. «Такой функционал нужен, но не успеваем» — треугольник компромиссов.

        Или мои познания сильно устарели и в этом вопросе тоже появилось четвертое измерение?

        0
        0
        1. Олег Скрынник Автор

          Например, в игре «The Challenge of Egypt» участники должны построить две пирамиды — большую для фараона, маленькую — для его супруги. Для обеих пирамид чётко сформулированы требования по качеству — из каких камней сложены, где должны быть расположены, что с чем соприкасаться может, а что — нет и так далее.

          Иногда группа не успевает построить обе пирамиды и приходит к фараону договариваться об уменьшении объёма работ. При сохранении качества, сроков и бюджета (некоторые группы умудряются выйти за границы и качества, и объёма, и времени, и денег, но сейчас не об этом). Это пример уменьшения scope.

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

          0
          0

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ОКТ
26
Учебный курс:
Основы DevOps
ОКТ
30
Учебный курс:
Основы COBIT 5