Стейкхолдеры: казнить нельзя помиловать

02.06.17

Управление проектом

Представьте, что в управлении проектами есть такой же инструмент, как SQL-профайлер. Когда на проекте наступает большая проблема, мы подключаем к нему всех участников, и он нам показывает, кто самый медленный, кто кого ждет, кто давно ушел в глубокий дедлок. Было бы круто, но пока таких инструментов нет. Какими моделями и методами управления в таком случае пользоваться, будет рассказано в статье.

Факторы успешности проекта

 

 

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

 

 

 

 

 

 

По некоторым оценкам, количество заваленных проектов в последние 10 лет составляет примерно 25%, то есть четверть. Иногда этот показатель составляет 19%, а потом снова поднимается. Но как видно из картинки, успешность проектов, в первую очередь, зависит от эффективной коммуникации со всеми стейкхолдерами и вовлеченности всех стейкхолдеров в ход проекта.
 
Некоторые считают, что наиболее важными на проекте являются риски, оценка сроков и бюджета. Именно эти темы чаще всего обсуждаются на конференциях по правлению проектами. Но мое мнение, что все эти факторы вторичны. Риски, сроки и даже стоимости проекта: влияние на эти факторы оказывают стейкхолдеры. Поэтому эта тема очень важна.

Показательная история о влиянии на проект

 

 

Я начал заниматься темой управления проектами и стейкхолдерами, потому что набил, действительно, много реальных шишек на своих собственных проектах.  Историй много, но одна из них наиболее показательная.
 
12 лет назад я руководил одним проектом и уже понимал, что главное – это вовлеченность руководства предприятия, получение результатов, основанных на удовлетворенности этого высшего руководства. Как руководитель проекта, я запланировал и проводил периодически совещания с руководством заказчика – раз в две недели/месяц. Сначала я заметил, что когда рассказываю о ходе проекта, руководитель смотрит на меня с хитрым прищуром, как один из тех людей, которые знают, что ничего не получится. Еще через несколько встреч я вижу, что у директора появилось какое-то недовольство, хотя проект шел, как надо. Я поделился с айтишником предприятия, объяснил, что пытаюсь вовлечь руководство в процесс, но директор «не вовлекается». В ответ он рассказал, что дочка директора работает в одном из подразделений компании, и она против внедрения этого проекта, поскольку с ней ничего не обсуждалось, и она в процесс никак не вовлечена. В итоге мнение руководителя формируется не на том, что ему рассказывает управляющий проектом, а на том, что ему дочка рассказывает.
 
Вот такие моменты подтолкнули меня полностью погрузиться в тему работы со стейкхолдерами – кто именно и как может влиять на успешность проекта в целом.
 
Отдельно отмечу, что изложенная в докладе информация (особенно все, что касается не теории, а практики) в большей степени мое личное и субъективное отношение к проблеме. С ним можно соглашаться или не соглашаться. Но субъективизм мой основан на большом количестве проектов, которые я осуществил, в качестве инженера-программиста, руководителя проекта, руководителя программы проекта, а также на опыте взаимодействия с людьми в этих проектах и в качестве бизнес-тренера. У меня есть сертификат Института управления проектами (Project Management Institute, PMI), и я сертифицированный профессионал в управлении проектами (Project Management Professional, PMP), что является признанным отраслевым сертификатом для руководителей проектов. Я преподаю, веду занятия для разных групп людей, и, собственно, в том числе исходя и из их видения, сформировал какое-то свое отношение, базирующееся, конечно же, на общемировом своде знаний об управлении проектами PMBoK.

 

Немного теории об управлении заинтересованными сторонами в проекте

Существует 4 основных процесса, связанных с заинтересованными сторонами:
 
1.      Их надо определить, т.е. найти, кто в проекте является заинтересованной стороной.
 
2.      Спланировать, как с ними работать, какие действия предпринимать, чтобы вовлечь заинтересованные стороны в проект.
 
3.      Воплотить план в жизнь, управлять заинтересованными сторонами или, правильнее сказать,  управлять для заинтересованных сторон.
 
4.      Контролировать этот процесс, (т.е. все, что делается в рамках проекта).

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

Все инструменты в рамках группы процессов управления заинтересованными сторонами я называю инструментами «бла-бла-бла». Потому что совещания, экспертная оценка, анализ и некоторые другие инструменты – все они основаны на коммуникациях и умении руководителя проекта коммуницировать. В отличие от управления расписанием, где есть методы построения сетевых диаграмм, в отличие от метода оценки стоимости, где есть правила оценки по функциональным точкам и другие специальные инструменты, здесь все такое... «поговорить, подумать, обсудить». Один из важнейших инструментов – это анализ заинтересованных сторон: группы, организации, непосредственно люди (персоналии), которые оказывают влияние на проект и на которых проект оказывает влияние. Понятно, что Мы не сможем управлять абсолютно всеми этими заинтересованными сторонами, особенно если у нас большой проект. У нас по 200-500 рабочих мест в 1С – каждый пользователь является заинтересованным лицом в терминологии PMI, но это не значит, что надо с каждым работать. В этом случае один из инструментов, который помогает руководителю проекта, – это матрица.

 

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

Следующий этап – то, что запланировано, выполнить. Задача руководителя проекта – опять, вспоминайте,  - да «бла-бла-бла». Иногда  думают, что задача руководителя проекта – спланировать, разработать план управления проектами, сдать его заказчику, и дальше он и не нужен. Но на самом деле руководитель проекта нужен, чтобы все запланированное воплощать в жизнь, контролировать и напоминать, чтобы все выполнялось.

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

Теперь вы знаете, в чем заключается управление заинтересованными сторонами с точки зрения свода знаний PMI.

От теории к практике

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

Как выявлять заинтересованные стороны? Самый худший способ выявить заинтересованную сторону – это предлагать заполнить анкеты заказчикам, в которой они должны сами написать, кто является заинтересованными сторонами в проекте. На 30% оно, возможно, и совпадет, но остальное – мусор. Потому что, скорее всего, эту анкету будет заполнять айтишник, который включит сюда все руководство предприятия, без оглядки на содержание проекта, применимость его результатов, окружение проекта как таковое.
 
Поэтому выполнять этот процесс вам надо самостоятельно с вашими людьми. Начинать делать это нужно еще до старта проекта, когда вы приходите на обследование перед проектом. Те люди, которые общаются с заказчиком, изучают потребности заказчика, - это достаточно большой кладезь информации для вас, как руководителя проекта. Поговорите с ними, обсудите результаты предварительного обследования не только с точки зрения функциональности системы, но и с точки зрения окружения проекта в целом. Они расскажут, что в каком отделе кто-то уже собирается идти на пенсию, кто-то в декретный отпуск, кто-то точно является явным противником проекта. Вся эта информация, полученная в результате экспресс-исследований, должна быть вами зафиксирована. Потому что, когда начнется уже непосредственно проект, это очень поможет.
 
И умейте правильно задавать вопросы. Что это значит? Иногда мне говорят, что самый правильный вопрос звучит так: «Когда у нас наступит большая проблема во взаимоотношениях с заказчиком, кто будет разруливать их?». Вопрос может быть и правильный, но начинать с него некорректно. У заказчика сразу перевернется сознание того, что вы хотите именно создать проблемы на проекте, а не успешно его реализовать. Правильный вопрос – это вопрос, который касается выяснения проблемы. Мне больше всего нравится вопрос с точки зрения оценки эффективности проекта.
 
У Пола Страссмана есть теория, согласно которой все те профиты, все те плюсы, которые предоставляет ИТ-система в процессе ее использования, должны быть превращены в пользу для организации конкретными ответственными за них людьми. То есть человек должен отвечать за то, как он использует функциональные возможности, которые дает нам система, чтобы превратить их в прибыль для организации. Говоря простым языком, если мы поставили систему, которая позволяет экономить большое количество времени кладовщиков, комплектовщиков, службы отгрузки, то должен быть человек, который должен продумать, куда задействовать этот персонал, как это будет работать в рамках реструктуризации компании. А не так, что мы внедрили систему, люди экономят время, но в это время чай пьют или в компьютере играют.
 
Задавая такие вопросы, мы сможем понять, кто у нас будет заинтересованным лицом в проекте, причем, часто их бывает два: один – руководитель, который в данной функциональной области хорошо себя зарекомендовал как эксперт, а второй – это его помощник, который собственно будет думать вместе с руководителем и  апробировать какие-то решения.
 
Очень помогает определять заинтересованные стороны простое рисование на бумаге. Есть такое понятие, как «стейкхолдер  maps», когда мы рисуем паутинку от одного до второго, затем до третьего, четвертого и т.д., в том числе влияние друг на друга. Это нелинейная таблица, а именно взаимодействие стейкхолдеров внутри организации.

 

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

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

 

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

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

Вторая мысль основана на понимании удовлетворенности. Какая математическая формула удовлетворенности?  Результат/ожидание. Чем больше у нас ожидания и меньше результат, тем меньше у нас коэффициент удовлетворенности. Я не призываю, конечно, с первой же встречи пугать заказчика, что в проекте все будет плохо. Но нужно исходить из того, что проект будут оценивать, исходя из коэффициента удовлетворенности. И это и ваша личная оценка, как руководителя. Насколько широки ожидания заказчика, а эти ожидания часто представлены в такой форме, можно посмотреть на картинке. Кроме того, у заказчика и исполнителя всегда абсолютно разные ожидания.

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


Как известно, вначале все пребывают в эйфории. Но только мы начинаем реализовывать проект, заказчик начинает понимать, что ему тоже надо работать. И началось…техзадание (ТЗ), рабочее проектирование (РП), опытный эксперимент (ОЭ), эксплуатация. Наша задача, как руководителей и исполнителей проекта, – не дать проекту просто упасть в «яму», которая возможна практически на всех проектах, не дать ему упасть до нуля. Когда проект опустится до нуля, это значит, что он  завершился очень неудачно.
 
Поделюсь еще несколькими мыслями – о типовых шаблонных ошибках, которые я встречаю в действиях исполнителей в каждом проекте. Во-первых, мы все считаем заказчиков тупыми.

И это нормально. Только поймите, что они тупые только с вашей точки зрения, поскольку не владеют всеми теми техниками и технологиями, которыми владеете вы. Поэтому с точки зрения понимания хода проекта и результатов процесса, заказчик, действительно, тупой. Но это не значит, что он тупой как таковой. Можно сказать, что надо учиться, но никого нельзя обзывать тупым. Я специально провожу беседы с командой перед началом проекта, и всегда об этом напоминаю. Даже памятка специальная разработана – памятка поведения в проектах. Не надо заказчиков называть тупыми, помогите им стать умными.
 
Второй паттерн – это проектная дружба. Конечно, выполнение общих обязанностей и сотрудничество в  должно иметь место, но не дружба.. При этом если речь идет о глубоких взаимоотношениях (вместе отмечают праздники, крестят детей), то в таком случае такая дружба всегда приводит к последствиям и проблемам в проекте, когда личные отношения сильно переплетены с профессиональными.

У меня есть только один успешный пример. У меня был коллега – он пришел на один проект, познакомился с девушкой, женился успешно, потом проект закончился, они развелись. Пришел на второй проект, снова познакомился, снова женился… Пока живут. Но деловым отношениям не надо скатываться в дружбу.
 
Третье. Не нужно перегибов, не нужно падать ниц перед заказчиком. Должны быть взаимные отношения: мы ему пользу приносим, он нам за это платит. Поэтому мы должны ожидать и строить партнерские отношения, а не отношения «хозяин и слуга». В то же время не надо давать пинка, мол, я лучше тебя знаю, что тут надо сделать. «Поскольку я строю вам систему, вы тут букашки» – так тоже нельзя.

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

 

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2016 DEVELOPER.

 

30 мая - 1 июня 2024 года состоится конференция Анализ & Управление в ИТ-проектах, на которой прозвучит 130+ докладов.

Темы конференции:

  • Программная инженерия.
  • Инструментарий аналитика.
  • Решения 1С: архитектура, учет и кейсы автоматизации на 1С.
  • Управление проектом.
  • Управление продуктом.
  • Soft skills, управление командой проекта.

Конференция для аналитиков и руководителей проектов, а также других специалистов из мира 1С, которые занимаются системным и бизнес-анализом, работают с требованиями, управляют проектами и продуктами!

Подробнее о конференции.

 


См. также

10 типовых рисков срывов проекта. Памятка для внедренцев и заказчиков

Кейсы проектов Бесплатно (free)

Как определить, что риск проекта высок настолько, что взяться за него – в 99% случаев значит потерять драгоценное время, деньги и другие ресурсы? Как еще до старта определить, что проект в лучшем случае на выходе станет пародией на задуманное, а в худшем – будет сорван? Сформулируем список типовых рисков срывов проекта и постараемся уберечь от ошибок внедренцев и заказчиков.

20.12.2023    2778    0    1СERP    21    

31

Внедрение крупного проекта на ERP 2.5 с применением методических решений из УПП 1.3 и обеспечением товаров с разных складов с учетом серий

Кейсы проектов Платформа 1С v8.3 1С:ERP Управление предприятием 2 Оптовая торговля, дистрибуция, логистика Россия Бесплатно (free)

В 2021 году начали проект в дистрибьюторской компании. Имели большой опыт внедрения УПП, но периодически возникали вопросы. Зачем что-то придумали в ERP, что стало менее удобнее, чем было в УПП? Почему нельзя было взять лучшие идеи из УПП и ERP и скрестить их? А идея, что обеспечение нужно выносить из заказов, с каждым новым проектом находила все большее подтверждение. В итоге на этом проекте удалось применить лучшие (на мой взгляд) методические решения, которые мне довелось внедрять в конфигурациях УПП и ERP, в т.ч. подход, что реагировать нужно только на важное (то, как на заре появления ERP Фирма 1С ее позиционировала).

05.07.2023    14308    0    ASchekachev    37    

55

Организация работы внутренней команды 1С с помощью Канбан

Канбан и поставка ценности Бесплатно (free)

Когда ИТ-отдел разрывается между разнотипными задачами от внутренних заказчиков, стоит посмотреть в сторону гибких подходов. О том, как, используя три практики Канбана – WiP-лимит, визуализация и распределение по сервисам – улучшить отношения с заказчиками, не бояться давать обещания по срокам и укладываться в них, на конференции Infostart Event 2021 Moscow Premiere рассказал руководитель направления 1С в компании UTG Станислав Алексенко.

28.06.2023    5854    0    stnslv    5    

25

Технология проекта внедрения 1С:ERP – как управлять большим проектом

Управление проектом Команда Платформа 1С v8.3 1С:ERP Управление предприятием 2 1С:Управление холдингом Бесплатно (free)

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

10.02.2023    4704    0    andironenko    2    

31

На что похож ваш продукт: на Аквариум или на Муравейник? 

Инструменты управления проектом Бесплатно (free)

Давайте поиграем в метафоры в лучших традициях экстремального программирования. А заодно проведем новогодний конкурс - на лучшую метафору для автоматизированного продукта

27.12.2022    2750    0    MariaTemchina    28    

23

ТРИЗ. Решение нерешаемых проблем в бизнесе

Управление проектом Бесплатно (free)

Советскую теорию решения изобретательских задач давно применяют крупнейшие мировые корпорации, причем не только в технологической области, но и в сфере бизнеса. На конференции Infostart Event 2021 Post-Apocalypse основатель бизнес-клуба ТРИЗ Алексей Благих рассказал, как с помощью ТРИЗ решать нерешаемые задачи, и почему метод проб и ошибок здесь не поможет.

09.11.2022    4188    0    user1576201    10    

17

Я - ЗУПер! Часть 1. Компетенции сотрудников.

Бизнес-анализ Управление проектом Команда Управление ИТ Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Цикл статей о том, почему акушер-сантехник широкого профиля - это ПЛОХО. Расскажу плюсы специализации на одной предметной области. Рассмотрим понятные аналогии из других областей. Проанализируем пару вакансий, естественно без указания компании.

09.09.2022    10678    0    biimmap    79    

75

Как донести здравый смысл до заказчика. Инструменты архитектора

Управление проектом Архитектура Бесплатно (free)

Андрей Овсянкин на конференции Infostart Event 2021 Post-Apocalypse поделился инструментами, которые помогают ему обрабатывать большой поток задач и экономить недели на обсуждении проекта. Он рассказал, как искать ошибки в процессах, какие диаграммы полезны при общении с заказчиком и с помощью каких инструментов можно быстро рисовать наглядные картинки вместо долгих разговоров.

05.08.2022    13095    0    Evil Beaver    17    

117
Комментарии
В избранное Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
1. dimpson 20 02.06.17 18:44 Сейчас в теме
Спасибо!
Не то, чтобы открыта Америка (в свете текущих событий, может и зря ее открыли-то), но систематизировано красиво!
В управлении тоже для себя давно понял - главное качество РП - это все же коммуникабельность. Как бы иногда не было лень или напряжно - лучше лишний раз позвонить, написать, чем проигнорировать или сделать паузу в отношениях с заказчиком.
Кстати, думаю, выстроенные коммуникации должны быть не только у РП, но и у всех вовлеченных сотрудников, общающихся с заказчиком.
Если заказчика не устраивает твой консультант и не получается это исправить, хоть он семи пядей во лбу - лучше такого консультанта отправить в бэкенд, чем через него получать негатив на проект (это, конечно, во многом зависит от обстоятельств, но чаще всего так).
kirinalex; +1 Ответить
8. kirinalex 15 27.06.21 17:51 Сейчас в теме
(1) да, хорошая системная подача
автору спасибо
2. d4rkmesa 07.06.17 19:12 Сейчас в теме
Интересно, чем закончилась ситуация с дочкой директора? Ситуация как то разрешилась или тупик? Чем вообще можно занять подобных неквалифицированных кураторов? Я не РП, примеряя на себя, сложно сказать, как бы я среагировал, если бы условная "дочка директора" изъявила желание чем-то заниматься:
"...Чтоб служила мне рыбка золотая
И была б у меня на посылках".
3. monkbest 115 08.06.17 08:11 Сейчас в теме
Стейкхолдеры - это те кто держат решетку с мясом над мангалом?

steak - бифштекс, стейк, отбивная
holder - держатель, кронштейн, фиксатор

стек и стейк - разные вещи :)
корум; +1 Ответить
6. vbirin 21 14.06.17 10:49 Сейчас в теме
(3)
Стейкхолдеры


Антон, добрый день.

Ни в коем случае не буду с Вами спорить по поводу того, как нужно переводить данное определение. Но, в настоящий момент "Стейкхолдер" - это общепринятая трактовка. См., например, ВикипедиЯ.
7. monkbest 115 15.06.17 12:31 Сейчас в теме
(6) ай, тот кто переводил PMBok на русский был гнусный лентяй. В управлении проектом подойдет термин "заинтересованная сторона", а буквально - "Владелец доли" - вполне всем понятные русские слова, не требующие читать их определение в википедии.

Любая наука обрастает терминами, чтобы сначала обучить людей терминам, а потом на этих терминах объяснить суть в более короткой форме. Но когда терминов становится больше чем сути... прям агррр да и только :)

А вообще, прошу прощенья за миллитроллинг
4. UR1 97 09.06.17 12:02 Сейчас в теме
Спасибо за статью! Но хотелось бы больше примеров из практики. И тоже интересно - чем закончилось с дочкой руководителя?.
5. vbirin 21 14.06.17 10:45 Сейчас в теме
Коллеги, добрый день.

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