Никита Сергеев - Трансформация - особенности управления проектами преобразований. МВА-библиотека

Почему-то внутри компаний принято на все крупные инвестиционные проекты (даже простые по своей природе, например, когда 99% огромного бюджета составляют материалы и стандартное оборудование) готовить и рьяно обсуждать бизнес-кейсы. А на порядок сложнее проекты, но не выражающиеся прямо в денежных величинах – никто «не заморачивается»…

В части именно трансформационных проектов (проектов преобразований) бизнес-кейс освещает проблематику и причины, по которым запускается проект. И в них часто речь не просто о некой сумме денег – речь о более фундаментальных вещах, связанных с эффективностью организации и бизнеса.

Именно в бизнес-кейсе содержатся бизнес-потребности и выгоды от проекта, прослеживается его окружение и следуемые из него ограничения. Ведь бизнес-кейс – это то, что создается или под требования рынка (клиенты, конкуренты), или организации, или технологический прогресс, или требования госрегулятора…

Несомненно, для инициации проекта бизнес-кейс, конечно, штука незаменимая, а вроде как для управления проектом уже и не нужна….

С коллегами по цеху (консультантами) мы иногда горячо дискутируем о необходимости этого документа для управления проектом. Основная масса коллег воздерживается от комментариев, а некоторые говорят, что он не нужен, ибо это проблема заказчика: «Он же заказывает, значит у него бизнес-кейс сходится, он проект утвердил. А нам только сделать надо». Да и во многих компаниях бизнес-кейсы (особенно на проекты преобразований) не готовятся в принципе.

Но с моей точки зрения для консультанта погружение в бизнес-кейс по потенциальному проекту часто имеет кроме упрощения управления проектом еще и очень прикладную (читай денежную ) выгоду.

В одном проекте я сам когда-то нарисовал бизнес-кейс для компании, чтобы продать необходимость интересного мне проекта. Меня же провайдером выбрали. Сам же потом проектом управлял.

Однозначно, конечно, делать бизнес-кейс точно не обязанность менеджера проекта. Менеджер проекта – это тот, кто «исполняет» пожелание заказчика. Но считаю, что его надо иметь. Если у заказчика бизнес-кейса нет (такое очень часто бывает) – то менеджеру проекта стоит сделать хотя бы наброски бизнес-кейса что называется «на пальцах» для себя и проектной команды на основании беседы с заказчиком и спонсором проекта.

Последняя версия РМВоК в сравнении с предыдущими намного больше внимания уделила бизнес-вопросам проектного управления (предыдущие более технически и процессно-ориентированы).

И помимо отдельного прицельного фокуса на бизнес-кейсе в РМВоК ввели понятие нового документа – « ПЛАН УПРАВЛЕНИЯ ВЫГОДАМИ ПРОЕКТА».

Аргументация необходимости этого документа в том, что после завершения проекта возникают ситуации, когда полученные результаты не используются или используются не так, как задумано. Соответственно компания не имеет выгод, ради достижения которых запустили и реализовали проект. При этом высшее руководство не знает об этом, т.к. после завершения проекта бывает о истинном назначении результатов все забывают, в том числе и Спонсор, и Заказчик. А бывает забывают (или видоизменяют) специально…

Как с этим явлением борются из того, что я встречал на практике. Здесь мне нравится метод и подход некоторых системных консалтинговых компаний в Москве (правда в основном их просят клиенты-заказчики уровня набсоветов или акционеры – от них «ноги растут»). Они предлагают в качестве услуги не только дизайн проекта, а и периодические аудиты внедрения и использования результатов проекта (Внедрили ли то, что согласовали или по ходу внедрения «нагенерировали отсебятину»? Используются\функционируют ли результаты проекта как предписано проектом?).

Я сам участвовал в нескольких таких пост-проектных аудитах: в одной компании внедрили электронный документооборот – а по факту функционировал параллельно бумажный; в другой должны были передать на аутсорсинг ночные развозки операторов Call Center автобусами по домам – оказалось никто даже не провел эту работу; в третьей – должны были отстроить сегментно-ориентированную структуру, а по факту получился «компромиссный гибрид», созданный под отдельных людей…

PBMоK же рекомендует для решения проблемы использования результатов проекта «по назначению и как предписано проектом» создавать « План управления выгодами проекта».