Коммуникационный план проекта: кому, что и когда сообщать
Коммуникационный план нужен, чтобы информация в проекте доходила до того, кто должен действовать. Разберём получателей, владельцев, каналы и подтверждения на примере запуска внутреннего сервиса, включая сообщение о риске и отсутствие ответа.
План коммуникаций — договорённость об обмене информацией
Коммуникационный план проекта определяет, какая информация нужна участникам, кто её готовит, когда и каким способом передаёт и что должно произойти после получения. Это не перечень всех чатов и не расписание встреч. Рабочая строка заканчивается понятным действием: согласовать, выполнить, учесть изменение или подтвердить ознакомление.
В материале PMI об управлении коммуникациями среди компонентов плана выделены получатели, содержание, сроки, способ и формат передачи информации. Ниже — авторский прикладной шаблон на этой основе, а не обязательная форма PMI.
Общие правила общения в команде могут устанавливать, где хранятся решения и как оформляются задачи. План конкретного проекта отвечает на более узкий вопрос: кому сообщить, например, о задержке тестирования, чтобы вовремя изменить запуск. Он использует общий регламент, но не повторяет его целиком.
Таблица помогает организовать обмен, однако трудный разговор сама не проводит. Для развития постановки задач, обратной связи и согласования действий можно рассмотреть Управленческая коммуникация. При этом базовый план для своего проекта вы можете подготовить и проверить по следующему примеру.
Начните с решений, которые зависят от сообщения
Составьте список участников и для каждого ответьте: какое решение или действие этого человека зависит от информации о проекте? Заказчику может быть нужен выбор между сроком и объёмом, исполнителю — согласованное требование, службе поддержки — описание нового порядка, смежному подразделению — дата готовности результата.
Не приравнивайте интерес к проекту к необходимости читать всю переписку. Руководитель может получать короткое сообщение об исключениях, а рабочая группа — подробный журнал задач. Но сокращение потока не должно лишать человека сведений, без которых он несёт ответственность вслепую. Разобраться с ожиданиями помогает карта заинтересованных сторон.
Затем определите владельца каждого сообщения. Он отвечает за сбор и передачу согласованного содержания, но не обязательно обладает полномочиями утвердить само решение. Кто готовит предложение, кто принимает решение и кто исполняет — полезно сверить с матрицей ответственности RACI.
Заполненный шаблон: запуск внутреннего сервиса
Учебный проект — переход подразделения на единый порядок подачи заявок в техническую поддержку. Должности, события и договорённости вымышлены. Конкретные каналы замените разрешёнными средствами своей организации; конфиденциальные сведения нельзя автоматически отправлять в любой удобный мессенджер.
| Событие и содержание | Кому и для чего | Кто передаёт | Когда и где | Как закрывается коммуникация |
|---|---|---|---|---|
| Согласование состава полей заявки и исключений | Владелец процесса: утвердить требования | Аналитик проекта | До настройки формы; документ с отмеченными вопросами | Решение записано в журнале; спорные пункты имеют владельцев |
| Статус настройки и нерешённые препятствия | Рабочая группа: согласовать следующие действия | Руководитель проекта | В согласованный день контроля; краткая сводка в рабочем пространстве | Задачи и ответственные обновлены, обсуждение без действия не считается итогом |
| Ошибка тестирования мешает запуску | Заказчик и технический руководитель: выбрать вариант решения | Руководитель проекта после проверки факта | При выявлении угрозы согласованному запуску; срочное сообщение и запись в журнале | Получено решение либо вопрос передан по согласованному маршруту эскалации |
| Новый порядок подачи заявок готов | Сотрудники подразделения: узнать действие и точку помощи | Владелец процесса | До перехода; инструкция в общем доступном хранилище и уведомление | Доступ проверен, вопросы собраны у назначенного контактного лица |
| Итоги пробного использования | Заказчик: принять результат или назначить доработку | Руководитель проекта | После согласованного периода наблюдения; сводка фактов и предложение | Зафиксированы решение, оставшиеся ограничения и владелец сопровождения |
Это уже рабочий каркас. Чтобы превратить его в план своего проекта, замените роли конкретными ответственными, впишите календарные даты регулярных сообщений и проверяемый срок ответа на запросы решения. Формулировка «при необходимости» без признака события оставляет слишком много пространства для разных трактовок.
Отдельно укажите место хранения актуальной версии и человека, который её изменяет. Обсуждать черновик можно в чате, но итоговое решение должно попадать туда, где его найдут участники, не присутствовавшие в разговоре.
Как написать сообщение об отклонении
Плохое сообщение создаёт тревогу, но не даёт возможности действовать: «С тестированием всё плохо, запуск под вопросом». Полезнее отделить подтверждённый факт, влияние, варианты и запрос решения. Пример ниже относится к тому же вымышленному проекту.
Тема: требуется решение по запуску формы заявок.
Факт: при проверке заявка создаётся, но вложение недоступно специалисту поддержки. Ошибка воспроизведена на учебных данных, описание приложено к задаче.
Влияние: процесс с обязательным вложением пока не проходит согласованный сценарий приёмки.
Варианты: перенести запуск до исправления либо отдельно согласовать временный процесс без вложений, если владелец процесса подтвердит его допустимость.
Нужно от заказчика: выбрать вариант до контрольной встречи по запуску. До решения объявление сотрудникам не отправляем.
Указание срока должно быть конкретным в настоящем проекте: дата, время и часовой пояс, если участники работают в разных регионах. Не объявляйте предполагаемую причину ошибки доказанной и не обещайте срок исправления от имени специалиста, который его не подтвердил.
Если нужен результат от исполнителя, оформите отдельную задачу с условиями приёмки. Информационное сообщение и назначенная работа не взаимозаменяемы: у человека должна быть возможность понять, чего от него ждут.
Что делать, если ответа нет или мнения расходятся
Заранее договоритесь, как отличить доставку сообщения от принятого решения. Отметка о прочтении не равна согласию с бюджетом, сроком или риском. Если необходимо согласование, в плане должно быть прямо сказано, кто и в какой форме его фиксирует.
Для отсутствующего ответа предусмотрите последовательность: проверить адресата и доступ, напомнить о конкретном решении, затем обратиться к заранее названному заместителю или владельцу проекта. Не расширяйте рассылку на всех руководителей без понимания, кто вправе решить вопрос. Условие эскалации должно опираться на влияние на проект, а не на раздражение автора сообщения.
Когда участники предлагают разные варианты, сохраните разногласия в виде проверяемых альтернатив. Укажите последствия, неизвестные данные и лицо, принимающее решение. Не переписывайте журнал так, будто согласие существовало с самого начала.
Встреча нужна, если вопрос действительно требует совместного обсуждения. Для очередной передачи статуса может хватить письменной сводки. Если встреча назначена, её результат стоит оформлять по принципам эффективного совещания: решение, действие, ответственный и срок, а не только список присутствовавших.
Как проверить план до запуска проекта
Проведите короткую репетицию по реальному типу события: задержался результат, изменилось требование или появился риск. Участники должны без догадок найти получателя, подготовить сообщение и объяснить, какое подтверждение закрывает вопрос. Если этого не получается, уточните конкретную строку, а не увеличивайте весь документ.
- Каждое сообщение связано с решением или действием получателя.
- Исполнитель передачи и обладатель полномочий не перепутаны.
- Регулярные сроки и событийные условия различимы.
- Получатели имеют доступ к документу и понимают, какая версия актуальна.
- Для существенного риска определены ответ и маршрут эскалации.
- Конфиденциальность соответствует выбранному каналу.
Пересматривайте план при смене участников, переходе к новому этапу, изменении процесса принятия решений и повторяющихся потерях информации. Сам по себе большой объём переписки не доказывает плохую коммуникацию, а её малый объём — хорошую. Проверять нужно другое: получают ли люди нужные сведения вовремя и превращаются ли они в согласованные действия.
От таблицы сообщений к рабочим договорённостям
План задаёт порядок, а применять его приходится в разговорах, задачах и обратной связи. Посмотрите программу обучения управленческой коммуникации и сопоставьте её со своими трудностями.
Вопросы и ответы
- Нужен ли план небольшому проекту?
Масштаб документа можно сократить. Достаточно явно договориться о сообщениях, от которых зависят решения и действия; сложная форма сама по себе не нужна.
- Прочитанное сообщение считается согласованием?
Только если именно такой порядок заранее допустимо согласован для этой ситуации. Для существенного решения лучше явно фиксировать, кто его принял и что утверждено.
- Когда менять план коммуникаций?
При смене участников, этапа, полномочий или при повторяющихся потерях информации. Меняйте конкретные неработающие строки, сохраняя понятную актуальную версию.