👨‍💼 Управление стейкхолдерами | Stakeholder Circle: визуализация вместо матриц

Продолжаю исследовать тему имеющихся подходов и практик анализа стейкхолдеров. Сегодня про методологию Stakeholder Circle.

Подход разработан в начале 2000-х австралийским исследователем Линдой Борн в рамках докторской диссертации. Борн первой в мире защитила Doctor of Project Management и создала инструмент, который превратил анализ стейкхолдеров из таблиц в визуальную диаграмму.

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

Методология состоит из пяти шагов:
🔘Идентификация (кто стейкхолдеры, их ожидания и потребности)
🔘Приоритизация (оценка по трем параметрам: власть, близость, срочность)
🔘Визуализация (топ-15 стейкхолдеров)
🔘Вовлечение (стратегия коммуникации на основе отношения к проекту)
🔘Мониторинг (отслеживание изменений во времени)

Оценивается три ключевых параметра

1️⃣ Власть (Power): способность влиять на проект

2️⃣ Близость (Proximity): насколько близко к проекту (вовлечен в команду, руководит сверху, внешний участник)

3️⃣ Срочность (Urgency): насколько быстро нужно реагировать на требования

Комбинация дает индекс важности. Чем выше индекс, тем больше сегмент на диаграмме.

Главное отличие от других методов - визуализация на радиальной диаграмме. Размер сегмента показывает влияние стейкхолдера, цвет - категорию:
🔘Оранжевый (топ-менеджмент, спонсоры)
🔘Синий (внешние: клиенты, регуляторы, поставщики)
🔘Зеленый (команда проекта)
🔘Фиолетовый (коллеги уровня РП)

Дополнительно оценивается отношение (attitude): поддерживает/нейтрален/сопротивляется. Это определяет стратегию коммуникации.

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

Интересно, кому-то приходилось использовать такой метод? Поделитесь опытом и мыслями в комментариях👇

#пропроекты #pmoclub #развитие

И такое бывает 😉

#немногоюмора

Обычно рассказываю о чем-то, что уже случилось. Пока идет подготовка или нет готового результата, предпочитаю не говорить.

При этом не то, чтобы боюсь сглазить, как мне кажется, но кто знает на самом деле 🤔

Поэтому какое-то время думал, писать или нет. Но в итоге решил, что уже можно рассказать, поскольку все на финальной стадии.

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

Сборник посвящен теме ‘Команда’. Моя статья раскрывает вопросы управления гибридными командами людей и агентов. В ней я агрегировал накопленные знания по этому поводу и взгляд на проблематику изменения подходов к управлению со стороны проектного офиса.

Надеюсь, опыт окажется удачным. Ждите дальнейшие анонсы 😎

MAX | LinkedIn

#развитие

⚠️ Ошибки PMO | Что у нас по рискам?

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

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

PMO проверяет наличие реестра при инициации проекта. Галочка стоит, значит, всё в порядке.

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

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

❓ В чём здесь ошибка?

Версии в опросе ниже 👇

#ошибкаPMO #pmoclub

⚠️ Ошибки PMO | Разбор кейса по рискам

Всем спасибо за активное голосование. В этот раз выбор практически единогласный.

И, да, правильный ответ: 1. Управление рисками превратилось в формальность

Реестр рисков не просто документ, это инструмент управления. Разница между ними принципиальная.

Документ пишут один раз и сдают в архив проекта. Инструмент используют постоянно: обновляют, пересматривают, принимают на его основе решения. Когда реестр рисков становится документом, управление рисками исчезает и остаётся только его видимость.

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

Вариант 4 про эскалацию частично верный, но вторичный. Эскалировать нужно, когда риск достигает определённого порога. Но эскалация работает только, если риск вообще отслеживается. В описанной ситуации его просто никто не смотрел на регулярной основе.

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

Как исправить
🔘Включить пересмотр реестра рисков в повестку регулярных статус-митингов как часть стандартного ритма проекта.
🔘Ввести правило: риск без актуального статуса и даты последнего обновления считается неуправляемым. PMO проверяет не наличие реестра, а его актуальность.
🔘Ответственным за риск должен быть конкретный человек, не функция или роль. При смене членов команды передача рисков обязательна.
🔘Новые риски фиксируются в реестре в момент выявления, а не по итогам квартала.

В общем, риск, который никто не смотрит, это неуправляемый риск. Он становится миной замедленного действия.

#ошибкаPMO #pmoclub

Не самый плохой компромисс с учетом текущего рынка 😉

#немногоюмора