Управление стейкхолдерами. Все дело в нюансах Сергей Барамба
Введение
Дорогой читатель, если ты дошёл до моей книги, скорее всего ты уже знаешь, что такое проект, какие признаки у ИТ проекта и жизненный цикл. У тебя за плечами уже несколько прочитанных книг, пройденных курсов или завершённых проектов. Поэтому я постараюсь в процессе изложения не лить воду и не разжёвывать базовые термины проектного управления.
Основной предпосылкой для написания книги стало то, что большинство руководителей в процессе реализации проекта не уделяют должного внимания заинтересованным сторонам, они же стейкхолдеры. Даже в компаниях с развитой культурой проектного управления работа со стейкхолдерами редко идёт дальше заполнения приложения к уставу проекта «Матрица заинтересованных сторон», и после защиты проекта все что там было забывается. Почему-то основная концентрация усилий происходит на решении ежедневных задач и устранении отклонений. Потом руководители проектов, ближе к итогам удивляются, почему заказчики не довольны.
Я не хочу сказать, что руководители проектов перестают считаться или работать со стейкхолдерами. Вовсе нет, но данная деятельность как правило несёт за собой несистемный, при том порой эмоциональный, характер. Все это в свою очередь приводит к излишним рискам и как следствие – не эффективной работе и лишним коммуникациям для всех.
В целом успех ИТ проекта во много зависит от правильно выстроенных взаимоотношений со стейкхолдерами заказчиком, пользователями, генеральным директором. В конце проекта многие меряют успех проекта через свои критерии – сколько в итоге активных пользователей, сколько обошлось создание этого ИТ продукта, насколько профессионально работала команда и держала в курсе событий.
Приступая к написанию книги, я поставил для себя задачу помочь руководителям проекта систематизировать знания о роли стейкхолдеров, их явном и не явном влиянии на ИТ проекты, узнать о нюансах, и получить чёткие и практические советы, которые можно попробовать прямо тут и сейчас в том проекте, за который ты сегодня отвечаешь.
Приятного чтения, ваш Сергей Барамба.
Глава 1. Кто такие Стейкхолдеры. Немножко терминологии и теории.
Термин стейкхолдер
В основе данного термина лежит английское слово – “Stakeholder”, буквально – «владелец доли». Оксфордский словарь даёт нам такое определение – человек, который интересуется или беспокоиться о чем-нибудь, особенно в бизнесе. Термин на русский язык можно перевести, как «заинтересованная сторона». Состоит из слияния двух слов
1) stake – может иметь несколько значений перевода на русский:
– доля (в компании)
– что-то, что ставится на кон ради прибыли или убытка
– находиться под угрозой
– заостренный кусок дерева или другого материала, вбитый в землю в качестве маркера или опоры
2) holder – хранитель, держатель.
История первого использование этого термина уносит нас в эпоху колонизации Америки. Во время экспансии на Запад европейские поселенцы буквально «застолбили» (“stakes”) себе землю, чтобы заявить о своих правах собственности, вытеснив коренных жителей, которые изначально там жили. В документах о таких поселенцах описывали словом «стейкхолдеры».
Существует версия что возникновение современного значения слова «стейкхолдер» связано с азартными играми. Так потом называли человека, принимающего ставки и хранящего у себя до объявления победителя.
Считается, что современная история концепции заинтересованных сторон началась с монографии Р. Э. Фримена «Стратегическое управление: роль заинтересованных сторон», изданной в 1984 г1.
Для проектного управления под словом «стейкхолдер» понимают лицо, группу или организацию, которая может влиять, на которую могут повлиять или которая может воспринимать себя подвергнутой влиянию решения, операции или результата проекта2.
А управление стейкхолдерами (Stakeholdersmanagement) – Описывает процессы и методы, необходимые для определения заинтересованных сторон проекта и управления взаимодействием между ними и проектной командой.
Как правило, работая со стейкхолдерами руководители проектов концентрируют усилия на трёх группах:
– Кто активно вовлечен в проект и работает в нем (спонсор проекта, проектная команда, спонсор, управляющий комитет, привлеченные сторонние компании и другие исполнители и т.д.)
– На чьи интересы может повлиять проект, и кто будет пользоваться его результатами (заказчики, руководители функциональных подразделений и их сотрудники, специалисты, которые работают непосредственно с клиентами и понимают их нужды, бизнес-партнеры, клиенты, покупатели и т.д.)
– Кто в проект не вовлечен, но кто, в силу своего положения или профессиональной деятельности, может на него влиять (топ-менеджеры компании, владельцы и инвесторы, акционеры, кредиторы, внешние и внутренние партнеры, регулирующие государственные органы, общественность и т.д.)
Влияние на проект со стороны заинтересованных сторон может быть позитивным: инсайты, бюджеты, поддержка и лоббирование интересов, предоставление ресурсов, выполнение сервисной или экспертной функции. А также может выражаться в негативном ключе – внесение лишней работы, затормаживание процессов, сокрытие информации, конфликты, сокращение расходов, жалобы и создание сложностей в работе, требовании соблюдения правил и законов.
На основе влияния можно потом выстроить векторы воздействия: Эмоциональный и Рациональный.
Эмоциональный вектор, оценивает как стейкхолдеры относятся к проекту и какой эффект ожидают от проекта на субъективном уровне, и создать положительное представление – это будет ваше «завоевание сердец».
Рациональный вектор позволяет изменить установки насколько стейкхолдеры уверены в том, что выполняемая работа и результаты проекта являются правильными, этот путь называется «завоеванию умов».
В большинстве случаев справедливым считается формула «Дай стейкхолдерам то, что нужно им. А они дадут то, что нужно тебе в замен». Если это делать спонтанно, без плана – скорее всего руководителя ждёт провал, для успеха нужно выстраивать плановый и системный взаимообмен.
Часто я слышу, что заказчик и стейкхолдер – синонимы, и если выстроить работу с заказчиком, то дело сделано. Как мы увидели выше – заинтересованные стороны, те кого проект или продукт так или иначе затрагивает. Сюда же относятся и те, кого проект не затрагивает, но они могут повлиять или подвержены влиянию. Но Заказчики – это те, кто формируют основную задачу для создания продукта или начала проекта. Отсюда можно сделать вывод что заказчики являются частью сущности стейкхолдеры. Но не стоит забывать спонсоров, конечных пользователей ИТ продукта, клиентов.
Стейкхолдеры в «Результат проекта» и в «Процессы проекта».
Если на стейкхолдеров взглянуть с другого ракурса – их можно типизировать на тех, у кого зона интересов связана с результатами проекта – т.е. ИТ продуктом – пользователи и заказчики, и тех, кого больше волнуют процессы протекающие в проекте – предоставление отчётности, достижение метрик, соблюдение требований законодательства и внутренней документации в компании, выдерживание рамок бюджета. Это кураторы и руководители подразделений, сотрудники финансовой службы или отдела кадров. Понимая такую типизацию, руководитель проекта сможет на шаге выявления стейкхолдеров задавать правильные вопросы, а это в свою очередь поможет выявить как можно больше стейкхолдеров.
Уровень взаимодействия, частота, канал в коммуникации будут резко зависеть от того, к какой отдельной группе или двум группам сразу будет относится наше заинтересованное лицо. Об это мы поговорим ниже.
Обзор процессов работы со стейкхолдерами по PMBOK версии 6.
Рассказ о методологиях работы со стейкхолдерами был бы неполным, если не затронуть насколько детально расписаны процессы, в пусть уже считающейся устаревшей после выхода в свет версии 7, но всё-таки все ещё актуальной PMBOK 6.
В книге описывается 4 процесса:
Как и все другие процессы в PMBOK – все описано очень теоретически, и не даёт ответов как именно с практической точки зрения все вышеуказанное реализовать руководителю проекта. Главная польза для руководителя проекта от изучения описания процессов в книге – понимание последовательности выполнения процессов один за другим и то, что «Мониторинг вовлечения стейкхолдеров» осуществлять в течении всего проекта.
После старта проекта первая активность, когда команда проекта взаимодействует со стейкхолдерами – это сбор требований. В этом процессе происходит документирование потребностей заинтересованных сторон для достижения заявленных целей проекта.
Что нам говорит Scrum про работу со стейкхолдерами
В Scrum Guide от ноября 2020 года слово Стейкхолдер встречает 13 раз, при этом само определение термина не приводится. Поэтому, мне кажется, уместным будет пользоваться общепринятым определением, которое приводилось выше. Так же Scrum Guide оперирует ещё термином ключевые стейкхолдеры (key stakeholders), и тоже без расшифровки определения. Логично нам предположить, что это какие более важные стейкхолдеры, чем обычные, без приставки «ключевые».
Основная роль управления стейкхолдерами возлагается на Владельца продукта (Product Owner), который должен перекладывать выявленные потребности от всех стейкхолдеров внутрь артефакта под названием Беклог Продукта (Product Backlog). Он должен хорошо знать в лицо стейкхолдеров, каждый день с ними взаимодействовать, как требует 4 принцип Agile – «На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе»
