2.2 계획 단계 | 프로젝트 매니지먼트 입문

2.2 계획 단계

프로젝트의 성공은 출발선에서 결정되지 않지만, 실패는 흔히 한 단계로 거슬러 올라갑니다 — 바로 계획 단계입니다. 여기서 프로젝트의 청사진이 그려집니다. 명확함 없이 무작정 달려가면 방향을 잃고, 재작업에 시간을 허비하고, 불필요한 비용이 쌓이게 됩니다.

이 단계의 목적은 무엇을, 언제까지, 누가, 어떻게 할지를 정의하는 것입니다. 큰 목표를 실제로 실행하고 측정할 수 있는 구체적인 계획으로 바꾸는 작업이죠.

계획 단계가 왜 중요한가

주된 목적은 세 가지입니다.

• 프로젝트를 시각화하고 목표까지의 경로를 분명히 그리기
• 이해관계자가 같은 이해를 공유하도록 정렬하기
• 진척을 추적하고 리스크를 관리할 시스템을 구축하기

여러 팀이나 부서가 얽혀 있을 때 특히 중요합니다. 정렬이 단단해지는 곳도, 부서지기 시작하는 곳도 바로 이 단계거든요.

핵심 계획 활동과 산출물

1. 프로젝트 범위 정의

무엇이 포함되고 무엇이 제외되는지 명확히 합니다. 산출물, 품질 기대치, 제약 조건도 함께 다룹니다.

2. 작업 분해 구조도(WBS) 작성

범위를 다룰 수 있는 크기의 태스크로 잘게 나눕니다. 잘 짜인 WBS는 빠지는 일을 막아주고, 일정과 자원 배분의 토대가 됩니다.

3. 프로젝트 일정 수립

WBS를 토대로 태스크 순서, 의존 관계, 기간을 정하고 — 간트 차트나 그에 준하는 타임라인으로 시각화합니다.

4. 자원 배정

각 태스크에 사람, 시간, 스킬, 장비, 예산을 매핑합니다. 과부하 없이 실제로 실행 가능한 현실적인 구성을 목표로 하세요.

5. 리스크 식별 및 대응 계획

잠재 리스크를 나열하고 대응 전략을 지정합니다 — 회피, 완화, 전가, 수용. 선제적 계획은 리스크를 다룰 수 있는 것으로 만들어 줍니다.

6. 커뮤니케이션 계획

누가 무엇을, 언제, 어떻게 공유할지 정합니다 — 미팅 주기와 보고서 템플릿까지 포함해서요. 커뮤니케이션은 프로젝트를 굴러가게 하는 동력입니다.

7. 품질 관리 정의

품질 기준과 그것을 어떻게 검증할지 명확히 합니다 — 리뷰, 테스트, 승인 등을 통해서요. 결과물이 기대치와 어긋나지 않도록 잡아주는 장치입니다.

8. 조달 계획

외주가 필요한 경우, 무엇을 조달할지, 계약 조건, 평가 방법, 그리고 조달 전략을 정의합니다.

주요 산출물 예시

• 프로젝트 매니지먼트 계획서
• WBS 및 태스크 정의
• 간트 차트 또는 프로젝트 타임라인
• 리스크 등록부 및 대응 계획
• 자원 배분 매트릭스
• 커뮤니케이션 계획 / 매트릭스
• 품질 관리 계획

계획 단계에서 주의할 점

• 완벽주의를 피하세요: 계획은 진행하면서 진화합니다. 수정해 나갈 것을 전제로 계획하세요.
• 지나친 낙관을 경계하세요: 실제 데이터와 경험으로 공수와 일정을 추정하세요.
• 실제로 일하는 사람들의 동의를 얻으세요: 그들의 의견이 들어가야 현실적이고 받아들여지는 계획이 만들어집니다.

요약: 계획은 프로젝트의 청사진입니다

이 단계가 프로젝트에 형태와 구조를 부여합니다. 좋은 계획은 팀을 정렬시키고 진척을 안정적으로 유지해 줍니다. 모호하거나 불완전한 계획은 혼선, 재작업, 시간 낭비로 이어집니다.

그래서 이 단계에는 진짜 시간을 들일 가치가 있습니다 — 함께 생각하고, 함께 설계하고, 명확한 길에 합의하기 위해서요. 장기적인 성공을 위해 할 수 있는 가장 좋은 투자입니다.

AB에서는 이렇게 동작합니다

위에 나온 계획 산출물 대부분은 AB Project Management 안에 곧장 자기 자리를 갖고 있습니다.

• WBS → 부모 태스크와 하위 태스크. "하위 태스크 있음" 플래그와 진척 합산이 분해를 모든 레벨에서 눈에 보이게 만들어 줍니다.
• 일정 → 태스크의 마감일과 프로젝트 캘린더가 결합해, 약속을 걸기 전에 병목을 미리 발견하게 해줍니다.
• 자원 배분 → 담당자 필드와 태스크별 견적(기본값 1시간 — 0이 아니라)이 함께 작동하니, 손대지 않은 태스크가 무게 없이 묻히는 일이 없습니다.
• 리스크 등록부 → 프로젝트 위키의 "리스크" 페이지, 또는 "Risk" 타입으로 태깅된 태스크 묶음 — 그러면 각 리스크가 자기 스레드를 갖게 됩니다.
• 커뮤니케이션 계획 → 연결된 Teams나 Slack 채널의 적응형 카드(Adaptive Cards), 그리고 직접 요청용으로는 태스크 멘션.
• 품질 계획 → 리뷰 체크리스트를 하위 태스크로 캡처. "Definition of Done"은 프로젝트 위키에 둡니다.

계획은 한 번 작성하고 잊어버리는 문서가 아닙니다 — 프로젝트 그 자체의 구조이고, 접근 권한이 있는 누구에게나 보이는 살아 있는 형태입니다.

→ 다음: 2.3 실행 단계