Запустили, но не начали использовать: как считать успех портфеля изменений
Запуск и результат в портфеле изменений
В конце прошлого года наш проектный офис выпустил путеводитель по рискам. Мы разобрали риски, которые реализовались в проектах за пять лет, нашли десять ситуаций, повторявшихся снова и снова, и написали готовые рекомендации, как не наступать на те же грабли. Документ разослали командам, и по нашим тогдашним меркам работа была сделана.
Потом на встрече нашего проектного сообщества мы провели короткий опрос. О существовании путеводителя знали от пяти до семи процентов присутствующих. Я уже разбирал эту историю как ошибку в работе с уроками проектов, и один из выводов там был про точку финиша. Мы считали работу законченной в тот момент, когда документ готов.
Сегодня я сказал бы резче. Представьте отчёт по инициативам проектного офиса: путеводитель стоял бы в нём зелёной строкой “выпущен”. В этой строке нет ни слова неправды и ни слова о том, что о документе почти никто не знает.
В масштабе одного документа это досадная история. Хуже, когда так же устроен учёт целого портфеля изменений, а у крупных компаний он большой. Высшая школа бизнеса НИУ ВШЭ и компания “5встреч” исследовали, как проводят изменения крупнейшие российские компании. В трети из них за год запускают сотни проектов изменений, а в 5% счёт идёт на тысячи.
Речь о проектах, которые меняют процессы, роли или способы работы и требуют от людей работать иначе. Успехом исследователи считали не формально завершённый проект, а изменение, которое произошло на самом деле: систему начали использовать, процесс заработал по-другому, люди перешли к новым способам работы. По медианной оценке участников, до такого результата доходит около половины проектов.
Я подозреваю, что в отчётах тех же компаний картина гораздо благополучнее. Это догадка, но объяснение у неё простое. Портфель изменений меряют запусками, а проваливается он на принятии, то есть там, где люди должны перейти на новое. Система внедрена и работает, отчёт о запуске точен, а запланированного результата нет, и в отчётах этого обычно не видно.
Управлять поэтому нужно принятием: у него должны быть мера, срок и владелец, а успех портфеля изменений надо считать иначе, чем успех проекта. Это прямая работа проектного офиса.
Что происходит после запуска
В день запуска проект сдаёт главный экзамен. Срок, бюджет и объём проверяют именно к этой дате, и после неё команда уходит на следующий проект. Переход людей на новое повисает между закрытым проектом и подразделением, которое получило систему, но часто не получило задачи довести её до результата.
Сколько может длиться этот промежуток, видно на случае из свежей статьи Prosci о цифровой трансформации. Проект цифровизации склада шёл в две фазы. В первой обошлись без управления изменениями, и до полного перехода на новую систему прошло восемь месяцев. Во второй работу с людьми вёл сертифицированный внутренний специалист: сотрудники уверенно пользовались инструментом уже через день после запуска и полностью перешли на него за месяц.
Сравнение не чистое. Вторая фаза шла по следам первой, и часть выигрыша мог дать опыт. К тому же Prosci сама продаёт методологию управления изменениями, и такие кейсы ей выгодно показывать. Но восемь месяцев первой фазы от этого не исчезают. Всё это время система работала, а полностью на неё ещё не перешли.
Почему переход тянется месяцами, понятно любому, кто менял что-то в работающей компании. Её нельзя закрыть на время перемен, как магазин на ремонт. Люди учатся новому, продолжая делать старую работу, и осваивают его между текущими задачами.
По наблюдению Prosci, такой разрыв не исключение: системы работают, а раз за разом ломается то, что люди ими не пользуются, причём ломается тихо и дорого. Компания приводит оценку, по которой ожидаемый результат приносит только треть цифровых трансформаций. Большинство руководителей, по мнению Prosci, судят о трансформации по тому, как быстро её запустили, и следят не за тем. Про систему, которую запустили вовремя и которой пользуются вполсилы, в статье сказано так: “это просто невозвратные затраты с хорошей вечеринкой по случаю запуска”.
Вечеринка в отчёт попадает, а то, что затраты не окупились, не попадает. Поэтому принятие нельзя считать хвостом проекта, который как-нибудь дотянется сам. У него своя длительность, свои риски и свои люди. Пока его ничем не меряют, в отчётах его просто нет.
Что считать принятием и к какому сроку
Начинать стоит с меры, то есть с признака, названного заранее, по которому видно, что люди перешли на новое. Prosci пишет о цифровых трансформациях, но три фактора, которые там называют, годятся для любого изменения: как скоро люди начали работать по-новому, сколько из них действительно пользуются решением и дотягивают ли они до ожидаемого уровня. Ещё Prosci советует начинать с того, чтобы развести показатели исполнения проекта и показатели перехода людей: проект может уложиться в срок и бюджет и всё равно не принести пользы.
Своя мера может быть совсем простой, но у простой меры есть предел. После истории с путеводителем мы добавили метрику: частоту запросов и поиска информации на нашем портале. Она показывает, дошёл ли документ до тех, кому он нужен, или снова осел в папке без движения.
Такая метрика меряет только первую ступень, ведь документ должен дойти до людей раньше, чем они начнут им пользоваться. По ней не видно, работают ли команды с рисками иначе. Для этого нужен признак из самих проектов.
Следом нужен срок. Кроме даты запуска у изменения должна быть вторая дата, к которой люди уже работают по-новому. В графике она появляется, только когда работу с людьми планируют вместе с технической частью. Prosci пишет об этом жёстче: стратегию по технологии и стратегию по людям нужно вести вместе, а компании, которые разводят их по отдельным потокам, раз за разом недополучают результат. Когда работу с людьми встраивают прямо в график проекта, запуск, по словам Prosci, становится вехой, а не датой окончания.
У второй даты должна быть и цена. Prosci предлагает спонсору простую проверку: во что нам обходится месяц задержки полного перехода? Каждый такой месяц компания недополучает отдачу от вложений, которые уже сделаны. Когда у задержки появляется цена в деньгах, вторая дата перестаёт быть формальностью.
Но мера и срок сами по себе ничего не исправляют. Они лишь покажут, что к назначенному дню люди всё ещё работают по-старому. Исправлять отставание сможет только тот, у кого есть власть над подразделениями, где изменение должно прижиться, и время этим заниматься.
Кто отвечает за то, чтобы изменение прижилось
Руководитель проекта владельцем принятия быть не может, потому что его работа заканчивается в день запуска, а людьми в подразделениях он не распоряжается. Владельцем должен быть тот, кто управляет процессом, в котором изменение приживается. Если изменение задевает несколько подразделений, это, как правило, топ-менеджер.
Вывод мой, но с ним согласуется вторая публикация того же исследования. По её данным, значимое изменение, где бы ни возникла идея, как правило, проходит через топ-менеджмент. Именно руководители решают о запуске, определяют приоритет и дальше двигают проект внутри компании.
Сколько изменений топ-менеджер может вести качественно, исследователи спросили напрямую. Чаще всего отвечали: от трёх до пяти в год. Столько же чаще всего и ведут на деле, хотя у 40% участников таких проектов шесть и больше, а почти у каждого пятого больше десяти.
Вывод исследователи делают осторожный: изменений в повестке руководителя может оказаться больше, чем тех, которым он способен уделять полноценное внимание. Отсюда их гипотеза о пропускной способности компании: число топ-менеджеров, умноженное на три-пять, равно числу изменений, которые компания способна провести за год. Нормативом они формулу не считают, и я тоже. Но приложить её к своему портфелю полезно, особенно когда изменений в нём сотни.
Что происходит с изменением, на которое у владельца не хватает внимания? Исследователи описывают это так: “проекты могут формально оставаться в работе, но решения по ним принимаются медленнее, противоречия между участниками не снимаются, а внедрение постепенно теряет приоритет”. Под это описание подходит и запущенное изменение, которое так и не прижилось. Никто его не отменял, и никто его не ведёт.
Если гипотеза исследователей верна, предел портфелю ставит внимание владельцев. Запустить изменение, на которое у владельца нет времени, можно. Рассчитывать на его результат не стоит.
Как считать успех портфеля изменений
У изменения к дню запуска пройдена только половина пути, поэтому портфель изменений я бы считал иначе, чем портфель проектов. Вместо одной строки “запущено” в отчёте комитету стояли бы четыре: застряло, остановлено сознательно, прижилось к сроку и ещё в пути, если вторая дата не наступила.
Строку про сознательную остановку я выделяю из-за ответа одного генерального директора, о котором исследователи рассказали в своём канале. В анкете он оценил долю удачных изменений в 50%. Когда его спросили, что он об этом чувствует, он ответил, что беды здесь не видит. Если посреди проекта поняли, что идут не туда, и отменили его, такой проект вроде бы провальный, а вроде бы и нет, ведь компания что-то поняла и чему-то научилась.
С ним трудно спорить. Но в его половину неудач попадают два совсем разных случая. Когда проект останавливают на полпути, кто-то принимает решение, и у этого решения есть автор и дата. Застрявшее изменение никто не останавливал, его просто запустили, отчитались о запуске, и оно тихо не прижилось. В доле неудач эти случаи выглядят одинаково, хотя для управления они противоположны, поэтому застрявшие я и поставил бы в отчёте первой строкой.
Рядом я положил бы ещё одно сравнение: сколько изменений сейчас в работе и сколько их способны вести владельцы. Если первое число в разы больше второго, застрявшие изменения в портфеле уже есть, даже если отчёт их пока не показывает.
Почему это работа проектного офиса? Через него проходят все контрольные точки портфеля: карточка на входе, решение о запуске, закрытие проекта и отчёт комитету. Мера, срок и владелец встраиваются ровно в эти точки.
С новыми изменениями я начал бы с входа. Я не выносил бы изменение на решение о запуске, пока в карточке нет трёх ответов: по какому показателю мы увидим, что люди перешли на новое, к какой дате это должно случиться и кто за это отвечает. Закрытие проекта я развёл бы с закрытием изменения. Проект может закрыться в день запуска, а изменение остаётся в портфеле до своей второй даты и в этот день проходит разбор.
С изменениями, которые уже запущены, первый шаг другой. Я взял бы десять самых крупных за последний год и по каждому спросил, перешли ли люди на новое и по какому показателю это видно. Думаю, по многим ответа не найдётся.
Первый такой отчёт будет выглядеть хуже привычного. Вместо сплошь зелёных запусков комитет увидит долю прижившихся изменений, и она вполне может оказаться близкой к той половине, которую назвали участники исследования. Портфель после этого, скорее всего, сократится, если сравнение с возможностями владельцев покажет, что часть запусков вести некому. Наш путеводитель по рискам в тот момент стоял бы в таком отчёте в строке застрявших, и мы узнали бы об этом в назначенный день по заранее выбранному показателю, а не из опроса на встрече сообщества. Ради этого отчёт и стоит менять: о том, что изменение не прижилось, лучше узнавать по графику.
