Как работать со стейкхолдерами? Основы стейкхолдер-менеджмента для РМ и бизнес-аналитика

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

Для того чтобы работать с требованиями, нам нужно сначала разобраться, кто источник этих требований, как этим источником управлять, чтобы он не иссяк, не затух, или наоборот не затопил нас потоком требований.

Поэтому первая статья посвящена основам стейкхолдер-менеджмента (Stakeholder Management, англ.), то есть управлению заинтересованными сторонами на проекте / продукте.

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

Я, как менеджер проектов, действительно занимаюсь управлением заинтересованными сторонами:

Как бизнес-аналитик я управляю стейкхолдерами иначе:

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

Давайте для начала договоримся о терминах, чтобы говорить на одном языке, и вы не говорили, что я не говорила:

Историческая справка: отцом теории управления заинтересованными сторонами плюс-минус в том виде, как мы знаем его сейчас, считается Эвард Фримен, его книга «Стратегический менеджмент: концепция заинтересованных сторон» (англ., Freeman R. E. Strategic Management: A Stakeholder Approach) дала и определение стейкхолдера, и расширила менеджерский взгляд на то, как управлять чужими интересами в бизнесе, и дала какие-то техники (анализа, управления, например, объединения с конкурентами для удовлетворения интересов регулирующего органа).

Важное уточнение для бизнес-аналитика: в Руководстве к Своду знаний по бизнес-анализу, BABOK Guide от IIBA, определен перечень основных стейкхолдеров, с которыми бизнес-аналитику нужно иметь дело, и этот перечень отличается от вариантов Э. Фримана, или вариантов, которые есть в моих статьях, а так же расписаны задачи, которые бизнес-аналитик выполняет, привлекая этих стейкхолдеров (и задачи тоже отличаются от моего опыта, например). Как вариант, в BABOK Guide есть такие роли как руководитель проекта, спонсор, тестировщик, регулятор, клиент, поставщик, конечный пользователь, и вот все они участвуют в задаче спецификации и моделирования требований. Мне сложно прям вот с чистой душой сказать, что я принимаю целиком и полностью логику BABOK Guide, но вам может зайти, поэтому посмотрите его внимательно прежде чем организовать свою работу с заинтересованными сторонами.

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

В контексте проектов ожидания участников связаны с их представлениями о том:

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

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

Итак, с чего начать? С составления полного списка всех, кто хоть как-то связан с проектом. Выявление стейкхолдеров — работа для РМа, но он может подключать остальных членов команды в контексте вопроса «А кто еще заинтересован в результате проекта / получении выгоды от результата? С кем стоит поговорить мне / члену моей команды для решения какой-то задачи?»

Можно работать по категориям стейкхолдеров, записывая всех, кого найдем и вспомним:

На выходе у нас должен быть список стейкхолдеров, в котором указано:

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

Вот здесь можно прочесть подробнее: моя статья для сервиса Кайтен про управление ожиданиями.

Если коротко, то мы можем составить таблицу в виде ответа по формуле:

Например:

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

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

Для этого берем матрицу «Влияние/Интерес» и располагаем на ней всех стейкхолдеров:

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

Если низкий интерес и высокая власть (нижний желтый квадрант), то это стейкхолдеры, которых нужно держать в курсе, потому что если они будут не в курсе, им будет не интересно поддерживать проект, и они могут его закрыть (им-то результат не интересен). С ними тоже работать предстоит РМу (чаще всего это С-level, финдир, комдир, ИТ-директор, руководители смежных направлений, напрямую не получающих выгоды от проекта).

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

И есть зеленый квадрант, когда и низкая власть, и низкий интерес, это все мимокрокодилы, наблюдатели, например, линейные сотрудники других каких-то отделов, с ними направленной работы ни РМ, ни БА не ведут, но просто информируют о том, что вот есть такой проект, у него вот такие будут результаты и вот такие выгоды, порадуйтесь, мол, за своих коллег по компании. Иногда это сотрудники, которые являются исполнителями точечных задач в процессе, вокруг которого строится проект.

Ну вот мы проанализировали наших стейкхолдеров, что мы имеем в итоге?

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

Стратегия взаимодействия это чаще всего стратегия коммуникации, писала про нее здесь, предложила для вас шаблон именно коммуникационного плана на конкретном примере. Разница между реестром стейкхолдеров и коммуникационным планом в том, что в реестре ВСЕ заинтересованные стороны, с которыми может и НЕ ВЕСТИСЬ коммуникация, а в коммуникационном плане ТОЛЬКО ТЕ, С КЕМ КОММУНИЦИРУЕМ.

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

Вот моя статья про коммуникационный план и шаблон такого плана.

Вот нам вводные:

Что нам надо сделать в рамках стейкхолдер-менеджмента на этом проекте при условии, что мы, например, и РМ, и БА?

Давайте определим всех заинтересованных внутри компании:

Кто снаружи компании:

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

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

Давайте посмотрим на заполненный реестр в части ролей, внешнего / внутреннего взаимодействия, матрицы влияния и интереса с ожиданиями:

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

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

Я внесу эти мысли в реестр, а себе, как РМ, запишу задачи:

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

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

Важно: менеджмент стейкхолдеров — не разовая задача. Люди меняют должности, их интерес к проекту может расти или падать, поэтому надо регулярно актуализировать реестр и пересматривать влияние.

Что может измениться в контексте нашего примера?

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

Смекаете?

Вот и я о том же.

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

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

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