프로젝트 통합 관리 프로세스
Project Integration Management
PM은 프로젝트가 처음 설정한 계획대로 진행되고 있는지 추적 및 관리하고, 프로젝트 일정/원가/범위의 변경을 초래할 수 있는 이슈들을 감시하고 통제해야 한다. 이를 위해서는 먼저 프로젝트 통합 관리 프로세스에 대해 이해할 필요가 있으며, 오늘은 PMBOK(Project Management Body of Knowledge)에서 말하는 프로젝트 통합 관리에 대해 정리해 보려고 한다.
프로젝트 통합 관리
프로젝트 통합 관리는 프로젝트 범위 관리부터 이해관계자 관리까지의 모든 지식 관리를 의미하며, 아래 7단계로 구성된다.
1. 프로젝트 헌장 개발
프로젝트 헌장이란 프로젝트의 자원, 예산, 목표를 부여하기 위해 관리자로부터 승인받은 문서로 보통 사업계획서(Business Case 또는 Benefits Management Plan)로 불린다. 프로젝트 헌장은 프로젝트 목적을 정의하는 것을 시작으로 핵심 인도물, 마일스톤, 원가, 이해관계자, 프로젝트 관리 및 개발 방법론, 문제 정의, 상위 수준의 가정 및 제약조건, 예상되는 위험 등을 작성한다.
2. 프로젝트 관리 계획서 개발
프로젝트 관리 계획서는 프로젝트가 어떻게 계획 및 실행되고, 감시/통제되는지 기술한 문서이다. 모든 보조적인 계획을 정의하고 조정하여 종합적인 관리 계획서를 작성해야 한다.
프로젝트 관리 계획서에는 범위 기준선, 일정 기준선, 원가 기준선이 반드시 포함되어야 한다.
'범위 기준선'은 프로젝트의 범위로 WBS(작업 분류 체계)를 기준으로 작성하며, '일정 기준선'은 목표된 일정을 달성하기 위해 시정 조치가 필요한지 판단할 수 있는 기준이 되는 일정(출시일, 납기일 등 변동이 불가한 날짜)이다. '원가 기준선'은 관리 예비비를 제외하고 일정 단계마다 프로젝트 예산으로 승인된 비용이다. 범위, 일정, 원가에 대한 계획서 외에도 의사소통 관리 계획서, 위험 관리 계획서, 조달 관리 계획서 등의 문서가 프로젝트 관리 계획서에 포함될 수 있다. 보통 프로젝트 헌장이나 One-pager에 원가, 일정, 범위와 같이 중요한 요소는 포함되므로 조직/프로젝트의 특성에 따라 다른 계획서까지 작성할 필요가 있는지 고민하고 필요에 따라 작성하면 된다. 이때 PM은 용이한 형상 관리를 위해 조직에 필요한 문서의 종류를 파악하고, 정형화된 템플릿을 만들어서 배포할 수 있다.
범위, 일정, 원가를 모두 포기하지 못해서 결국 품질이 포기되는 경우가 있다. 그러나 애자일에서는 품질을 가장 중요하게 생각하기 때문에 다른 것을 포기하더라도 품질이 낮아지지 않도록 주의해야 한다.
3. 프로젝트 작업 지시/관리
계획을 실행에 옮기는 가장 중요한 단계로 프로젝트를 실질적으로 통합/실행/관리하는 작업을 수행한다. 즉, 프로젝트 목표를 달성하기 위해 계획서에 정의된 작업과 승인된 변경을 이행하는 단계이다.
PM은 프로젝트를 통합 관리하고, 변경에 따른 위험을 사전에 파악하기 위해 프로젝트 범위의 변경, 계획의 수정, 원가 또는 예산의 변경, 일정 변경 등을 공식적으로 요청하고 승인하는 변경 요청/승인 프로세스를 구축해야 한다. 변경 요청 작업은 크게 네 가지 유형으로 분류된다.
· 시정 조치: 현재 지연 사항을 프로젝트 관리 계획서의 수준으로 높이기 위한 작업이다.
· 예방 조치: 향후 부정적인 영향을 줄 수 있는 이슈를 사전에 조치하는 작업이다.
· 결함 수정: 프로젝트/서비스 요구사항과 불일치한 작업을 수정해서 보완하는 작업이다.
· 갱신: 수정 또는 추가된 작업을 반영하기 위해 프로젝트 문서를 갱신하는 작업이다.
4. 프로젝트 지식 관리
프로젝트 시작 전, 진행 중, 종료 후 프로젝트에 대한 지식을 수집하여 교훈물 관리대장에 기록하고, 다음 프로젝트를 위해 새로운 지식을 축적하는 과정이다. 이전 프로젝트 교훈물을 통해 기존 지식을 활용하고, 새로운 지식 생성을 위해 암묵지를 명백지로 만드는 작업을 수행한다. 즉, 다음 프로젝트의 성공률을 높이기 위해 전반적인 진행상황 및 지식을 문서화한다. 이는 동일한 이슈가 재발하는 것을 방지하고, 프로젝트 성공률을 높이는 전략이다.
이러한 형상 관리를 통해 무절제한 변경을 사전에 예방하고, 변경에 따른 부작용을 최소화할 수 있다. 또한 프로젝트를 적절히 통제하여 체계적이고 효율적으로 관리할 수 있으며, 가시성과 추적성을 보장함으로써 개발 생산성과 품질을 높일 수 있다.
5. 프로젝트 작업 감시/통제
사전에 정의한 프로젝트 관리 계획서의 목표에 대한 수행을 추적하고, 달성 여부를 검토/보고하는 단계이다. PM은 Scrum, 1on1, 회고 등을 통해 정기적으로 프로젝트의 진행상황, 수행 능력, 이슈 등을 검토한다. 이러한 검토는 비공식적인 검토가 될 수도 있고, 검토 결과서로 문서화될 수도 있다.
6. 변경 통제
모든 변경 요청서를 검토/승인하고, 변경된 내용을 인도물, 프로젝트 문서, 프로젝트 관리 계획서에 반영하는 단계이다. 프로젝트 도중 수정된 작업을 반영하기 위해 문서를 갱신하고 계획 등을 변경하며, 주로 갱신되는 문서는 아래와 같다.
· 원가 예측치: 원가 예측의 변경이 발생한 경우 갱신한다.
· 일정 예측치: 프로젝트 진행이 지연된 경우 갱신한다.
· 이슈 로그: 새로운 이슈가 발견된 경우 갱신한다.
· 교훈물 관리대장: 교훈물이 습득된 경우 갱신한다.
· 위험 관리대장: 새로운 위험이 발견된 경우 갱신한다.
7. 프로젝트 종료
프로젝트의 공식적인 종료를 통해 프로젝트 팀의 조직 자원을 해체하고, 프로젝트 목표가 완수되었는지 확인하는 단계이다. 모든 산출물이 검수 기준을 준수했는지 확인하고, 최종적으로 제품/서비스에 요건이 정상적으로 적용되었는지 검토한다. PM은 프로젝트 종료 후 산출물 및 교훈물을 취합하고 아카이빙한다.
Launch Plan Checklist
런칭 직전에 작성하는 체크리스트로 프로젝트 목표, QA 결과(TC, 승인자 등)를 작성한다. 또한 도메인별 개발/배포 타임라인 및 배포 승인자의 이름을 기재하고, 컨펌 여부를 작성한다. 이렇게 컨펌을 남기는 이유는 런칭 후 이슈가 발생했을 때 책임을 묻기 위함도 있지만, 런칭 전 누락된 Task가 없는지 마지막으로 확인하는 절차이기도 하다. 그리고 Backlog, 유지운영 방안, CS 방식 등 런칭 후 계획도 작성하는 것이 좋다. 이렇게 작성한 Launch Plan Checklist는 런칭 일주일 전에 스테이크 홀더들에게 메일로 배포한다.
Launch Announcement
런칭일로부터 3일 내에 작성하여 스테이크 홀더들에게 배포하는 문서이다. 런칭한 서비스를 설명하고, 이를 통해 고객이 얻는 베네핏(새로운 이득이거나, 기존의 문제를 해결해주는 것)을 작성한다. 프로젝트 또는 서비스의 다음 버전을 준비 중이라면 Next Plan도 작성하는 것이 좋다. 그리고 문서의 맨 하단에 'Special thanks to'로 프로젝트에 도움을 준 모든 팀을 언급하고 감사를 표한다. 이때 누락되는 팀이 없도록 여러 번 확인하자.
오늘은 PMBOK 기반의 프로젝트 통합 관리에 대해 이야기했다. 프로젝트 통합 수행 및 관리는 어렵지만 PM에게 반드시 필요한 스킬이다. 다만, 프로젝트 진행상황 및 이슈를 관리하기 위해 디테일에 포커싱하면 전체 흐름을 놓치고, 전체를 관리하다 보면 디테일을 놓칠 수 있으니 놓치는 부분이 없도록 조정해야 한다. 효율적인 통합 관리를 위해 PO, UX, Tech 각 리더들을 신뢰하고 일부 권한을 위임할 수도 있다. 예를 들어, 프로덕트 요건의 디테일 및 정의되는 과정을 PO에게 위임하고, 모든 미팅에 따라 들어가지 않고 PO와 별도 싱크업을 통해 내용을 공유 받을 수 있다. PM은 프로젝트를 전체적으로 이해하고 관리해야 하지만, 어느 정도 롤을 나눌 필요는 있다. 하나부터 열까지 놓치지 않고 매니징 한다는 것이 쉽지 않겠지만, 용이한 형상 관리를 위해 프로젝트에 자주 사용되는 문서들을 정형화된 템플릿으로 만들어서 조직에 배포하는 것부터 시작해 보면 어떨까.
