지난 '(상)'편에서 우리는 프로젝트의 완벽한 청사진을 그리는 '계획'의 세계를 탐험했습니다. 하지만 우리 모두 경험으로 알고 있죠. 지도대로만 흘러가는 여행은 없다는 것을요. 프로젝트를 시작하는 순간, 계획은 살아있는 생물처럼 꿈틀대기 시작합니다. 핵심 개발자가 갑자기 퇴사하고, 고객은 어제까지 없던 새로운 아이디어를 요구하며, 잘 되던 서버는 이유 없이 말썽을 부립니다.
계획서 속 PM은 전략가였지만, 현실 속 PM은 소방수에 가깝습니다. 여기저기서 터지는 불을 끄느라 정신이 없죠. 하지만 중요한 것은, PMP 시험은 우리가 유능한 '소방수'가 되기를 넘어, 애초에 불이 나지 않도록 관리하고, 불이 났을 때 체계적으로 대응하며, 모든 재난을 교훈으로 남기는 '방재 시스템 설계자'가 되기를 원한다는 점입니다.
오늘은 PMP '프로세스' 영역의 후반부, 계획이 현실과 부딪히는 치열한 전쟁터인 '실행, 통제, 그리고 종료'에 대한 이야기를 해보려 합니다. 😊
ECO Task 10: 변경 통제 - 변화는 '관리'의 대상 🤔
프로젝트에서 변경 요청은 필연적입니다. "이 기능 하나만 추가해 주세요"라는 고객의 가벼운 한마디가 프로젝트 전체를 뒤흔들 수도 있죠. 유능한 PM은 모든 변경을 막는 '벽'이 아니라, 변경의 영향을 분석하고 합리적인 의사결정을 돕는 '문지기' 역할을 합니다. 이를 위한 시스템이 바로 '변경 통제 프로세스'입니다.
🔍 효과적인 변경 통제 4단계
- 변경 요청(CR) 제출: 모든 변경은 공식적인 변경 요청서(Change Request Form)를 통해 접수합니다. 누가, 왜, 무엇을 바꾸고 싶은지, 기대효과는 무엇인지 명확히 기록해야 합니다.
- 영향도 분석: PM과 팀은 해당 변경이 범위, 일정, 비용, 품질 등 프로젝트의 다른 영역에 미칠 파급 효과를 분석합니다. "이 기능을 추가하면 출시일이 2주 늦어지고, 추가 비용 1천만 원이 발생합니다"와 같이 구체적으로 분석해야 합니다.
- 변경 통제 위원회(CCB) 검토: 분석 결과를 바탕으로 스폰서, 주요 이해관계자 등으로 구성된 CCB(Change Control Board)가 변경 승인 여부를 최종 결정합니다. PM이 독단적으로 결정하는 것이 아닙니다.
- 결과 반영 및 소통: 결정된 내용은 모든 이해관계자에게 투명하게 공유하고, 승인된 변경은 프로젝트 계획서에 공식적으로 반영합니다.
애자일에서는 이 프로세스가 제품 백로그를 통해 훨씬 유연하게 이루어집니다. 변경 요청은 새로운 '사용자 스토리'로 백로그에 추가되고, 제품 책임자(Product Owner)가 다른 항목들과 비교하여 우선순위를 재조정합니다. 단, 진행 중인 스프린트를 중단시키는 변경은 거의 허용되지 않습니다.
ECO Task 11: 리스크와 이슈 관리 - 시험 단골 출제 포인트 📊
PMP 시험에서 수험생들이 가장 많이 혼동하는 개념이자, 실무에서도 헷갈리기 쉬운 두 단어, 바로 '리스크'와 '이슈'입니다. 이 둘을 명확히 구분하는 것만으로도 프로세스 영역의 절반은 이해한 셈입니다.
■ 리스크 (Risk): 미래의 안개
"만약 ~ 라면?"
- 정의: 아직 일어나지 않은, 미래에 발생할 수도 있는 불확실한 사건입니다. 긍정적 리스크(기회)와 부정적 리스크(위협)가 모두 포함됩니다.
- 관리 방식: 사전 예방적(Proactive). 리스크를 미리 식별하고, 발생 확률과 영향을 분석하여, 대응 계획을 세웁니다. (예: 완화, 회피, 전가, 수용)
- 문서: 리스크 기록부 (Risk Register)
- 예시: "만약 핵심 개발자가 퇴사한다면 프로젝트가 지연될 것이다." (아직 퇴사 안 함)
■ 이슈 (Issue): 발등의 불
"지금 ~ 일이 터졌다!"
- 정의: 현재 발생한 문제, 장애물, 또는 이견입니다. 현실이 된 리스크라고 볼 수 있습니다.
- 관리 방식: 사후 대응적(Reactive). 발생 즉시 해결해야 합니다. 문제를 기록하고, 담당자를 지정하여 해결을 촉구합니다.
- 문서: 이슈 기록부 (Issue Log)
- 예시: "핵심 개발자가 방금 사직서를 제출했다." (실제로 발생함)
유능한 PM은 이슈 해결(소방)에만 매몰되지 않고, 리스크 관리(방재)에 더 많은 시간을 투자하여 이슈 발생 자체를 줄이려고 노력합니다.
ECO Task 12: 프로젝트 종료 및 지식 이전 ⚙️
모든 기능 개발이 끝나고 제품이 출시되었다고 해서 프로젝트가 끝난 것이 아닙니다. "수고하셨습니다!"라는 말 한마디로 흩어지는 것은 최악의 마무리입니다. 공식적인 '종료 프로세스'는 프로젝트의 성공을 확정하고, 그 경험을 조직의 자산으로 만드는 중요한 의식입니다.
🔍 제대로 프로젝트를 마무하는 법
- 공식적인 승인 획득: 고객이나 스폰서로부터 프로젝트 결과물이 요구사항을 모두 충족했다는 최종 인수 서명을 받아야 합니다.
- 최종 보고서 작성: 프로젝트의 성과를 계획과 비교하여 분석하고, 예산, 일정, 범위 목표 달성 여부를 정리합니다.
- 교훈 정리(Lessons Learned): 프로젝트 과정에서 무엇이 잘되었고, 무엇이 잘못되었는지, 그리고 다음 프로젝트에서는 무엇을 다르게 해야 할지 최종적으로 정리하여 조직 프로세스 자산(OPA)으로 남깁니다. 애자일에서는 매 스프린트 회고를 통해 이를 상시적으로 수행합니다.
- 자원 해제 및 계약 종료: 팀원들을 공식적으로 원래 소속팀이나 다른 프로젝트로 보내주고, 외부 업체와의 모든 계약을 정산하고 종료합니다.
이러한 공식적인 절차를 통해 프로젝트는 비로소 마침표를 찍고, 그 경험은 회사의 기억 속에 저장됩니다.
이것으로 PMP 시험의 50%를 차지하는 '프로세스' 영역의 대장정을 모두 마쳤습니다. (상)편에서 잘 짜인 '계획'이라는 지도를 그렸다면, (하)편에서는 예측불허의 '현실'이라는 바다를 항해하는 법을 배웠습니다. 변경의 파도를 관리하고, 리스크라는 암초를 피하며, 이슈라는 폭풍우에 대응하는 것. 이것이 바로 프로세스 영역의 진정한 핵심입니다.
'리스크'와 '이슈' 중, 평소 업무에서 어떤 것을 관리하는 데 더 많은 에너지를 쏟으시나요? 미래를 예측하고 대비하는 편인가요, 아니면 당장 터진 문제를 해결하는 데 급급한 편인가요? 여러분의 솔직한 경험을 댓글로 공유해주세요. 서로의 소방 경험을 나누다 보면 더 나은 방재 전문가로 성장할 수 있을 겁니다.
이제 PMP 시험의 92%를 정복했습니다. 마지막 여정은 8%를 차지하는 작지만 강력한 '비즈니스 환경(Business Environment)' 영역입니다. 우리가 하는 프로젝트를 회사의 큰 그림과 연결하는 전략적인 눈을 기르는 법에 대해 다음 시간에 함께 알아보겠습니다.
자주 묻는 질문 (FAQ) ❓
Q1. 변경 통제 위원회(CCB)는 모든 프로젝트에 필수적인가요?
A. 프로젝트의 규모나 복잡성에 따라 다릅니다. 작은 프로젝트에서는 PM이나 스폰서가 CCB 역할을 겸할 수도 있습니다. 하지만 프로젝트에 미치는 영향이 큰 중요한 변경에 대해서는 주요 이해관계자들이 함께 책임지고 결정하는 공식적인 거버넌스 체계를 갖추는 것이 PMP에서 권장하는 방식입니다.
Q2. 긍정적 리스크(기회)는 어떻게 관리하나요?
A. 부정적 리스크와 마찬가지로 대응 전략을 세웁니다. '활용(Exploit)'은 기회를 100% 실현시키기 위해 적극적으로 행동하는 것, '향상(Enhance)'은 기회의 발생 확률이나 영향력을 높이는 것, '공유(Share)'는 기회를 더 잘 활용할 수 있는 제3자와 협력하는 것, '수용(Accept)'은 특별한 조치 없이 기회가 오면 받아들이는 것입니다.
Q3. 프로젝트가 중간에 취소되어도 종료 프로세스를 진행해야 하나요?
A. 네, 반드시 해야 합니다. 프로젝트가 실패하거나 조기에 종료되더라도, 공식적인 종료 프로세스는 매우 중요합니다. 지금까지 진행된 작업의 결과물을 정리하고, 계약을 마무리하며, 가장 중요하게는 '왜 프로젝트가 중단되었는지'에 대한 교훈을 철저히 분석하여 조직의 자산으로 남겨야 유사한 실패를 반복하지 않을 수 있습니다.