И помимо отдельного прицельного фокуса на бизнес-кейсе в РМВоК ввели понятие нового документа – «ПЛАН УПРАВЛЕНИЯ ВЫГОДАМИ ПРОЕКТА».
Аргументация необходимости этого документа в том, что после завершения проекта возникают ситуации, когда полученные результаты не используются или используются не так, как задумано. Соответственно компания не имеет выгод, ради достижения которых запустили и реализовали проект. При этом высшее руководство не знает об этом, т.к. после завершения проекта бывает о истинном назначении результатов все забывают, в том числе и Спонсор, и Заказчик. А бывает забывают (или видоизменяют) специально…
Как с этим явлением борются из того, что я встречал на практике. Здесь мне нравится метод и подход некоторых системных консалтинговых компаний в Москве (правда в основном их просят клиенты-заказчики уровня набсоветов или акционеры – от них «ноги растут»). Они предлагают в качестве услуги не только дизайн проекта, а и периодические аудиты внедрения и использования результатов проекта (Внедрили ли то, что согласовали или по ходу внедрения «нагенерировали отсебятину»? Используются\функционируют ли результаты проекта как предписано проектом?).
Я сам участвовал в нескольких таких пост-проектных аудитах: в одной компании внедрили электронный документооборот – а по факту функционировал параллельно бумажный; в другой должны были передать на аутсорсинг ночные развозки операторов Call Center автобусами по домам – оказалось никто даже не провел эту работу; в третьей – должны были отстроить сегментно-ориентированную структуру, а по факту получился «компромиссный гибрид», созданный под отдельных людей…
PBMоK же рекомендует для решения проблемы использования результатов проекта «по назначению и как предписано проектом» создавать «План управления выгодами проекта».
На момент написания книги сам я ни разу не видел такого документа для отдельного проекта – встречал только нечто похожее для программ. Но собираюсь попробовать: как и что из этого получится напишу возможно в виде отдельной статьи в социальных сетях (возможно дополню и книгу).
Это документ, который:
· устанавливает связь между проектом с программой и портфелем, в которые он входит;
· связь между проектом и целями организации;
· определяет ответственного за получение выгод и сроки достижения выгод, которые могут выйти далеко за границы проекта.
Ключевое для меня в этом документе – это его фокус на том факте, что после завершения проекта полученные результаты не используются или используются не так, как задумано. Проблема ли это проектного менеджера? Отнюдь нет. Но это большая проблема для организации или любой другой социально-экономической системы, для преобразования которой запускался проект.
А для консультантов наличие такого документа может стать подспорьем для: (а) проведения пост-проектных аудитов; (б) четкого ответа на вопрос-претензию заказчика «Ну мы же сделали проект с Вами – почему не работает?»
Заинтересованные стороны
Заинтересованные стороны – это широкий круг лиц, которые заинтересованы в проекте или кого проект просто затрагивает: от команды проекта с подрядчиками – и до сотрудников/менеджеров тех предприятий или подразделений, кого напрямую коснутся результаты проекта или которые выделяют ресурсы (особенно подчинённых) для реализации проекта (рис.1.11).
Рис.1.11. Заинтересованные стороны
В трансформационных проектах важно выделять членов высшего руководства компании (ТОР-менеджмент) – особенно тех, кого изменения могут коснуться так, что после преобразования они потеряют власть, разделят с кем-то полномочия, уменьшатся их ресурсы, бюджеты и т. д.
А если Вы работаете внутри компании и успели нажить пусть даже условно влиятельных недоброжелателей, врагов или просто есть люди, которым Вы лично не нравитесь – их всех в список.
Особенно часто внутри организации встречается конфликт на уровне руководитель корпоративного РМО (офиса по управлению проектами) и менеджер проекта из какой-то функции, который ему по ряду причин не нравится.
В недоброжелатели, как бы банально не выглядело, могут попадать даже HR-менеджеры и HR-директора, руководствующиеся «своими критериями лучшести» проектного менеджера: должны быть глазки горящие, харизма-шмаризма, хороший спикер и прочие занимательные вещи (и часто критерии «под одну гребенку» под все проекты, причем что для управляющего операционной деятельностью «линейщика», что для менеджеров специфических проектов). Они не всегда поддерживают те или иные назначения, а поскольку решения о назначениях принимают не они – то это иногда становится чреватым для менеджера проекта.
В одной крупной промышленной компании на трансформационном комитете обсуждали статус ТОР-10 трансформационных проектов.
Был проект, который дважды переносили, трех менеджеров сменили – а он никак не двигался. Спросили есть ли вообще по моему мнению кто-то внутри компании, кто мог бы его сделать? Зная компанию, я назвал одно ФИО.
И тут вскочила директор по персоналу с репликой «Он не может быть менеджером проектом». На вопрос «Почему?» Ответ: «Харизмы ему не хватает, говорит все время сложно – как он выступать будет?».
Но невзирая на ее реплику, СЕО с операционным директором прислушались к ФИО – и назначили этого человека. Под его руководством проект таки был успешно реализован. Правда, как мне потом рассказывали, HRD настолько «прониклась проектом», как будто она лично за него отвечала. В т.ч. принудила одного из своих HR-менеджеров быть в курсе «что творится на этом проекте и как он там управляет». А на каждом комитете пыталась придраться к любым мелочам. Правда длилось это недолго: когда на очередном комитете она придралась к очевидно выдающемуся прогрессу и результату с формулировкой «не, ну вы посмотрите: выполнение задачи на целых 2 дня задержали…», операционный директор и СЕО не выдержали и сказали ей сфокусироваться на вакансиях и оформлении бумаги «и вот там и считай сроки закрытия вакансий и оформления отпусков в днях».
Возвращаясь к заинтересованным сторонам. Самый классический способ их анализа – матрица власти и интереса (или любые ее вариации) – рис.1.12. Оценки в этой матрице базируются на Ваших собственных суждениях.
Рис.1.12. Матрица власти и интереса
Если в квадрате «Высокая Власть – Низкий интерес» очень много влиятельного народа (а еще не дай бог спонсор и заказчик, которым проект был навязан сверху) – не подписывайтесь под таким проектом, всячески «спрыгивайте» с него. Одно дело нивелировать влияние одних людей контрвлиянием других (если необходимо – то даже «сталкивая лбами» тех, кто поддерживают проект, и его противников), совсем другое дело самому бороться с сопротивлением всей «машины власти». На таких проектах не заработаешь, даже если обещают заплатить много – в итоге заработанные деньги не компенсируют затраченные усилия и нервы.
Получив эту матрицу, уже можно думать, как и с кем будете отстраивать коммуникации в проекте и нивелировать влияние недоброжелателей.
И я думаю все понимают, что вот этот свой анализ ни в коем случае внутри организации лучше никому не показывать. Иначе будет «миной замедленного действия» для проекта. На сторонников это никак не повлияет, а вот противники будут еще больше разъярены и многие «уйдут в подполье», заверив всех, что они на самом деле поддерживают проект. Но при малейшей возможности будут с огромным рвением создавать Вам лично, проекту или проектной команде проблемы.