프로젝트 상태 보고서
Project Status Report (: Weekly Report)
PM은 프로젝트 진행상황을 이해관계자들에게 효과적으로 전달하기 위해 프로젝트 상태 보고서를 작성해야 한다. 주 단위로 전반적인 업데이트를 통해 프로젝트가 계획대로 진행되고 있는지, 위험 요소는 없는지 파악하고 필요에 따라 방향을 수정하고 마감일을 지킬 수 있다. 나는 매주 금요일 오전에 지난주 금요일부터 이번주 목요일까지의 업데이트가 담긴 Weekly Report를 프로젝트 팀을 포함한 전체 Stakeholder에게 메일로 발송하고 있다. 오늘은 프로젝트 상태 보고서를 작성하는 방법과 기본적인 템플릿에 대해 이야기하려고 한다.
프로젝트 상태 보고서는 프로젝트 진행상황에 대한 업데이트가 담긴 문서이다. 프로젝트 팀원 및 이해관계자들은 프로젝트 상태 보고서를 통해 프로젝트 현황을 한눈에 파악하고, 진행 중인 작업, 이슈, 예정된 다음 작업을 파악할 수 있다. 프로젝트 상태 보고서를 발송하는 시점은 프로젝트 성격에 따라 다를 수 있다. 매주 업데이트가 필요한 프로젝트도 있고, 한 달에 한 번만 업데이트해도 되는 프로젝트도 있다. PM은 프로젝트의 타임라인 및 성격에 따라 프로젝트 상태 보고서를 언제부터 발송하고, 어느 주기로 발송할지 정하면 된다. 다만, 프로젝트 상태 보고서는 문제가 발생하고 나서 작성하는 보고서가 되어서는 안 된다. 프로젝트가 계획대로 진행 중인지, 위험 상태인지, 계획에서 벗어났는지 등 최신 프로젝트 진행 상태를 기준으로 작성해야 한다.
1. Overall Status
프로젝트 상태 보고서 최상단에 프로젝트의 전반적인 상태를 작성한다. 이해관계자들은 Overall Status를 통해 현재 프로젝트가 어떤 상태인지 즉각적으로 파악할 수 있다.
On Track (: Project is on schedule)
- 프로젝트가 계획대로 진행 중인 상태로 범위/일정/원가 상의 큰 위험이 없는 상태이다.
At Risk (: Milestones missed but date intact)
- 프로젝트 계획서 상의 마일스톤은 벗어났지만, 종료일은 변경되지 않은 상태이다.
High Risk (: At risk, with a high risk of going off track)
- 프로젝트가 위험한 상태로 프로젝트 종료일을 벗어날 가능성이 높은 상태이다.
Off Track (: Date will be missed if action not taken)
- 프로젝트 범위를 수정하는 등의 액션을 취하지 않으면 종료일을 지킬 수 없는 상태이다.
이슈 없이 완벽한 프로젝트란 세상에 없다. 매일 크고 작은 이슈들이 터지고, PM은 문제를 해결할 수 있는 담당자를 소집하여 불을 끄고 다니기 급급하다. 업무 시간 내내 프로젝트 팀원들에게 진행상황을 체크하고, 쪼고, 이슈를 해결하느라 정작 내 업무는 퇴근 후에야 시작할 수 있다. 하지만 매주 프로젝트 상태 보고서의 Overall Status가 'On Track'이기만 하다면 얼마든지 이 한 몸 불사를 수 있다.
하지만 On Track이길 바란다고 해서 Risk가 발생했는데 그것을 위험이라고 치부하지 않거나, 이해관계자들에게 알리지 않고 숨겨서는 절대 안 된다. PM은 프로젝트가 On Track 상태를 유지할 수 있도록 사전에 위험을 예방하고 일정을 타이트하게 관리하는 사람이 맞지만, Risk를 가장 빠르게 파악하여 모두에게 알리고, 담당자가 문제를 해결할 수 있도록 서포트해야 하는 사람이기도 하다. 그래서 항상 긴장을 늦추지 말고, 매의 눈으로 프로젝트의 전반적인 진행 상태를 추적 및 관리해야 한다. PM에게 "어떻게든 되겠지"라는 사고는 절대 금물이다.
2. Update
처음으로 발송하는 프로젝트 상태 보고서에는 프로젝트 개요가 포함돼야 한다. 프로젝트의 목표, 리더 및 구성원, 계획, 타임라인 등 프로젝트에 대한 전반적인 개요를 작성하여 보고서를 받는 이해관계자들의 이해도를 높일 수 있도록 한다. 두 번째 발송부터는 프로젝트에 대한 개요는 생략해도 되며, 프로젝트 진행 상태, 이번 주 업데이트, 예정된 업무에 대해 구체적으로 작성한다. 이때 Epic 단위로 나눠서 업데이트를 한다면 훨씬 눈에 잘 들어온다.
예시)
이전 회사에서 진행한 프로젝트를 참고하여 작성3. Issue and Risk
프로젝트가 직면한 이슈, Risk 등 모든 문제를 명시해야 한다. 여기서 말하는 문제란 예상하지 못한 감사나 심의를 받아야 하는 경우, 추가 예산이 필요한 경우, 프로젝트 타임라인에 영향을 미치는 지연 등 다양한 형태로 나타날 수 있다. 이러한 문제가 발생했을 때 당황하지 말고 이해관계자들에게 신속하게 정보를 공유하고, 팀원들이 문제를 해결할 수 있도록 서포트해야 한다.
예시)
이전 회사에서 진행한 프로젝트를 참고하여 작성4. Next Week
다음주에 해야 하는 업무, 예정된 작업에 대해 작성한다. 이것을 작성함으로써 프로젝트 팀원들과 이해관계자에게 다음주에 해야 할 일에 대해 상기시켜 해당 업무에 누락되지 않게 하는 효과도 있고, 작업이 예정된 날짜에 완료되지 않고 지연되는 경우 PM에게 알려달라는 무언의 압박이기도 하다.
예시)
이전 회사에서 진행한 프로젝트를 참고하여 작성5. Reference
프로젝트 상태 보고서에 모든 세부사항을 기재해서는 안 되지만, 프로젝트 상태 외 자세한 내용을 알고 싶어 하는 이해관계자가 있을 수 있다. 특히 프로젝트 중간에 입사/투입된 경우 프로젝트 개요를 모르기 때문에 보고서만으로 팔로업하기 어려울 수 있다. 이것을 커버하기 위해 프로젝트 상태 보고서 맨 하단에 문서나 리소스에 대한 링크를 붙여주면 좋다. 예를 들어, 원페이저나 PRD, Dashboard 등을 링크할 수 있다.
나는 실제로 프로젝트 개발 플래닝이 완료되면 Dashboard를 만들고, PRD와 함께 Weekly Report에 링크하고 있다. 생각보다 많은 이해관계자들이 링크된 문서를 확인하고, PRD나 대시보드에 대한 질문을 종종 하기 때문에 레퍼런스 링크는 꼭 필요한 작업이라고 생각한다.
프로젝트 상태 보고서를 매주 작성하고 보내는 일은 생각보다 어려운 일이다. 특히 업무 시간이 회의 지옥이어서 보고서를 작성할 시간이 없다면, 퇴근 후에 작성해야 할 텐데 더욱 곤욕스러운 일이다. 하지만 일주일에 한번 프로젝트 보고서를 작성하기 위해 프로젝트 진행 상태를 꼼꼼히 확인하고, 이슈 및 리스크를 파악하고, 다음주에 해야 할 업무를 정리하다 보면 정말 놓치는 것이 1도 없게 된다. 아무리 PM이라도 당장 처리해야 하는 업무들에 치이다 보면 프로젝트 전반적인 진행상황을 놓칠 수 있다. 그러나 프로젝트 상태 보고서를 작성한다면, 그저 이것을 작성하기 위한 노력만으로 프로젝트의 현 상태를 명확하게 파악하고, 이슈나 리스크를 놓치지 않을 수 있다. 그래서 힘들더라도 해야 하는 일 중 하나라고 생각한다. 사실 아직도 매주 목요일 밤이 가장 고되고 두렵지만, PM으로 사는 이상 어쩔 수 없다. 전국의 모든 PM 화이팅 :)
