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