Глава 2. Идентификация и анализ стейкхолдеров
Что необходимо руководителю проекта для управления заинтересованными сторонами
Когда речь заходит об управлении заинтересованными лицами в ИТ проекте на бумаге рецепт идеального руководителя (дальше, я буду привычно для среды управления проектами, иногда использовать сокращение «РП») выглядит просто, не сложнее рецепта блинов. Итак, нам потребуется:
Вот и наш идеально прокаченный Руководитель Проекта, который сможет склонить на свою сторону почти любого стейкхолдера.
Понятное дело, в нашем рецепте, почти половина зависит от удачи. А она нет-нет, да и отвернётся даже от самого везучего. Это не наш метод. Поэтому, на самом деле, успех заключается в методичном и последовательном выполнении 4х шагов по работе со стейкхолдерами:
Шаг 1. Выявить
Шаг 2. Классифицировать
Шаг 3. Выработать план на основе классификации
Шаг 4. Постоянная оценка и корректировка планов, инструментов и подходов
И это все на протяжении всего проекта, до самого последнего дня, и иногда даже после. Руководитель должен готовиться погружаться постоянно в этот процесс и держать в голове много дополнительный информации, считывать эмоции, настроения.
Шаг 1. Выявить
На первом шаге – Затрагивая процедуру выявления стейкхолдеров помимо создания поимённого списка, будет необходимо: определить их основные проблемы, просчитать столкновения различных интересов, вычислить различные ограничения и оценить возможности взаимодействия с каждым стейкхолдером.
Прежде чем приступать к идентификации стейкхолдеров ИТ проекта важно визуализировать «Жизненный цикл» самого проекта для участников мозгового штурма. Это сильно поможет команде генерировать мысли и наносить на карту.
Для процесса идентификации попробуйте в команде проекта задать нижеследующие вопросы и записать ответы.
Вопросы для идентификации стейкхолдеров в области «Результат проекта»:
Для кого мы создаём данный продукт? Кто его будет использовать? Кому предстоит его администрировать и эксплуатировать?
Как вы думаете кто может пригодиться вне команды на каждом из этапов проекта.
Что необходимо знать, чтобы выпустить продукт?
Кто-то уже в компании имеет соответствующий опыт?
Кем будут приниматься решения по продукту?
Чье мнение окажется важным и требуется посоветоваться прежде, чем принимать решение.
Кто вне команды будет выполнять действия согласно принятых решений?
Чья активная поддержка имеет существенно значения для успеха проекта?
Для кого проект будет выгоден, а для кого несёт угрозу?
Кого в обществе мы можем потревожить нашей активностью?
Вопросы для идентификации стейкхолдеров в области «Процессы проекта»:
С кем придётся согласовывать методологию работы над проектом?
В чьих руках будут находится финансы, и кто будет согласовывать движение денежных средств в рамках проекта?
В чьих руках будут находится кадровые вопросы команды проекта?
Кто владелец регламентов и положений, в рамках которых будет осуществляться деятельность внутри проекта?
Какие ключевые законодательные акты могут повлиять на достижение целей проекта? С кем надо контактировать и консультироваться что бы не наступили риски?
Кому необходимо будет сдавать отчёты?
На чьи метрики может повлиять проект?
Кто будет принимать итоговый продукт когда проекта закончится?
В рамках проектов очень часто приходится оперировать аббревиатурой «ЛПР»4– Лицо принимающее решение. Это такой человек, который наделен полномочиями в той или иной сфере и несёт прямую ответственность за реализацию и последствия принятого решения. Это не обязательно должен быть руководитель подразделения, им может оказаться лидером или экспертов в определённой области. При этом он должен обязан выдать в команду проекта решение. Ключевое слово «обязан», и от выданной информации порой может зависеть каким будет ИТ продукт. Для ЛПР важна высокая оперативность и к его помощи команда прибегает в случаях недостатка информации для принятия решения или нехватки времени. Таким образом такие ЛПР становятся стейкхолдерами и должны быть идентифицированы.
Реальные и виртуальные стейкхолдера
Большая часть ИТ проектов это про проверку гипотез и конкретных пользователей у продукта ещё может не быть. Если вы создаёте продукт для большого количества пользователей вашего ИТ продукта, руководитель проекта может вводить «виртуального стейкхолдера» – представителя потенциальных пользователей и наделять его определёнными свойствами и желаниями.
В отличие от реального стейкхолдера, у которого есть Фамилия и имя, название организации, чётко понятно, где он сидит и как к нему обратиться, виртуальные живут только в наших головах и документах. Но уже начинают влиять на наш проект или быть подвержены влиянию проекта.
Хорошо, когда его принесут маркетологи или другие стейкхолдеры. Если нет, то такого стейкхолдера команда сочиняет на мозговом штурме по методу «портрет клиента», описывая его пол, возраст, привычки, которые сформируют желания и требования к к итоговому продукту. И на ранней стадии проекта этого виртуального стейкхолдера будет достаточно.
Введение «виртуальных» заинтересованных сторон позволяет детальнее определить степень влияния и способы реагирования на поведение. Если РП работает с «общественностью», тяжело предусмотреть планы и действия для всех возрастных и социальных категорий в этой сущности. А если ввести виртуального стейкхолдера «пожилая женщина, на пенсии, которая выгуливает в парке свою собачку дважды в день и читает книгу на скамейке у входа», то сразу понятны и риски, и маршруты, по которым она может пожаловаться на вас, если вы решили провести ремонтные работы и на неделю убрать скамейки пока монтируете столбы и вешаете камеры для видеонаблюдения. И сразу понятно, как выработать способы противодействия или снижения уровня дискомфорта для такого стейкхолдера.
Еще одним представителем «виртуальных» стейкхолдеров можно назвать волонтёров.
В планах реализации ИТ проектов волонтеры могут оказаться полезными для Альфа- и Бета-тестирование, написания и перевода документации на другой язык, проведения обучения пользователей. Поэтому своевременная идентификация волонтеров как стейкхолдеров поможет спланировать каналы привлечения их в проект, круг задач, которые им необходимо решить, формат взаимодействия и формы отчётности.
Ошибочно, не считаться с волонтёрами как стейкхолдерами. Просто попробуйте оценить какое влияние на план проекта они оказывают если окажутся вовлечёнными в проект. Для работы с волонтёрами потребуется спланировать время и ресурсы внутри команды проекта чтобы:
– предусмотреть необходимое количество учётных записей, доступов и лицензий для ПО, в котором они будут работать и писать отчёты
– заранее подготовить, необходимые формы и отчёты, которые нужно будет заполнять волонтерами
– на непосредственное управление волонтёрами, выдачу им необходимых заданий и координацию
– на анализ качества выполненной работы силами волонтёров.
А ещё Руководитель проекта должен определить канал связи и выстраивать корректное информирование для волонтёров о:
– старте проекта
– сути проекта и его значимости;
– начала и завершении набора волонтёров
– скором привлечение к задаче
– старте этапа с привлечением волонтёров
– роли, которую сыграли в проекте волонтёры
Таким образом бесплатный по статье ФОТ ресурс в виде волонтёров начинает иметь определённое значение в других строках бюджета и календарного расписания проекта.
Следующая информация позволит правильно выбрать на следующем шаге провести классификацию и выбрать стратегию: волонтёры будут обладать минимальной властью, но положительно относится к нашему проекту.
Со временем, в процессе производства ИТ продукта некоторые из виртуальных стейкхолдеров перейдут к реальным представителям, а по некоторым так и останутся в документах и мыслях.
Шаг 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. Постоянная оценка и корректировка планов, инструментов и подходов
При повторении упражнения в новую дату, сначала вносится информация в старый файл – принесли ли желаемый результат действия или нет. После файл сохраняется под новым именем с новой датой и заполняется по новой.
После заполнения файла работа над ним не закончена, Руководитель проекта должен все действия перенести в свой рабочий календарь и стараться выполнять задуманное. В противном случае грош цена такому плану и планированию.