Управление взаимоотношениями с ключевыми участниками проекта

13.02.19

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

Руководителю проекта необходимо не только знать в лицо ключевых участников, но и уметь наладить с ними хорошие взаимоотношения. На что следует обратить внимание, чтобы расположить к себе спонсора и заказчика, рассказал главный редактор журнала «Управление проектами» Олег Тумасов.

Справка

Олег Тумасов, инициатор, создатель и главный редактор журнала «Управление Проектами». Имеет опыт управления крупными, территориально распределенными проектами и программами – более 15 лет, как на стороне заказчика, так и на стороне генерального подрядчика и конечного исполнителя. Руководил проектами в банковской сфере, в телеком индустрии, в области разработки и внедрения программного обеспечения, управленческом консалтинге.

Введение

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

Все мое изложение будет от лица PM (Project Manager): то есть я разберу связи не всех участников со всеми, а условно говоря, один ко многим, и расскажу, как Руководителю проекта взаимодействовать с командой, заказчиком и спонсором.

Ключевые участники: кто они?

На слайде вы видите четырех основных Стейкхолдеров.

Что нам важно понимать обо всех этих людях? Руководитель проекта - он счастлив, у него есть новый проект, есть новая интересная работа, которая его увлекает.

Заказчик. Ему, в принципе, нужен не столько наш проект, сколько те выгоды, которые он получит от реализации этого проекта. У грамотного заказчика должно быть 2-3 варианта получения этих выгод. Проект, который достается нам в управление, это всего лишь один из возможных вариантов получения этих выгод. Это надо понимать, когда мы взаимодействуем с ним.

Спонсор – это наш проводник в мир проекта. Тот человек, который объясняет нам ограничения проекта, а его связи с бизнес-процессами компании – то есть, фактически, связи с бизнесом нашего проекта.

Команда проекта – это те люди, которые нам нужны для реализации проекта, потому что большие дела в одиночку не делаются. И важно понимать, что для реализации проекта нам нужна сплоченная мотивированная команда.

Важное замечание

Прежде, чем говорить о конкретных взаимодействиях, я бы хотел сделать небольшое «лирическое отступление». Любое взаимоотношение мы реализуем в форме сделки и договоренности. Приведу несколько гигиенических факторов, которые я считаю необходимыми для эффективной работы руководителя.

Первый фактор – это открытость и честность с партнерами. И я даже не знаю, что важнее – открытость или честность. Любой проект – это всегда что-то новое. Открытость позволяет нам получать поддержку. Если мы открыты, то поддержка придет даже в трудный момент.

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

 

 

При этом важно быть принципиальным или гибким? Что я имею в виду?  Поскольку конференция в большей степени посвящена гибким методологиям, то оговорюсь, здесь слово «гибкий» – это не отсылка к гибким методологиям, это отсылка к вашей личной гибкости, насколько вы готовы отстаивать свою позицию и насколько вы готовы идти на уступки. Очень интересный момент: чтобы идти на уступки, у вас обязательно должна быть своя собственная позиция. Прежде, чем идти на уступки, и прежде, чем о чем-то договариваться, нужно определиться со своей позицией. У вас должны быть некоторые руководящие принципы. Например, у меня больше 15 лет назад сформировался один такой принцип. Я его выработал буквально на первом своем проекте. Проект был внутренний, я работал тогда в большой финансовой организации, функционально устроенной, в которой у меня была роль руководителя проекта, а не должность. Этот принцип очень простой: у меня уже есть все, что нужно для того, чтобы делать то, что я считаю правильным.  

Важно понимать, что принципы должны быть достаточно общими. Они позволяют вам договариваться, но при этом двигаться вперед.

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

 

 

Взаимодействие со спонсором

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

На старте проекта нужно договориться, выяснить у спонсора:  

  1. Продукт проекта;

  2. Цель проекта;

  3. Ограничения;

  4. Допущения. Я недавно в ходе общения с одним из клиентов с удивлением обнаружил, что понятие «допущение» вызывает у клиента непонимание. Достаточно трудно было объяснить клиенту это понятие, поскольку для меня оно было достаточно очевидным. Но для клиента этот вопрос оказался достаточно трудным. Итак, допущение – это то, что является действительным на старте, когда мы принимаем решение о проекте. Ведь любое решение принимается на основе определенных допущений, определенных рамок. Почему это важно учитывать? Проект все-таки длится не один день, не две недели, не месяц, бывает что год или два, если он крупный. Важно понимать, что решения, которые были приняты на стадии открытия проекта, были приняты в условиях определенных ограничений и допущений. И если эти ограничения и допущения сейчас недействительны, то нельзя просто сказать, что решение об открытии проекта было неправильным, просто оно было обусловлено определенными факторами;

  5. Нужно также понять в целом заказ – состав работ и состав поставки. В принципе, этого понимания спонсор ожидает от вас, это то, зачем вы нужны спонсору. Потому что спонсор часто понимает, что он хочет получить в более общем виде, но ждет понимания деталей от вас. На самом деле вдумчивый спонсор на этапе взаимодействия часто проверяет PM-а. Может ли он этот пункт адекватно воспринять и объяснить, для спонсора это важно, ведь на старте проекта легче поменять PM-а. В свою очередь для PM-а этап первичных договоренностей также очень важен. Не нужно «брать под козырек» и бежать реализовывать проект. Если вам что-то непонятно, это самый лучший момент взять паузу. Не на месяц, естественно. Пауза зависит от объема реализации проекта: например, если предполагаемая длительность проекта два месяца, абсолютно нормально, если вы возьмете паузу на несколько часов, подумаете до вечера, и более детально все себе представите. Но опять же, это все зависит от культуры организации. Если у вас культура приказная, то, возможно, вам такой роскоши не предоставят. Если культура открытая, демократичная, спонсор абсолютно нормально и даже положительно отнесется, если вы придете чуть позже с более взвешенным решением и с пониманием состава работ, состава поставки;

  6. Важно выяснить, как видятся риски этого проекта спонсору, и отличается ли это от вашего понимания рисков.

  7. Когда мы говорим о рисках, хорошо бы сразу договориться о зонах ответственности. При этом во внутренних проектах, часто роли спонсора и заказчика совмещает один человек. Важно понимать, какие риски на вашей стороне, какие – на его стороне;

  8. Конечно же, бюджет и сроки реализации проекта – это классика.

  9. И последнее, все эти пункты желательно зафиксировать, обычно это делается в форме устава проекта, либо любого другого документа, например, паспорта проекта.

 

 


На что необходимо обратить внимание

Обязательно нужно выяснить, есть ли у вас различия в понимании или трактовке каких-либо аспектов проекта. Этот момент очень важен.

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

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

 

 

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

Кроме того, важно держать спонсора и заказчика в тонусе. Что это означает? Интерес спонсора и заказчика к проекту не линейный: он максимальный на старте, потом есть некоторый провал, когда спонсор и заказчик могут даже не появляться, если вы не будете им давать новую информацию, или появляться в совершенно неожиданный для вас момент.  Чтобы этого не происходило, наладьте регулярное взаимодействие. При этом не нужно успокаивать спонсора и не нужно давать ему каждый раз одну и ту же информацию, например, все в порядке, сроки соблюдаем. Потому что руководители верхнего уровня не любят такую информацию. Казалось бы, от PM-а ожидают, что он взял проект, ведет его, и по готовности показывает зеленый флажок. Это не так. Действуя подобным образом, вы рискуете пропустить важный момент - момент изменения понимания проекта у заказчика или спонсора. Поэтому обязательно обмениваясь информацией, поддерживая один и тот же уровень детализации, чтобы таким образом поддержать преемственность.

 

Несколько слов о рисках

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

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

 

Что нужно знать про взаимодействие с заказчиком

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

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

 

 

Помните, что “продажу” проекта можно сравнить с продажей сложного продукта. А продажа сложного продукта не заканчивается, даже когда вы получили за него деньги. Подтверждением продажи для вас является факт, что заказчик использует продукт в своих бизнес-процессах. Чтобы это отслеживать, на старте проекта важно ответить для себя на два вопроса: какую задачу решает проект и продукт проекта для заказчика, и как заказчик собирается получать выгоду от этого проекта.

 

 

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

Для команды проекта такой подход также позволяет понять собственную производительность. Ценность гибких методологий, например Scrum, когда вы раз в 2 недели осуществляете поставку, в том, что вы понимаете вашу двухнедельную производительность. Когда вы понимаете свою двухнедельную производительность, у вас повышается качество планирования, вы четко понимаете, что вы готовы сделать за эти две недели. А у команды крепнет вера в собственные силы и успех проекта.
 

 

Еще один важный фактор, который должен отслеживать PM, – это повышение  производительности по ходу проекта. Команда, которая сработалась, постепенно выдает все лучший результат. Пусть на 3-5-10 процентов, но лучше. Если этого не происходит, для PM-а – это звоночек, надо посмотреть, что-то идет не так.

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

 

 

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

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

На этапе эксплуатации мы всячески приветствуем замечания и пожелания заказчика по улучшению продукта, поскольку это не только позволяет нам совершенствовать продукт, но и показывает, что заказчик продуктом пользуется.

 

Несколько кейсов

Оба кейса, о которых я кратко расскажу, – не негативные, но проблемные.

 

Кейс 1. Проект реализовывался классическим способом: контракт фикс-прайс с внешним заказчиком. Группа аналитиков разработала большое ТЗ – на несколько сотен страниц. И вот в какой-то момент на этапе реализации выяснилось, что одну и ту же формулировку одного из пунктов ТЗ заказчик и аналитик трактуют по-разному. Но реальная проблема в том, что потенциальные изменения, если просто принять сторону заказчика влияют на архитектуру продукта проекта.

 

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

 

Кейс 2. Какие могут быть риски у этого подхода? У заказчика может создаться ощущение, что вы завысили цену или сроки проекта.

 

 

 

 

 

Взаимодействие с командой

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

 

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

 

 

Спасибо за внимание.

Успеха Вашим проектам!

 

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

 

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

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

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

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

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

 


См. также

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

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

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

20.12.2023    2919    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    14502    0    ASchekachev    37    

55

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

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

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

28.06.2023    5926    0    stnslv    5    

25

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

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

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

10.02.2023    4847    0    andironenko    2    

31

Тест для самопроверки руководителя проекта: как отличить падавана от рыцаря-джедая?

Компетенции и навыки РП Бесплатно (free)

Многое узнать ты еще можешь, мой старый падаван. Это только начало… Если честно, каждый раз, когда мне предлагают поднять тему “компетенций руководителя проекта”, у меня возникает ощущение, что я все время бьюсь в одну и ту же стену.

12.01.2023    5460    0    MariaTemchina    28    

22

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

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

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

27.12.2022    2814    0    MariaTemchina    28    

24

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

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

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

09.11.2022    4293    0    user1576201    10    

17

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

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

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

09.09.2022    10868    0    biimmap    79    

75
Оставьте свое сообщение