Коммуникации на проекте

Коммуникации на проекте играют важнейшую роль и не зря выделены в PMBOK в отдельный процесс «управление коммуникациями»

Коммуникация состоит из следующих частей:

  • Планирование коммуникаций
  • Распространение информации
  • Отчетность по исполнению
  • Управление коммуникациями

Матрица коммуникаций

Начнем с матрицы коммуникаций, что в неё обычно включают:

  • тип передаваемой информации
  • получатель информации
  • частота коммуникации
  • ответственный за сбор и передачу информации
  • канал передачи информации

Чтобы составить матрицу коммуникаций, необходимо как можно раньше обсудить потребности каждого из участников и спонсоров проекта. Само собой матрица может корректироваться в течении работы над проектом.

Важное замечание: отчеты не могут быть единственным видом коммуникации как внутри команды проекта так и между менеджером проекта и спонсорами проекта.

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

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

Отчеты по исполнению проекта

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

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

Я разбирал кейс по отчетам на проекте с примерами в отдельном посте, рекомендую заглянуть чтобы узнать больше о том, как может выглядеть отчет по проекту в заказной разработке:
Разбор ситуации(кейса) 7 для ПМа. Отчет по проекту.

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

  • низкое качество или скорость работы команды
  • клиент ищет формальные причины не платить выставленный счёт/инвоис
  • плохое управление ожиданиями клиента приводит к тому, что, несмотря на постоянно вносимые клиентом изменения или новую информацию, клиент все равно ожидает тот же срок поставки и бюджет, что и в начале проекта или не представляет насколько они изменились

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

Важно высылать клиенту email с кратким содержанием беседы сразу после завершения разговора. Это служит сразу нескольким целям:

  • фиксирует любые устные договоренности письменно
  • позволяет быстро найти когда и что обсуждалось и какое решение было принято
  • фиксирует ответственных если вместо решения была сформулированы задачи (AI’s — action items) и следующие шаги
  • служит весомым аргументов в спорах с клиентом по вопросам, которые упоминаются в email

Типичные ошибки коммуникации с клиентом

Одна ошибка часто встречается у неопытных менеджеров проекта — информирование о проблеме слишком поздно.

Поясню на примере из практики.
В процессе работы над технической задачей возникли непредвиденные трудности, которые привели к существенному увеличению сроков завершения задачи (в целях примера пусть это будет вместо 2х дней — 5). Менеджер не сообщает об этом клиенту сразу, а постфактум спустя 5 дней сообщает о том, что из-за непредвиденных сложностей было потрачено больше времени и увеличилась стоимость.

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

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

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

Коммуникации внутри команды проекта

Коммуникации внутри команды проекта пересекаются с матрицей ответственности, которая указывает, кто отвечает за какой из информационных потоков на проекте (включая документацию, например). Матрица коммуникаций внутри команды необходима не всегда, если члены команды имеют четкое представление о своей зоне ответственности и о взаимосвязях ролей в команде.

По мере роста численности команды (n) количество каналов передачи информации (k) внутри команды растет по формуле:
k = (n * (n — 1) ) / 2
то есть, например в команде из 4х человек, количество каналов равно 6, а в команде из 5ти — уже 10.
В итоге чем больше команда — тем больше времени тратится на коммуникации и тем важнее правильно организовать каналы передачи информации.

Каналы получения и отправки сообщений должны совпадать. Если вам написали письмо — ответьте письмом, если вам написали в мессенджер — ответьте там же.