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