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

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

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

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

Это документ, который:

· устанавливает связь между проектом с программой и портфелем, в которые он входит;

· связь между проектом и целями организации;

· определяет ответственного за получение выгод и сроки достижения выгод, которые могут выйти далеко за границы проекта.

Ключевое для меня в этом документе – это его фокус на том факте, что после завершения проекта полученные результаты не используются или используются не так, как задумано. Проблема ли это проектного менеджера? Отнюдь нет. Но это большая проблема для организации или любой другой социально-экономической системы, для преобразования которой запускался проект.

А для консультантов наличие такого документа может стать подспорьем для: (а) проведения пост-проектных аудитов; (б) четкого ответа на вопрос-претензию заказчика «Ну мы же сделали проект с Вами – почему не работает?»

Заинтересованные стороны

Заинтересованные стороны – это широкий круг лиц, которые заинтересованы в проекте или кого проект просто затрагивает: от команды проекта с подрядчиками – и до сотрудников/менеджеров тех предприятий или подразделений, кого напрямую коснутся результаты проекта или которые выделяют ресурсы (особенно подчинённых) для реализации проекта (рис.1.11).

Рис.1.11. Заинтересованные стороны

В трансформационных проектах важно выделять членов высшего руководства компании (ТОР-менеджмент) – особенно тех, кого изменения могут коснуться так, что после преобразования они потеряют власть, разделят с кем-то полномочия, уменьшатся их ресурсы, бюджеты и т. д.

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

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

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

В одной крупной промышленной компании на трансформационном комитете обсуждали статус ТОР-10 трансформационных проектов.

Был проект, который дважды переносили, трех менеджеров сменили – а он никак не двигался. Спросили есть ли вообще по моему мнению кто-то внутри компании, кто мог бы его сделать? Зная компанию, я назвал одно ФИО.

И тут вскочила директор по персоналу с репликой «Он не может быть менеджером проектом». На вопрос «Почему?» Ответ: «Харизмы ему не хватает, говорит все время сложно – как он выступать будет?».

Но невзирая на ее реплику, СЕО с операционным директором прислушались к ФИО – и назначили этого человека. Под его руководством проект таки был успешно реализован. Правда, как мне потом рассказывали, HRD настолько «прониклась проектом», как будто она лично за него отвечала. В т.ч. принудила одного из своих HR-менеджеров быть в курсе «что творится на этом проекте и как он там управляет». А на каждом комитете пыталась придраться к любым мелочам. Правда длилось это недолго: когда на очередном комитете она придралась к очевидно выдающемуся прогрессу и результату с формулировкой «не, ну вы посмотрите: выполнение задачи на целых 2 дня задержали…», операционный директор и СЕО не выдержали и сказали ей сфокусироваться на вакансиях и оформлении бумаги «и вот там и считай сроки закрытия вакансий и оформления отпусков в днях».

Возвращаясь к заинтересованным сторонам. Самый классический способ их анализа – матрица власти и интереса (или любые ее вариации) – рис.1.12. Оценки в этой матрице базируются на Ваших собственных суждениях.

Рис.1.12. Матрица власти и интереса

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

Получив эту матрицу, уже можно думать, как и с кем будете отстраивать коммуникации в проекте и нивелировать влияние недоброжелателей.

И я думаю все понимают, что вот этот свой анализ ни в коем случае внутри организации лучше никому не показывать. Иначе будет «миной замедленного действия» для проекта. На сторонников это никак не повлияет, а вот противники будут еще больше разъярены и многие «уйдут в подполье», заверив всех, что они на самом деле поддерживают проект. Но при малейшей возможности будут с огромным рвением создавать Вам лично, проекту или проектной команде проблемы.

Из всех заинтересованных сторон отдельно выделю сильно влиятельных: Спонсора, Заказчика и Управляющий комитет (или как еще его называют «трансформационный комитет», когда речь о проектах преобразований) – рис.1.13.

Рис.1.13. Наиболее влиятельные стороны в большинстве проектов

· Спонсор – это покровитель проекта из высоких эшелонов власти организации. Именно его в первую очередь интересует бизнес-эффект и успех проекта. Это «тяжелая артиллерия», которая решает всю проблематику проекта. Проблематику не в части управления проектом (чтобы сделать вовремя и эффективно – за это отвечает менеджер проекта), а в части всех организационных проблем и особенно «поставить на место» влиятельных врагов проекта или его менеджера.

· Заказчик – это тот, кто будет пользоваться результатами проекта. Он определяет (с него надо, по сути, истребовать) результат проекта, критерии / метрики, условия приемки – именно он скажет «ок» или «не ок» результат проекта.

Зачастую Заказчиком и Спонсором трансформационных проектов является одно лицо. Но если роли разделены, то Заказчик скорее всего не будет вдаваться в подробности проекта – будет довольствоваться сухими отчетными данными, чтобы понимать сроки «пришествия» результатов проекта.

· Управляющий комитет (или часто в бизнесе говорят, где Стеринг, где Стиринг Комитет от англ. Steering Committee) – это самый главный орган управления проектом. Да именно он, а не Спонсор-Заказчик или менеджер проекта.

Об управляющем комитете в завершение главы немного расскажу, поскольку это еще часто и «самая страшная сторона» для менеджеров проектов, работающих внутри организации. Именно на этом комитете часто актуализируется страх показаться глупым, что будут ругать – ведь в русском обществе вообще высокий индекс дистанции власти перед обличенных властью «людьми в погонах».

Когда у проекта (или лично его менеджера) есть недоброжелатели из числа управляющего комитета – то они станут играть роль «прокурора». В принцип, менять роли прокурор\адвокат умеют все профессиональные менеджеры – «выпячивать» одно и тоже или как «проступок с расстрельной статьей» или как оправдание «во благо» (в роли прокурора на ошибку менеджера проекта можно сказать «смотрите, что этот негодяй натворил», а в роли адвоката – «супер, на ошибках мы учимся!»). Так что если на управляющем комитете у Вас могут быть прокуроры исходя из матрицы власти\интереса – то там же должны быть и Ваши адвокаты: вовлекайте их и заручайтесь поддержкой и защитой.

Это тот комитет, который уполномочен принимать любые решения по проекту. В некоторых организациях его роль заменяет сам Спонсор-Заказчик, но зависит на самом деле от уровня проекта. Если проект крупный, да еще и с привлечением «маститых» подрядчиков юрлиц, то в управленческом комитете нарисуется Спонсор, Заказчик, парочка самых влиятельных заинтересованных лиц-участников из числа высшего менеджмента, а также и представители подрядчика.

Управляющему комитету приписывают много функций, но я хотел бы выделить несколько наиболее полезных для менеджера трансформационного проекта (рис.1.14).

Рис.1.14. Наиболее полезные для менеджера проекта функции управляющего комитета

a. Как по мне главную ценность для менеджера проекта несет такая задача управляющего комитета, как разрешение проблем и принятие решений, которые ни менеджер, ни Спонсор решить не смогли. Да, Спонсор зачастую тоже не Бог (если это не СЕО или собственник) – особенно когда проект кроссфункциональный и охватывает сферу власти других топ менеджеров.

b. Вторая по ценности задача – это согласование критически больших изменений для проекта (бюджет, сроки, суть и цели проекта и т.д.). В проектах преобразований обычно тут проблем не возникает (особенно если есть на то конкретные обоснования). Скорее некоторым менеджерам проектов личностно надо «переломать» себя в том, что говорить об изменении изначальных параметров по ходу проекта – это нормально.

c. И третья – это заполнение вводными пробелов в проекте, «наведение на путь истинный». Ведь многое в проекте преобразований изначально предусмотреть и спросить нельзя – вопросы возникают по ходу и требует прояснения/дополнения.

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

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

Рассматривайте отчёт на управляющем комитете как возможности порешать проектные вопросы (только не забываем, что «вываливать» комитету нужно не все вопросы, а только те, которые не может решить ни менеджер, ни Спонсор проекта).

А помимо прочего, если Вы в текущий момент времени связываете свою карьеру с текущим работодателем – не забывайте, что именно на комитете Вас видят «в верхах» те люди, которые принимают решения в этой компании. И чем больше и по более толковым вещам Вы там «примелькаетесь» – тем выше вероятность карьерного роста.

И всегда готовьтесь к управляющему комитету (рис.1.15).

Рис.1.15. Подготовка к управляющему комитету

На этом главу закончим. В ней мы рассмотрели заинтересованных сторон и прошлись по трем самым влиятельным сторонам.

КЕЙС: Побеждая влиятельных людей

Вот Вы имеете матрицу заинтересованных сторон, списки влиятельных противников и ярых защитников. Сформировали понимание кем кого нейтрализовать в случае чего.

Вы прячете эту матрицу от «чужих глаз» и надеетесь, что ею воспользоваться не придется: авось, как-то пронесет. Но вот представьте приходит та самая ситуация, когда этим пониманием необходимо воспользоваться.

Если Вы внешний менеджер проекта, то в принципе Вы вольны поступать по ситуации так, как будет лучше для проекта, не считаясь ни с кем, не обращая внимание на чины и имена.

Но если Вы внутренний, то Вам надо быть поаккуратнее. Ведь Вам после проекта возможно еще работать в этой организации – и тут надо быть поосторожнее. Т.е., еще одним фильтром для Вас должен стать Ваш персональный комфорт работы в организации.

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

Ваша главная задача как менеджера проекта «не проспать»: как только Вы видите готовящееся противостояние проекту – если его невозможно сгладить, то сразу «обнажить» конфликт и «спровоцировать бой», а не ждать, когда ударят в наиболее неподходящий для Вас момент.

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

В общем, взвесьте все как будет лучше для Вас персонально (а не для компании или проекта). Я ниже расскажу одну поучительную историю – но выводы из нее уже делайте сами.

ИСТОРИЯ ОДНОЙ ПОБЕДЫ

Теперь расскажу сам кейс: ИСТОРИЮ ОДНОЙ ПОБЕДЫ… В холдинге запустили проект преобразований телекоммуникационного подразделения (выделенное предприятие связи, обслуживающее другие предприятия холдинга).

Изначально уже в оргдизайне данного холдинга был заложен конфликт: ИТ-департамент, с которым связисты были тесно завязаны, исторически подчинялся финансовому директору, а подразделение связи – операционному директору. Т.е., находились в разных «вертикалях власти».

И у финансового директора с момента прихода в компанию было видение «слить» это предприятие с подчиненным ему ИТ-департаментом.

Но операционный директор видел трансформацию по-другому – и запустил проект с изменения процессов и технологий, а также использования аутсорсинга. Т.е., не подразумевающий просто «слияния».

Менеджер проекта (девушка-технарь, 33 лет) взялась за дело и начала двигать проект. Чувствуя покровительство Спонсора, она двигала проект, невзирая на все нападки. Она умело и профессионально «ставила на место». В частности, демонстрировала некомпетентность финдира в технических вопросах и по проекту в целом. А финдир, как назло, все больше и больше пытался влезть и разобраться – но получалось у нее это из ряда вон плохо.

Проектный менеджер не побоялась пойти на конфронтацию и с HR-директором, находящегося в коалиции с финансовым. Сразу же «гасила» все нападки и помехи проекту, привлекая Спонсора, чтобы «размазывать» эту «сладкую парочку». Также на управляющем комитете при любом удобном случае она целенаправленно формировала мнение, что «кадровик и бухгалтер» противники проекта. Делала это с целью, чтобы никто из управляющего комитета всерьез не воспринимал их высказывания в адрес проекта или ее лично – и у нее это довольно неплохо получилось.

Проект закончился успешно. Наш менеджер проекта получила более высокую должность уже в операционном подразделении, непосредственно в вертикали Спонсора.

Но через 7 месяцев у Спонсор принял предложение о работе в другой компании в другой стране. И после его ухода менеджер проекта не могла работать нормально: и финансовый, и HR директор «рьяно взялись» как за нее, так и ее подразделение. Грамотно, монотонно, рутинно создавая ей ежедневные проблемы на ровном месте.

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

А после ее ухода финдир в конце концов все равно получила свое – предприятие связи вошло в состав подчиненного ей ИТ-департамента. Но это уже совсем другая история и не о проектном менеджменте.

Программное обеспечение для управления проектами

Многие уповают на важность программного обеспечения. Но программы – это просто инструментарий. С ним Вы можете более или менее эффективно управлять проектом. Т.е., какую программу использовать это одно из двух:

А) корпоративное требование;

Б) вопрос Ваших персональных профессиональных предпочтений.

По большему счету, это будет зависеть от того насколько Вы готовы осилить ту или иную программу. И, более того, осилив любую одну из них, Вы намного быстрее и будете осваиваться и работать с любыми другими программами.

Я, например начинал с Primavera и через какое-то время мне легко «зашел» MS Project Office (при разработке ПО для внутреннего CRM одного из банков). С некоторыми заказчиками работал также во Wrike в онлайне – таковы были условия проекта.

В части трансформационных проектов преобразований в большинстве случаев требования вести их в конкретном ПО – это удобство для трансформационного офиса предприятия.

Для реального управления трансформационными проектами непосредственно менеджерам проектов в большинстве случаев достаточно мощностей Excel и Power Point – ведь не хранилище ядерных отходов, ядерную АЭС или ультрасовременную подлодку собираем…

Главное из PMBoK за 5 минут

Я ранее уже упоминал РМВоК и говорил, что это не методология – это свод знаний (типа справочник) об управлении проектами. А также рекомендовал обязательно его почитать.

На самом деле в нем нет ничего сложного, а есть важные два блока (рис.1.16):

· 5 групп (категорий) процессов в проектном менеджменте

· 10 основных областей знаний, которые могут быть общеиспользуемыми в проектах. Только помните, что каждый проект зачастую еще может быть дополнен чем-то специфически-отраслевым или организационным.

Рис.1.16. Группы процессов и Области знаний

Вот эти два блока мы бегло и рассмотрим. Я сделаю фокус на 6 версию РМВоК (последнюю, которую я читал на момент написания данной книги).

Начнем с категорий процессов. РМВоК рассматривается 5 групп (категорий) проектных процессов, которые и на уровне здравого смысла используются в менеджменте как таковом.

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

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

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

Контроль – процессы, которые позволяют мониторить ход проекта, обнаружить отклонения от плана и предпринять управленческие воздействия для достижения целей проекта вовремя, в срок и в рамках бюджета.

Завершение – сдача-приемка результата, закрытие проекта и всех работ и контрактов по нему.

Тут вроде все просто. Главное не подумайте, что процессы = фазы жизненного цикла проекта. Это ПРОЦЕССЫ и они неизменны в отличии от фаз проекта, которые можно определять под каждый конкретный проект.

Теперь об областях знаний.

Управление содержанием проекта – определение целей, описания результата проекта, сбор требований/характеристик и перечня необходимых работ.

Управление графиком – детализация и дробление работ (при необходимости до операций) и их последовательности, определение длительности, привязка к календарным датам, разработка графика и его контроль и т. д.

Управление стоимостью – тут процессы, которые позволяют определить и оценить стоимость, составить бюджет проекта и осуществлять его контроль.

Управление качеством – процессы обеспечения и контроля качества в проекте.

Управление ресурсами – при чем в последней нотации PMBoK именно управление ресурсами: всеми – от физических, людских, оборудования, материалов, активов и т.д.. В отличии от предыдущих версий РМВоК, где фокус этого раздела был на людских ресурсах – от планирования количества и качества персонала, подбора и развития – и до ежедневного управления командой проекта. Это изменение реально толковое – по факту мы давно уже с коллегами обсуждали, что реально в проектах менеджер управляет всеми ресурсами.

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

Управление рисками – каждый проект всегда сопряжен с рисками. Потому тут задействуются процессы определение/идентификация рисков, количественная оцифровка и качественный анализ, система мониторинга рисков и план реагирования и предупреждения рисков.

Управление закупками проекта – планирование закупок, осуществление и контроль закупок.

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

Отдельную оговорку сделаю о международных проектах (когда проекты по разным временным поясам + межкультурные + межязыковой барьер). Вспоминая участие в проектах в ОАЕ и Норвегии, могу сказать, что сложность коммуникации может создавать много проблем на ровном месте. С языковым барьером думаю понятно (чего только необходимость перевода документов и трактований/разъяснений стоит), а в культурных особенностях запоминаются такие вещи как:

· дистанция власти – на Востоке очень боятся наделенных властными полномочиями. Боятся слово сказать вразрез. На Западе – нормально так пройдутся, покритикуют, повозмущаются если что.

· Восприятие полов – ну не привыкли на Востоке к женщинам как главным или даже равноправным. И это в проектах остро чувствуется.

· Даже такие вещи как праздники и обычаи. Например, у нас майские праздники и с Днем Победы – это святое, а для норвегов – будние рабочие дни и им ничего не стоило назначить ключевое совещание и групповую работу по проекту с 1 по 10 мая – ребята из Россия и других стран СНГ были крайне возмущены.

Управление заинтересованными сторонами (как их еще называют с англ. стейкхолдерами) – на них я уже отдельно останавливался. А данная группа процессов в РМВоК рассказывает, как определить, оценить влияние, вовлечь и отслеживать вовлеченность заинтересованных сторон в проекте.