"김 매니저, 이거 좋은 아이디어 같은데 한번 빠르게 진행해 봐요."
상사가 툭 던진 한 마디에 '네, 알겠습니다!'를 외치며 일단 개발팀에 찾아가 요청부터 했던 경험. 우리 직장인들의 DNA에는 '빠른 실행력'이 마치 최고의 미덕처럼 각인되어 있는지도 모릅니다. 하지만 그렇게 '일단 해보자!'며 달려들었다가, 나중에 보니 예산도 꼬이고 다른 핵심 업무 일정까지 망가져서 수습하느라 진땀 뺐던 기억, 저만 있는 건 아니겠죠?
PMP 시험의 '프로세스(Process)' 영역은 바로 이 '일단 하고 보자'는 우리의 오랜 습관에 정면으로 도전합니다. 문제가 발생했을 때, 가장 먼저 행동에 나서는 보기는 매력적으로 보이지만, PMI는 그것을 가장 위험한 '함정'으로 간주합니다. 오늘은 왜 계획을 검토하는 '느린 행동'이 가장 빠른 정답이 되는지, 그 역설적인 지혜에 대해 이야기해 보겠습니다. 😊
당신을 탈락시키는 '성급한 행동' 오답 유형 📊
프로세스 영역의 문제들은 대부분 프로젝트 진행 중에 발생하는 돌발 상황을 제시합니다. 고객이 갑자기 범위를 변경해달라고 하거나, 예상치 못한 리스크가 터지거나, 품질에 결함이 발견되는 식이죠. 이때 당신의 순발력을 테스트하려는 듯한 '즉시 해결' 보기가 등장합니다. 하지만 기억하세요, PM은 소방수가 아닙니다. 다음 유형의 보기는 과감히 제외해야 합니다.
- 즉시 실행형: "고객의 요청에 따라 개발팀에 즉시 추가 기능 개발을 지시한다." ➜ 왜 오답인가? 변경이 프로젝트의 다른 부분(일정, 비용, 리스크)에 미칠 영향을 전혀 분석하지 않았고, 공식적인 변경 절차를 무시했습니다.
- 임의적 판단형: "PM의 판단하에 가장 저렴한 공급업체와 계약을 진행한다." ➜ 왜 오답인가? 사전에 합의된 '조달 관리 계획'이나 '공급업체 선정 기준'을 따르지 않은 독단적인 결정입니다.
- 프로세스 무시형: "빠른 해결을 위해 변경 통제 위원회(CCB) 승인 없이 수정 사항을 우선 반영한다." ➜ 왜 오답인가? 프로젝트의 기준선(Baseline)을 지켜야 할 PM이 스스로 거버넌스를 무너뜨리는 최악의 행동입니다.
정답으로 가는 3단계 사고법: '분석 → 검토 → 절차' ⚙️
그렇다면 '성급한 행동' 대신 무엇을 해야 할까요? PMI가 모든 프로세스 문제에 일관되게 요구하는 정답의 로직은 명확합니다. 바로 '분석 → 계획 검토 → 절차 준수'라는 3단계 사고방식입니다. 어떤 문제가 나와도 이 프레임워크에 맞춰 생각하는 연습을 해야 합니다.
1단계: 분석 (Analyze) - "일단 멈춰서 생각하라"
문제가 발생했을 때, PM의 첫 번째 임무는 행동이 아니라 '분석'입니다. 이 변경이, 이 리스크가, 이 결함이 우리 프로젝트의 범위, 일정, 원가, 품질 등 기준선에 어떤 영향을 미칠지 파악하는 '영향도 분석(Impact Analysis)'이 선행되어야 합니다. "문제를 분석한다", "영향을 평가한다", "근본 원인을 조사한다"는 키워드가 포함된 보기는 정답 후보 1순위입니다.
2단계: 계획 검토 (Review the Plan) - "우리의 약속을 확인하라"
영향도 분석이 끝났다면, 그 다음은 관련 '관리 계획서'를 펼쳐보는 것입니다. 계획서는 이런 상황이 발생했을 때 우리가 어떻게 행동하기로 '미리 약속'해둔 절차를 담고 있습니다.
- 범위 변경 요청? ➜ 범위 관리 계획서 확인
- 예상치 못한 리스크 발생? ➜ 리스크 관리 계획서 확인
- 품질 표준 미달? ➜ 품질 관리 계획서 확인
"관련 계획서를 검토한다"는 보기는 PM이 즉흥적으로 일하는 것이 아니라, 약속된 시스템에 따라 일관성 있게 행동한다는 것을 보여주는 강력한 정답의 신호입니다.
3단계: 절차 준수 (Follow the Process) - "공식적인 길을 따르라"
계획서에 명시된 길을 따라가는 단계입니다. 대부분의 경우, 이는 '공식적인 변경 요청(Change Request)'을 제출하고, 프로젝트의 모든 변경을 통합적으로 관리하는 '통합 변경 통제(Integrated Change Control)' 프로세스를 따르는 것을 의미합니다. 변경 통제 위원회(CCB)의 검토와 승인을 거쳐, 승인된 변경사항을 모든 이해관계자에게 투명하게 공유하고 프로젝트 문서를 업데이트하는 것까지가 PM의 역할입니다.
결국 PMP의 프로세스 영역이 우리에게 가르쳐주는 것은 '계획'의 진정한 가치입니다. 계획은 단순히 예쁘게 만들어놓고 서랍에 넣어두는 문서가 아닙니다. 예측 불가능한 변경과 위기의 파도로부터 우리 프로젝트를 지켜주는 가장 튼튼한 방파제이자, PM인 당신을 보호하는 가장 강력한 무기입니다.
훌륭한 PM은 가장 빠르게 불을 끄는 소방수가 아니라, 애초에 불이 나지 않도록 튼튼하게 건물을 설계하는 건축가에 가깝습니다. '빠른 실행'이라는 조급함을 내려놓고, '올바른 절차'라는 단단한 기반 위에 프로젝트를 세워나가는 것. 이것이 바로 PMI가 원하는 진정한 프로의 모습입니다.
여러분의 회사에서는 '계획'과 '신속한 실행' 중 무엇을 더 중요하게 생각하나요? 계획 없이 시작했다가 위기를 맞았던 아찔한 경험, 혹은 탄탄한 계획 덕분에 위기를 넘겼던 경험을 공유해주세요.
자주 묻는 질문 (FAQ) ❓
Q1. 너무 계획에만 얽매이면 프로젝트가 느려지지 않나요?
좋은 계획은 속도를 늦추는 것이 아니라, 잘못된 길로 가서 시간을 낭비하는 것을 막아 결과적으로 더 빨리 목표에 도달하게 합니다. PMBOK에서 말하는 계획은 한번 정하면 바꿀 수 없는 돌덩이가 아니라, 상황에 맞게 지속적으로 '점진적으로 구체화(Progressive Elaboration)'되는 살아있는 문서입니다. '빨리 가는 것'과 '제대로 가는 것'의 균형이 중요합니다.
Q2. 애자일(Agile) 프로젝트에서도 이렇게 무거운 프로세스를 따라야 하나요?
애자일은 '계획 없음'이 아니라 '변화에 더 잘 대응하기 위한 계획 방식'을 따르는 것입니다. 제품 백로그(Product Backlog)가 바로 살아있는 계획서이며, 백로그에 아이템을 추가하고 우선순위를 조정하는 과정 자체가 공식적인 변경 관리 프로세스입니다. 문서의 형태와 주기가 다를 뿐, 변화를 체계적으로 관리한다는 본질은 동일합니다.
Q3. 모든 변경사항에 변경 요청(CR)을 제출해야 하나요?
아닙니다. 프로젝트의 핵심 기준선인 범위, 일정, 비용, 품질 기준선(Baseline)에 영향을 미치는 모든 변경은 공식적인 변경 요청 및 통합 변경 통제 절차를 따라야 합니다. 그 외 사소한 변경의 처리 기준은 프로젝트 초기에 '변경 관리 계획서'에 미리 팀과 합의해두는 것이 좋습니다.
Q4. 문제 상황에서 어떤 '관리 계획서'를 봐야 할지 헷갈려요.
문제의 키워드를 보면 명확한 힌트를 얻을 수 있습니다. '고객이 새로운 기능을 요구한다' ➜ 범위. '예상치 못한 이벤트가 발생했다' ➜ 리스크. '제품이 요구사항을 충족하지 못한다' ➜ 품질. '예산이 초과될 것 같다' ➜ 원가. 이처럼 문제의 성격과 관리 계획서를 연결하는 훈련이 필요합니다.
Q5. 상사가 자꾸 절차를 무시하고 바로 실행하라고 지시하면 어떡하죠?
PMP 시험의 정답은 '상사의 지시를 무조건 따른다'가 절대 아닙니다. 정답에 가장 가까운 행동은 '해당 지시가 프로젝트의 일정, 비용, 리스크에 미칠 영향을 객관적인 데이터로 분석하여 상사에게 다시 보고하고, 공식 절차를 따르는 것이 장기적으로 프로젝트 성공에 유리함을 설득하는 것'입니다. PM은 프로젝트 목표를 보호할 궁극적인 책임이 있습니다.