Expectations management или управление ожиданиями – любимая тема любого проектного менеджера, так как от эффективности этого процесса зависит чуть ли не столько же, сколько и от эффективности коммуникации или управления рисками (и все это очень сильно между собой пересекается). Итак, что такое управление ожиданиями?
Управление ожиданиями – это приведение картины мира пользователей, заказчика, спонсора проекта и других заинтересованных лиц в максимально возможное соответствие реальности, чтобы столкновение с ней было настолько безболезненным, насколько это возможно.
Достигнуть этого можно только одним способом: коммуницируя и еще раз коммуницируя ожидаемые результаты, всячески их визуализируя и постоянно напоминая о цели проекта.
Как управлять ожиданиями пользователей
Очень просто, нужно только:
- Напоминать о цели проекта. Очень легко уйти в сторону и, начав делать систему по управлению контрактами, закончить чуть ли не разработкой локального SAP. При этом в результате все останутся все равно недовольны, потому что ваша система управления контрактами без вариантов будет хуже SAP. Если удерживать фокус на том, что мы, вообще-то, делаем систему только для контрактов, а не для финансов, вероятность позитивного отношения к ней будет выше. И за каждую «финансовую» фишку вам будут благодарны. Как всегда, весь секрет – в угле зрения.
- Говорить о том, чего мы НЕ делаем, а не только о том, что делаем. Если ограничения проекта написаны в вашем уставе – это отлично, это уже больше, чем делает 75% руководителей проектов. Но если эти ограничения еще и регулярно проговаривать, то толку от них будет еще больше. От того, что вы в конце проекта будете декларировать недовольным пользователям «вот устав и тут написано, что проблемы с производительною не в нашей области ответственности, ваши претензии беспочвенны», вы в их глазах лучше не станете, скорее, наоборот, будете выглядеть эдаким бюрократическим негодяем, ловко скинувшим с себя работу. Лучше проговаривать это при первом же показе – «Обратите внимание, что система работает не очень быстро и также будет и в продуктивном окружении. У нас нет технической возможности решить эту проблему, она не входит в содержание проекта. Но вам будет некомфортно работать, поэтому, пожалуйста, подумайте о назначении ответственного за ее решение в отделе инфраструктуры». И все, вы зайка и вообще хороший и заботливый человек.
- Озвучивать ожидаемые проблемы или сложности (=риски), особенно если они на стороне Заказчика и должны решаться им. Показывая очередные результаты работ, уместно будет «случайно» напомнить – «Система работает так-то, но из нашего опыта на других проектах такого класса – у всех возникают проблемы со скоростью работы в первое время, так как люди на производстве не привыкли к использованию ПК, особенно старшего возраста. Все решают это по-разному – кто-то проводит для сотрудников курсы компьютерной грамотности в целом, кто-то читает тренинги по использованию системы. Кстати, если нужно, мы готовы оказать помощь в подготовке тренинговых материалов, чтобы система начала приносить пользу с первого дня, а не тормозила бизнес-процессы. Тогда проблема не будет неожиданностью, в которой виноват РМ (даже если он не виноват), а вполне ожидаемой рутиной. А вы будете выглядеть мудрым и опытным профессионалом.
- Немного снижать градус восторга, если Заказчик очень ждет результатов проекта и рассчитывает на некие фантастические результаты. Автоматизация, конечно, наше все, в том числе хлеб с маслом и икрой (икрой – у хороших РМов, а черной икрой – у очень хороших), она приносит реальную выгоду, но Заказчик, не получивший этих фантастических результатов в первые же дни, будет обманут в своих лучших ожиданиях и запишет проект в зря потраченные деньги, а вас – в неудачники. Умение грамотно подвести к тому, что результаты, конечно, будут, но не сразу и вообще, без терний звезд не бывает, – очень ценное качество для любого руководителя проекта. Аналогично – нужно снижать градус негатива, если результат проекта все заранее ненавидят, но это, как ни странно, часто проще.
Чего нужно избегать в проекте с точки зрения управления ожиданиями
Чтобы не столкнуться с завышенными ожиданиями и с разочарованием потом, лучше избегать:
- Общих сравнений, без детализации («Система будет как Angry Birds» – вы имели ввиду, с одной кнопкой, а заказчику уже видел в мечтаю интерфейс с любимыми птичками и теперь расстроен, и даже одна кнопка его не радует. Лучше будет «Система будет как Angry Birds с точки зрения простоты управления – там будет только одна кнопка и текст, и больше ничего).
- Очень точных оценок («Нам потребуется 2 млн.долларов, точно не больше» – и вот вы потратили 2 100 000 долларов, сделали проект раньше, вывели его на рынок – а все недовольны, так как держатель бюджета кровью подписался, что двух миллионов ему хватит и теперь бледно выглядит перед своим руководителем. Лучше было бы «по оптимистичной оценке мы уложился в 1,8 млн, по реалистичной – в 2 млн, но я бы закладывал 2,1 млн на случай непредвиденных обстоятельств и изменений, если это 100 тыс. не понадобятся – мы либо вернем их в бюджет (если применимо) либо закажем дополнительный цикл тестирования, чтобы свести вероятность ошибок к минимуму»). Кстати, это «болезнь» многих начинающих РМов – они панически боятся ошибиться в расчетах, называют цифры очень уверенно (и всегда очень конкретные, без оптимистичных и пессимистичных оценок). И потом очень расстраиваются.
- Долгих «пробелов» в коммуникации – доносить информацию нужно ненавязчиво, но постоянно, в лучших традициях советской пропаганды. То, что в начале проекта вы один раз всем рассказали, что будет на выходе, совсем не значит, что все это запомнили. В ходе проекта управление ожиданиями происходит системно и постоянно, только тогда от него есть толк.
Управление ожиданиями, конечно, не панацея, если все остальное в проекте плохо (в лучшем случае все расстроятся чуть меньше, чем могли бы), но без него все усилиях могут пойти прахом и хороший, даже отличный результат, полностью соответствующий всем договоренностям, может оставить Заказчика разочарованным и не оценившим вашего профессионализма. А нам этого не надо!
Добавить комментарий