가이드 › 가이드

프로젝트 의사소통 계획서 템플릿

프로젝트 의사소통 계획서는 대개 한 번 쓰고 서랍에 넣어 둔 채, 진짜 계획은 수십 개의 메일 스레드 속에서 돌아갑니다. 이 템플릿은 한 장에 들어가고, 모든 메시지에 담당자 이름이 있으며, 다시 열어 볼 마음이 들 만큼 짧습니다.

채널이 아니라 대상부터 정하기

많은 팀이 '사보를 보내자'에서 출발해 거꾸로 계획을 세웁니다. 그 대신 누가 무엇을 알아야 하는지, 그래서 그 사람이 무엇을 해 주길 바라는지부터 정하세요. 스폰서는 내려야 할 결정을, 수행팀은 일정을, 영향을 받는 부서는 변화가 자기 책상에 떨어지기 전에 미리 듣기를 원합니다.

대상 목록은 이해관계자 맵에서 가져오면 빠지거나 지어낸 사람이 생기지 않습니다. 같은 메시지가 필요한 사람끼리 묶고, 관리할 수 있을 만큼만 짧게 유지하세요.

• 스폰서와 운영위원회(SteerCo) 위원.
• 수행팀과 공급업체.
• 영향을 받는 현업 부서와 최종 사용자.
• 재무, 법무, 보안 등 통제 부서.
• 프로젝트를 막을 수 있는 사람: 먼저 묻지 않아도 목록에 넣어야 합니다.

표 자체

사람이 아니라 메시지 하나에 한 행을 씁니다. 복사해서 쓸 수 있는 구조이니 스프레드시트나 문서에 붙여 넣고, 계획서를 배포하기 전에 모든 열을 채우세요.

• 대상: 누가 받는지.
• 목적(공유, 의견 수렴, 결정, 승인)과 받는 사람이 가져가야 할 핵심 메시지 하나.
• 채널: 회의, 서면 보고서, 브리핑 노트, 메시지, 대면.
• 주기: 매주, 격주, 마일스톤마다, 또는 특정 상황 발생 시.
• 담당자: 작성하고 발송하는 한 사람.
• 피드백 경로: 받는 쪽이 의견을 돌려줄 방법.

주기와 발동 조건

정기 커뮤니케이션은 달력에 따라, 이벤트성 커뮤니케이션은 발동 조건에 따라 움직입니다. 둘 다 적어 두세요. 주간 현황 보고서는 정해진 요일에 나갑니다. 마일스톤 적색, 변경 요청 승인, 중대한 이슈는 발생하는 즉시 나가야 하고, 어느 정도면 충분히 큰 일인지 누가 판단하는지도 계획서에 있어야 합니다.

• 매주: 팀과 스폰서에게 현황 보고서.
• 회차마다: 회의 전에 배포하는 운영위원회 자료.
• 마일스톤마다: 영향을 받는 팀에게 짧은 안내.
• 발동 시: RAG 상태가 적색으로 바뀌면 에스컬레이션 메시지.
• 발동 시: 범위, 일정, 예산이 바뀌면 변경 공지.

양방향으로 만들기

일방적으로 알리기만 하는 계획은 문제를 늦게 알게 됩니다. 주요 대상마다 문제가 있을 때 어떻게 알려 올 수 있는지 정해 두세요. 회의의 고정 안건, 지정 연락 창구, 짧은 통화 같은 방식이 있습니다. 그리고 돌아온 의견은 듣기만 하지 말고 RAID 로그에 남겨 실제로 처리하세요.

• 질문에 대한 응답 시간을 합의합니다.
• 우려 사항은 담당자를 정해 리스크나 이슈로 기록합니다.
• 스폰서에게 매달 한 번 묻습니다. 지금 정도의 소통량이 적절한가요?

계속 살아 있게 하기

단계 게이트마다, 그리고 이해관계자 맵이 바뀔 때마다 계획서를 점검하세요. 두 회차 동안 쓰이지 않은 행이 있다면 메시지가 죽었거나 계획이 틀린 것입니다. Senshin에서는 이해관계자 등록부와 주간 보고서가 계획과 함께 있어서, 대상 목록과 그들에게 가는 업데이트가 서로 어긋나지 않습니다.

• 계획서에 날짜를 적고 변경 이력을 남깁니다.
• 아무도 읽지 않는 행은 지웁니다.
• 운영위원회마다 계획서를 현실과 대조합니다.

Senshin에서는 이렇게 관리합니다

자주 묻는 질문

다른 가이드

최종 업데이트: 2026-10-22