Сергей Барамба
От барьеров к результатам: Как наладить эффективное взаимодействие со стейкхолдерами

Введение

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

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

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

Почему будет полезно прочитать эту книгу – за 15 лет управления различными проектами и обучения студентов я успел попробовать разные подходы, знаю какие из них работают в современной действительности, а какие нет. Прежде чем сесть писать книгу я перечитал все что смог найти на русском и английском языке посвящённое стейкхолдерам. Каждая книга по-своему рассказывала, что надо организовать для того, чтобы обеспечить управление стейкхолдерами, но не давала информации как именно это сделать в той или иной ситуации. Приступая к написанию книги, я поставил для себя задачу исправить ситуацию и помочь руководителям проекта не только систематизировать знания о роли стейкхолдеров, их явном и не явном влиянии на ИТ проекты. А ещё узнать о нюансах, и получить чёткие и практические советы, которые можно попробовать прямо тут и сейчас в том проекте, за который ты сегодня отвечаешь. В целом успех ИТ проекта во много зависит от правильно выстроенных взаимоотношений со стейкхолдерами: заказчиком, пользователями, генеральным директором. В конце проекта многие из них меряют успех проекта через свои критерии – сколько в итоге активных пользователей, сколько обошлось создание этого ИТ продукта, насколько профессионально работала команда и держала в курсе событий.

Приятного чтения, ваш Сергей Барамба.

Глава 1. Кто такие Стейкхолдеры. Немножко терминологии и теории.

Термин стейкхолдер

В основе данного термина лежит английское слово – “Stakeholder”, буквально – «владелец доли». Оксфордский словарь даёт нам такое определение – человек, который интересуется или беспокоиться о чем-нибудь, особенно в бизнесе. Термин на русский язык можно перевести, как «заинтересованная сторона». Состоит из слияния двух слов

1) stake – может иметь несколько значений перевода на русский:

– доля (в компании)

– что-то, что ставится на кон ради прибыли или убытка

– находиться под угрозой

– заостренный кусок дерева или другого материала, вбитый в землю в качестве маркера или опоры

2) holder – хранитель, держатель.

История первого использование этого термина уносит нас в эпоху колонизации Америки. Во время экспансии на Запад европейские поселенцы буквально «застолбили» (“stakes”) себе землю, чтобы заявить о своих правах собственности, вытеснив коренных жителей, которые изначально там жили. В документах о таких поселенцах описывали словом «стейкхолдеры».

Существует версия что возникновение современного значения слова «стейкхолдер» связано с азартными играми. Так потом называли человека, принимающего ставки и хранящего у себя до объявления победителя.

Считается, что современная история концепции заинтересованных сторон началась с монографии Р. Э. Фримена «Стратегическое управление: роль заинтересованных сторон», изданной в 1984 г¹.

Для проектного управления под словом «стейкхолдер» понимают лицо, группу или организацию, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта².

А управление стейкхолдерами (Stakeholders management) – Описывает процессы и методы, необходимые для определения заинтересованных сторон проекта и управления взаимодействием между ними и проектной командой.

Как правило, работая со стейкхолдерами руководители проектов концентрируют усилия на трёх группах:

– Кто активно вовлечен в проект и работает в нем (спонсор проекта, проектная команда, спонсор, управляющий комитет, привлеченные сторонние компании и другие исполнители и т.д.)

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

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

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

На основе влияния можно потом выстроить векторы воздействия: Эмоциональный и Рациональный.

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

Рациональный вектор позволяет изменить установки насколько стейкхолдеры уверены в том, что выполняемая работа и результаты проекта являются правильными, этот путь называется «завоеванию умов».

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

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

Стейкхолдеры в «Результат проекта» и в «Процессы проекта».

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

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

Обзор процессов работы со стейкхолдерами по PMBOK версии 6.

Рассказ о методологиях работы со стейкхолдерами был бы неполным, если не затронуть насколько детально расписаны процессы, в пусть уже считающейся устаревшей после выхода в свет версии 7, но всё-таки все ещё актуальной PMBOK 6.

В книге описывается 4 процесса:

Как и все другие процессы в PMBOK – все описано очень теоретически, и не даёт ответов как именно с практической точки зрения все вышеуказанное реализовать руководителю проекта. Главная польза для руководителя проекта от изучения описания процессов в книге – понимание последовательности выполнения процессов один за другим и то, что «Мониторинг вовлечения стейкхолдеров» осуществлять в течении всего проекта.

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

Что нам говорит Scrum про работу со стейкхолдерами

В Scrum Guide от ноября 2020 года слово Стейкхолдер встречает 13 раз, при этом само определение термина не приводится. Поэтому, мне кажется, уместным будет пользоваться общепринятым определением, которое приводилось выше. Так же Scrum Guide оперирует ещё термином ключевые стейкхолдеры (key stakeholders), и тоже без расшифровки определения. Логично нам предположить, что это какие более важные стейкхолдеры, чем обычные, без приставки «ключевые».

Основная роль управления стейкхолдерами возлагается на Владельца продукта (Product Owner), который должен перекладывать выявленные потребности от всех стейкхолдеров внутрь артефакта под названием Беклог Продукта (Product Backlog). Он должен хорошо знать в лицо стейкхолдеров, каждый день с ними взаимодействовать, как требует 4й принцип Agile – «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе»³.

При этом в рамках уже согласованных задач, взятых в работу командой Скрам Мастер (Scrum Master) выполняет ряд важных задач при взаимодействии со стейкхолдерами:

– Фасилитирует взаимодействие и организовывает сотрудничество между заинтересованными сторонами.

– Осуществляет устранение барьеров между стейкхолдерами и Scrum-командами.

– Помогает пользователям и стейкхолдерами понимать и применять эмпирический подход к решению сложных задач.

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

В целом ответственность за управление стейкхолдерами сразу распределена между всеми ролями в Scrum:

– Владелец продукта по новым задачам и метрикам

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

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

7 принципов управления стейкхолдерами

Макс Кларксон (1922 – 1998) – выдающийся исследователь в области управления заинтересованными сторонами описал основные принципы по управлению заинтересованными сторонами:

Принцип 1 – Мониторинг:      РП должен отслеживать то, что вызывает беспокойства и опасения заинтересованных сторон, а также должны учитывать их интересы при принятии решений и деятельности.

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

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

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

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

Принцип 6 – Защита прав:      РП должны полностью избегать действий, которые могут поставить под угрозу неотъемлемые права человека или привести к рискам, которые, если их ясно понять, будут явно неприемлемы для соответствующих заинтересованных сторон.

Принцип 7 Конфликты:      РП должны признавать потенциальные конфликты между собой и заинтересованными сторонами или просто между стейкхолдерами. Конфликты должны разрешаться посредством открытого общения, соответствующих систем отчетности и стимулирования и, при необходимости, проверки третьей стороной.

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

Output, Outcome, Impact – почему они недовольны результатом

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

Что бы разобраться этом эффекте и найти способы преодоления такого препятствия сначала давайте изучим 3 термина и разберём пример:

Output (англ.: выход) описывает результат который достигается определенной активностью. Может относиться к продукту, услуге или другому легко ощутимому достижению.

Например, вам на встрече пожаловался генеральный директор что, работая в вашей ИТ системе согласования заявок на оплату, очень медленно происходит массовое выставление виз. Вы провели замеры и действительно на пакет в 20 заявок требуется около 60 секунд. Вы потратили 20 часов работы одного разработчика и оптимизировали код таким образом что вышеуказанный пакет согласовывается всего за 20 секунд. Ваш Output – 3х кратное увеличение производительности и даже не потребовалось времени больше недели. Классный результат «за дёшево» и надо «пиариться» перед стейкхолдером. Для красоты цифр можно в рассказе использовать значение «300%». В рамках этой задачи в нашем чек-листе все метрики «зелёные»:

– производительность увеличилась – да;

– без дополнительных ресурсов и затрат – да;

– серверные мощности остались прежние – да;

– срок между постановкой задачи и результатом (Time-To-Market) приемлемый – да.

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

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

В продолжение нашего примера, в ответ на ваши достижения в трёхкратное увеличение вы получаете хлёсткое: “я проверил, ничего не изменилось, все так же медленно».

Что мы получаем в итоге:

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

– Сами получаем статус «Пети» кричащего «волки-волки» перед самым важным стейкхолдером.

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

– Дополнительные затраты времени для себя и программиста.

Если проанализировать ситуацию, можно было бы в такую ситуацию не попасть, если сначала спросить какое значение производительности является приемлемым и ожидаемым. А ещё провести замеры поведения пользователя в системе. Тогда можно было бы увидеть, что, выставив «визы» на документах и нажав кнопку, основное окно сворачивается, потому что там идёт длительный процесс. Пока идёт обработка продолжается работа в других документах, чтобы не терять время. Несколько минут спустя, он возвращается к основному окну вашей программы выбирает пачку в новые 15-20 документов и операция повторяется. Поэтому прирост производительности от 60 до 20 секунд на самом деле не заметен. Да и как выяснилось чёткое значение первичного показателя в 60 секунд даже было не известно генеральному. Решить задачу можно было бы, если бы в интерфейсе визы выставлялись бы «мгновенно» (а именно такие в целом ожидания были озвучены позднее на детальном интервью), а потом уже дописывались в систему, в отложенном формате. Но это было бы возможно только через создание нового процесса, а не в оптимизации текущего в 3 раза.

Слово impact (анг.: воздействие) описывает результат в длительной перспективе и может оказаться не в прямой зависимости от outcome или output.

В целом, конечно, impact как правило, больше связан с какими-то серьёзным метриками, которые можно достигнуть через длительное время от событий output и outcome используя продукт, но и в нашем примере долгосрочное влияние уже можно представить:

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

– в уровне мотивации программиста, он работу сделал, но нет подтверждения что она принесла результат;

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

Глава 2. Идентификация и анализ стейкхолдеров

Что необходимо руководителю проекта для управления заинтересованными сторонами

Когда речь заходит об управлении заинтересованными лицами в ИТ проекте на бумаге рецепт идеального руководителя (дальше, я буду привычно для среды управления проектами, иногда использовать сокращение «РП») выглядит просто, не сложнее рецепта блинов. Итак, нам потребуется:

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

Понятное дело, в нашем рецепте, почти половина зависит от удачи. А она нет-нет, да и отвернётся даже от самого везучего, поэтому это не наш метод. На самом деле, успех заключается в методичном и последовательном выполнении 4х шагов по работе со стейкхолдерами:

Шаг 1. Выявить

Шаг 2. Классифицировать

Шаг 3. Выработать план на основе классификации

Шаг 4. Постоянная оценка и корректировка планов, инструментов и подходов

И это все на протяжении всего проекта, до самого последнего дня, и иногда даже после. Руководитель должен готовиться погружаться постоянно в этот процесс и держать в голове много дополнительный информации, считывать эмоции, настроения. И самое главное – вкладывать в это свою энергию.

Шаг 1. Выявить

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

Прежде чем приступать к идентификации стейкхолдеров ИТ проекта важно визуализировать «Жизненный цикл» самого проекта для участников мозгового штурма. Это сильно поможет команде генерировать мысли и наносить на карту.

Для процесса идентификации попробуйте в команде проекта задать нижеследующие вопросы и записать ответы.

Вопросы для идентификации стейкхолдеров в области «Результат проекта»:

Для кого мы создаём данный продукт? Кто его будет использовать? Кому предстоит его администрировать и эксплуатировать?

Как вы думаете кто может пригодиться вне команды на каждом из этапов проекта.

Что необходимо знать, чтобы выпустить продукт?

Кто-то уже в компании имеет соответствующий опыт?

Кем будут приниматься решения по продукту?

Чье мнение окажется важным и требуется посоветоваться прежде, чем принимать решение.

Кто вне команды будет выполнять действия согласно принятых решений?

Чья активная поддержка имеет существенно значения для успеха проекта?

Для кого проект будет выгоден, а для кого несёт угрозу?

Кого в обществе мы можем потревожить нашей активностью?

Вопросы для идентификации стейкхолдеров в области «Процессы проекта»:

С кем придётся согласовывать методологию работы над проектом?

В чьих руках будут находится финансы, и кто будет согласовывать движение денежных средств в рамках проекта?

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

Кто владелец регламентов и положений, в рамках которых будет осуществляться деятельность внутри проекта?

Какие ключевые законодательные акты могут повлиять на достижение целей проекта? С кем надо контактировать и консультироваться что бы не наступили риски?

Кому необходимо будет сдавать отчёты?

На чьи метрики может повлиять проект?

Кто будет принимать итоговый продукт когда проекта закончится?

В рамках проектов очень часто приходится оперировать аббревиатурой «ЛПР»⁴– Лицо принимающее решение. Это такой человек, который наделен полномочиями в той или иной сфере и несёт прямую ответственность за реализацию и последствия принятого решения. Это не обязательно должен быть руководитель подразделения, им может оказаться лидером или экспертов в определённой области. При этом он должен обязан выдать в команду проекта решение. Ключевое слово «обязан», и от выданной информации порой может зависеть каким будет ИТ продукт. Для ЛПР важна высокая оперативность и к его помощи команда прибегает в случаях недостатка информации для принятия решения или нехватки времени. Таким образом такие ЛПР становятся стейкхолдерами и должны быть идентифицированы.

Реальные и виртуальные стейкхолдера

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

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

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

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

Еще одним представителем «виртуальных» стейкхолдеров можно назвать волонтёров.

В планах реализации ИТ проектов волонтеры могут оказаться полезными для Альфа- и Бета-тестирование, написания и перевода документации на другой язык, проведения обучения пользователей. Поэтому своевременная идентификация волонтеров как стейкхолдеров поможет спланировать каналы привлечения их в проект, круг задач, которые им необходимо решить, формат взаимодействия и формы отчётности.

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

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

– заранее подготовить, необходимые формы и отчёты, которые нужно будет заполнять волонтерами

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

– на анализ качества выполненной работы силами волонтёров.

А ещё Руководитель проекта должен определить канал связи и выстраивать корректное информирование для волонтёров о:

– старте проекта

– сути проекта и его значимости;

– начала и завершении набора волонтёров

– скором привлечение к задаче

– старте этапа с привлечением волонтёров

– роли, которую сыграли в проекте волонтёры

Таким образом бесплатный по статье ФОТ ресурс в виде волонтёров начинает иметь определённое значение в других строках бюджета и календарного расписания проекта.

Следующая информация позволит правильно выбрать на следующем шаге провести классификацию и выбрать стратегию: волонтёры будут обладать минимальной властью, но положительно относится к нашему проекту.

Со временем, в процессе производства ИТ продукта некоторые из виртуальных стейкхолдеров перейдут к реальным представителям, а по некоторым так и останутся в документах и мыслях.

Шаг 2. Классификация

На втором шаге, происходит классификация полученного на первом шаге списка. Общепринятой практикой подготовки проектной документации является распределение всех стейкхолдеров в один из квадрантов Матрица власти и интересов, см. рис.2.1

рис. 2.1. Матрица «Власти и интересов» стейкхолдеров

И базовые стратегии работы со стейкхолдерами сводятся тоже к четырём стратегиям.

Давайте разберёмся с характеристиками и свойствам квадрантов и стратегий. Для простоты восприятия я свёл все в одну таблицу:

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

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

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

Как правило «Общественность» относится «к противникам» на матрице.

Жизненный цикл стейкхолдера

Каждый стейкхолдер в рамках проекта проходит 4 стадии:

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

Основные триггеры прекращения отношений:

– увольнение или перевод стейкхолдера

– выполнение всех требований в ближайшей перспективе

– истечение срока трудового или хозяйственного договора

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

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

Как говорится в пословице «одна дверь закрывается, другие открываются», так и завершение одних отношений должны спровоцировать анализ положения вещей, на выявление новых стейкхолдеров.

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

Шаг 3. Выработать план

Наступает время 3го шага – руководитель должен выработать план на основе классификации. Самый сложный период. План необходимо постоянно пересматривать, корректировать, выполнять запланированные в нем действия, смотреть на результаты.

Со своей стороны предлагаю в виде примера вот такой формат шаблона 7 шагового плана.

План работы с со Стейкхолдерами

Данный документ имеет гриф для личного использования.

Название проекта: если ведёте несколько проектов, чтобы не путаться, лучше указать

Дата редакции: 01.03.2025

Дата следующей редакции: 01.04.2025 (как правило к плану нужно возвращаться раз в месяц и закладывать на работу с ним не меньше 1 часа).

Шаг 1. Список Стейкхолдеров и краткая информация

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

.1. 

Вводная информация

Повторить заполнение для каждого стейкхолдера.

1.2. Текущие конфликты

Тут руководитель проекта записывает информацию о затрагивающих проект конфликтах.

При этом РП может выступать или стороной конфликта или арбитром, а стратегии как правило выбираются из списка, приведённого в таблице.

ШАГ 2. Квадрант оценки стейкхолдеров

Перенесите ID необходимого стейкхолдера на нужный квадрат. Раз данная информация только для ваших глаз, указывайте реальное положение вещей и на стратегии для данного квадрата будут основываться ваши шаги с данным стейкхолдером.

Шаг 3. Планируем мероприятия, направленные на проведение коммуникаций в предстоящем периоде

Таблица заполняется только для тех стейкхолдеров, с которыми вы планируете осуществлять мероприятия.

Шаг 4. Планируем мероприятия, направленные на изменение отношения к проекту у стейкхолдера

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

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

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

Шаг 5. Планируем мероприятия, направленные на сохранение отношения к проекту у стейкхолдера и выполнения ценных для проекта активностей

Шаг 6. Планируем мероприятия, направленные на выявление новых стейкхолдеров

Шаг 7. Планируем мероприятия, направленные на смену этапа жизненного цикла для стейкхолдера

К действиям направленными на прекращение может стать:

– подписание      актов или каких-нибудь завершающих документов

– передача инструкций и документации о продукте

– проведение «итоговой» встречи на которой поставить точку и сформировать пути взаимодействия по поддержке продукта не через команду проекта

– донести информацию до команды проекта о новом статусе стейкхолдера.

Шаг 4. Постоянная оценка и корректировка планов, инструментов и подходов

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

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

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

Глава 2 Формы влияния стейкхолдеров на ИТ проект

Стейкхолдер (Stakeholder) vs Стейкитер (Steak Eater), почему важно их различать и удовлетворение чьих интересов важнее.

В отличии от обычного, не ИТ проекта, например строительства загородного дома, стейкхолдер и является основным потребителем благ которых несёт продукт. Он постоянно находится в гуще событий, его мнения запрашивается в моменте и учитывается как с точки зрения платёжеспособности и формирования условий проекта, так и с точки зрения пользования продуктом. Но в ИТ сфере не всегда всё также.

Небольшое отступление в историю из моей личной жизни, чтобы объяснить читателю появление термина «Steak Eater». Давным-давно, когда я не так хорошо знал английский язык и этимологию слова «cтейкхолдер», я в голове на слух переводил часть слова стейкхолдер как «Стейк» – кусок дорогого мяса – что-то, редкое и дорогое. Все потому, что до этого не встречал написания термина на английском, а на слух и в письменности все печаталось на русском языке. У меня получалось что «cтейкхолдер» – это хранитель чего-то ценного как, кусок дорогого стейка в элитном ресторане. Вот такая терминологическая фантазия тогда у меня была. Работая в ИТ, к нам в сервис-деск систему регулярно поступали заявки от руководителей (cтейкхолдеров) в которых надо было выполнить какое-нибудь действие или настройку для его подчинённого. И мои коллеги после завершения работы или постановщику задачи сообщают информацию только стейкхолдеру, или только мне или рядовому сотруднику. Напрочь забывая, что в целом тут целый треугольник или даже четырёхугольник «заинтересантов». И тогда возникла потребность выделять отдельно тех, кто заказывает и тех для кого делается настройка или работа. И таким образом у меня появился новый термин «cтейкитер».

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Strategic Management: A Stakeholder Approach. R. Edward Freeman, Pitman, 1984

Вернуться

2

PMBOK® GUIDE Seventh Edition, Project Management Institute, 2021

Вернуться

3

https://agilemanifesto.org/iso/ru/principles.html

Вернуться

4

Иногда ещё используют аббревиатуру ЛДПР – Лицо действительно принимающее решение чтобы выделить того, за кем последнее слово.

Вернуться