Стейкхолдеры: казнить нельзя помиловать

Факторы успешности проекта

 

 

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

 

 

 

 

 

 

По некоторым оценкам, количество заваленных проектов в последние 10 лет составляет примерно 25%, то есть четверть. Иногда этот показатель составляет 19%, а потом снова поднимается. Но как видно из картинки, успешность проектов, в первую очередь, зависит от эффективной коммуникации со всеми стейкхолдерами и вовлеченности всех стейкхолдеров в ход проекта.
 
Некоторые считают, что наиболее важными на проекте являются риски, оценка сроков и бюджета. Именно эти темы чаще всего обсуждаются на конференциях по правлению проектами. Но мое мнение, что все эти факторы вторичны. Риски, сроки и даже стоимости проекта: влияние на эти факторы оказывают стейкхолдеры. Поэтому эта тема очень важна.

Показательная история о влиянии на проект

 

 

Я начал заниматься темой управления проектами и стейкхолдерами, потому что набил, действительно, много реальных шишек на своих собственных проектах.  Историй много, но одна из них наиболее показательная.
 
12 лет назад я руководил одним проектом и уже понимал, что главное – это вовлеченность руководства предприятия, получение результатов, основанных на удовлетворенности этого высшего руководства. Как руководитель проекта, я запланировал и проводил периодически совещания с руководством заказчика – раз в две недели/месяц. Сначала я заметил, что когда рассказываю о ходе проекта, руководитель смотрит на меня с хитрым прищуром, как один из тех людей, которые знают, что ничего не получится. Еще через несколько встреч я вижу, что у директора появилось какое-то недовольство, хотя проект шел, как надо. Я поделился с айтишником предприятия, объяснил, что пытаюсь вовлечь руководство в процесс, но директор «не вовлекается». В ответ он рассказал, что дочка директора работает в одном из подразделений компании, и она против внедрения этого проекта, поскольку с ней ничего не обсуждалось, и она в процесс никак не вовлечена. В итоге мнение руководителя формируется не на том, что ему рассказывает управляющий проектом, а на том, что ему дочка рассказывает.
 
Вот такие моменты подтолкнули меня полностью погрузиться в тему работы со стейкхолдерами – кто именно и как может влиять на успешность проекта в целом.
 
Отдельно отмечу, что изложенная в докладе информация (особенно все, что касается не теории, а практики) в большей степени мое личное и субъективное отношение к проблеме. С ним можно соглашаться или не соглашаться. Но субъективизм мой основан на большом количестве проектов, которые я осуществил, в качестве инженера-программиста, руководителя проекта, руководителя программы проекта, а также на опыте взаимодействия с людьми в этих проектах и в качестве бизнес-тренера. У меня есть сертификат Института управления проектами (Project Management Institute, PMI), и я сертифицированный профессионал в управлении проектами (Project Management Professional, PMP), что является признанным отраслевым сертификатом для руководителей проектов. Я преподаю, веду занятия для разных групп людей, и, собственно, в том числе исходя и из их видения, сформировал какое-то свое отношение, базирующееся, конечно же, на общемировом своде знаний об управлении проектами PMBoK.

 

Немного теории об управлении заинтересованными сторонами в проекте

Существует 4 основных процесса, связанных с заинтересованными сторонами:
 
1.      Их надо определить, т.е. найти, кто в проекте является заинтересованной стороной.
 
2.      Спланировать, как с ними работать, какие действия предпринимать, чтобы вовлечь заинтересованные стороны в проект.
 
3.      Воплотить план в жизнь, управлять заинтересованными сторонами или, правильнее сказать,  управлять для заинтересованных сторон.
 
4.      Контролировать этот процесс, (т.е. все, что делается в рамках проекта).

Все это похоже на цикл Деминга, это постоянно повторяющийся процесс. В ходе проекта все повторяется по несколько раз, и нет такого, что мы спланировали, повесили план на стенку и в соответствии с ним действуем, определили, кто является заинтересованными сторонами, положили под сукно и просто смотрим. Нет, мы всегда должны повторять этот процесс.
 
Коротко о составляющих процесса. Кто знаком с методологией PMI, знает, что вся технология основана на процессах, и есть определенное понятие процесса. У процесса всегда есть входы, инструменты и методы, которыми мы пользуемся в ходе выполнения процесса, и определённые выходы. 
Процесс определения заинтересованных сторон нацелен на то, чтобы мы поняли, кто у нас является стейкхолдерами в данном проекте.  На выходе у нас имеется некий реестр, список, с кем надо работать в рамках данного проекта.

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

 

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

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

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

Теперь вы знаете, в чем заключается управление заинтересованными сторонами с точки зрения свода знаний PMI.

От теории к практике

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

Как выявлять заинтересованные стороны? Самый худший способ выявить заинтересованную сторону – это предлагать заполнить анкеты заказчикам, в которой они должны сами написать, кто является заинтересованными сторонами в проекте. На 30% оно, возможно, и совпадет, но остальное – мусор. Потому что, скорее всего, эту анкету будет заполнять айтишник, который включит сюда все руководство предприятия, без оглядки на содержание проекта, применимость его результатов, окружение проекта как таковое.
 
Поэтому выполнять этот процесс вам надо самостоятельно с вашими людьми. Начинать делать это нужно еще до старта проекта, когда вы приходите на обследование перед проектом. Те люди, которые общаются с заказчиком, изучают потребности заказчика, — это достаточно большой кладезь информации для вас, как руководителя проекта. Поговорите с ними, обсудите результаты предварительного обследования не только с точки зрения функциональности системы, но и с точки зрения окружения проекта в целом. Они расскажут, что в каком отделе кто-то уже собирается идти на пенсию, кто-то в декретный отпуск, кто-то точно является явным противником проекта. Вся эта информация, полученная в результате экспресс-исследований, должна быть вами зафиксирована. Потому что, когда начнется уже непосредственно проект, это очень поможет.
 
И умейте правильно задавать вопросы. Что это значит? Иногда мне говорят, что самый правильный вопрос звучит так: «Когда у нас наступит большая проблема во взаимоотношениях с заказчиком, кто будет разруливать их?». Вопрос может быть и правильный, но начинать с него некорректно. У заказчика сразу перевернется сознание того, что вы хотите именно создать проблемы на проекте, а не успешно его реализовать. Правильный вопрос – это вопрос, который касается выяснения проблемы. Мне больше всего нравится вопрос с точки зрения оценки эффективности проекта.
 
У Пола Страссмана есть теория, согласно которой все те профиты, все те плюсы, которые предоставляет ИТ-система в процессе ее использования, должны быть превращены в пользу для организации конкретными ответственными за них людьми. То есть человек должен отвечать за то, как он использует функциональные возможности, которые дает нам система, чтобы превратить их в прибыль для организации. Говоря простым языком, если мы поставили систему, которая позволяет экономить большое количество времени кладовщиков, комплектовщиков, службы отгрузки, то должен быть человек, который должен продумать, куда задействовать этот персонал, как это будет работать в рамках реструктуризации компании. А не так, что мы внедрили систему, люди экономят время, но в это время чай пьют или в компьютере играют.
 
Задавая такие вопросы, мы сможем понять, кто у нас будет заинтересованным лицом в проекте, причем, часто их бывает два: один – руководитель, который в данной функциональной области хорошо себя зарекомендовал как эксперт, а второй – это его помощник, который собственно будет думать вместе с руководителем и  апробировать какие-то решения.
 
Очень помогает определять заинтересованные стороны простое рисование на бумаге. Есть такое понятие, как «стейкхолдер  maps», когда мы рисуем паутинку от одного до второго, затем до третьего, четвертого и т.д., в том числе влияние друг на друга. Это нелинейная таблица, а именно взаимодействие стейкхолдеров внутри организации.

 

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

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

 

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

Мои наблюдения, или как работать с людьми со стороны заказчика
 
Есть несколько моментов, которые не очень относятся к теории, но которые, возможно, помогут вам понять, как работать с персоналом заказчика.
 
Первый касается того, как нужно относиться к тем, с которыми работаете. Надо понимать, что эти люди не будут действовать рационально с вашей точки зрения. Их поведение обусловлено большим множеством фактов, поэтому если вы считаете, что человек должен поступить именно так, потому что это принесет пользу или это правильно, это не обязательно так и произойдет. Эта мысль всегда должна быть у вас в голове.

Вторая мысль основана на понимании удовлетворенности. Какая математическая формула удовлетворенности?  Результат/ожидание. Чем больше у нас ожидания и меньше результат, тем меньше у нас коэффициент удовлетворенности. Я не призываю, конечно, с первой же встречи пугать заказчика, что в проекте все будет плохо. Но нужно исходить из того, что проект будут оценивать, исходя из коэффициента удовлетворенности. И это и ваша личная оценка, как руководителя. Насколько широки ожидания заказчика, а эти ожидания часто представлены в такой форме, можно посмотреть на картинке. Кроме того, у заказчика и исполнителя всегда абсолютно разные ожидания.

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

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

И это нормально. Только поймите, что они тупые только с вашей точки зрения, поскольку не владеют всеми теми техниками и технологиями, которыми владеете вы. Поэтому с точки зрения понимания хода проекта и результатов процесса, заказчик, действительно, тупой. Но это не значит, что он тупой как таковой. Можно сказать, что надо учиться, но никого нельзя обзывать тупым. Я специально провожу беседы с командой перед началом проекта, и всегда об этом напоминаю. Даже памятка специальная разработана – памятка поведения в проектах. Не надо заказчиков называть тупыми, помогите им стать умными.
 
Второй паттерн – это проектная дружба. Конечно, выполнение общих обязанностей и сотрудничество в  должно иметь место, но не дружба.. При этом если речь идет о глубоких взаимоотношениях (вместе отмечают праздники, крестят детей), то в таком случае такая дружба всегда приводит к последствиям и проблемам в проекте, когда личные отношения сильно переплетены с профессиональными.

У меня есть только один успешный пример. У меня был коллега – он пришел на один проект, познакомился с девушкой, женился успешно, потом проект закончился, они развелись. Пришел на второй проект, снова познакомился, снова женился… Пока живут. Но деловым отношениям не надо скатываться в дружбу.
 
Третье. Не нужно перегибов, не нужно падать ниц перед заказчиком. Должны быть взаимные отношения: мы ему пользу приносим, он нам за это платит. Поэтому мы должны ожидать и строить партнерские отношения, а не отношения «хозяин и слуга». В то же время не надо давать пинка, мол, я лучше тебя знаю, что тут надо сделать. «Поскольку я строю вам систему, вы тут букашки» – так тоже нельзя.

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

***************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 DEVELOPER. Больше статей можно прочитать здесь.

В 2024 году приглашаем всех принять участие в 7 региональных митапах, а также юбилейной INFOSTART EVENT 2024 в Москве.

Выбрать мероприятие.