PMP - 범위(Scope)

* 범위 관리(Scope Management)는 (1) 일정 / 예산 수립, (2) 품질 관리 (3) 자원 관리 (4) 인력 조달의 기초가 됨.

* 기획
5,1 요구사항 수집: 프로젝트 목적 / 목표를 충족하기 위해 이해관계자의 요구사항을 정의하고 문서화 하는 프로세스.
5.1.1 Input
1) 프로젝트 헌장
2) 아해관계자 등록부
5.1.2 Tool & Technique
1) 인터뷰
- 공식/비공식적으로 준비된 질문/즉흥 질문을 이용하여 이해관계자와 직접 대화를 통해 수집.
- 경험있는 프로젝트 참여자 / 이해관계자 / 해당 주제 전문가들이 인터뷰에 참여하여야 정확한 요구사항을 수집할 수 있다.
2) 핵심 그룹(Focus Group)
: 선별된 이해관계자 / 해당 주제 전문가들이 좌담(Interactive Discussion)형태로 진행 <- 숙련된 조정자 필요(Trained Moderator)
3) 심층 워크샵(Facilitated Workshop): 핵심 복합 기능 이해관계자(Key Cross-Funcional Stakeholder)가 모요서 제품 요구사항을 정의.
- 복합기능 요구사항을 신속하게 정의 하거나, 상반된 이해관계자 의견 조정시 유용.
- 개별 세션보다 휠씬 빠르게 이슈를 발견, 해결 할 수 있다.
4) 집단 창의력 기법(Group Creative Technique)
   (1) Brainstorming: 다양한 아이디어 창출 및 취합에 용이.
   (2) 명목그룹 기법(Nominal Group Technique): 심층 브레인스토밍. 아이디어 도출 및 우선순위 선정을 위해 투표 방식.
   (3) Delphi 기법
   (4) 친화도(Affinity Diagram): 브레인 스토밍으로 획득한 자료를 연관성으로 Grouping하는 기법.
5) 집단 의사결정 기법(Group Decision Making Technique)
- 제품 요구사항 도출 / 분류 / 우선순위 선정 시 사용.
- 만장일치(Unanimity) / 과반수(Majority) / 다수결(Plurality) / 독재(Dictatorship)
6) 설문지 / 설문조사(Questionnaires / Surveys): 대상 응답자가 광범위 하거나, 신속한 자료 수집시 용이. 통계 분석이 가능함.
* 요구사항이 불명확한 경우 사용.
7) 관찰(Observation): 이해관계자가 요구사항 설명을 주저하거나 어려워 하는 경우 사용.
- 개인 환경에서 담당 업무, Task / Process를 수행하는 방법을 직접 관찰 후, 참여 관찰자(Participant observer)가 직접 실행함으로써, 드러나지 않은 요구사항을 식별 할 수 있다.(Job Shadowing)
8) Prototype: 고객의 요구사항이 모호한 경우, 시제품을 개발하여 고객에게 실험할 기회를 제공함으로써, 요구사항에 대한 조기 피드백 가능
- 점진적 구체화 방법(단점: 시간이 오래 소요됨.)
5.1.3 Output
1) 요구사항 문서: 개별 요구사항이 어떻게 프로젝트의 비즈니스 요구사항과 연결되는지 설명
- 요구사항은 명확성 / 추적 가능성 / 완전성 / 일관성 / 수용 가능한 수준이어야 함.
2) 요구사항 관리 계획서: 전체 프로젝트 기간에 요구사항을 분석하여 문서화 하고, 관리하는 방법을 기술한다.
<- 요구사항 변경 시 유용하게 사용됨.
3) 요구사항 추적 매트릭스
- 요구사항을 각 요소(출처:origin)에 연결하여, 프로젝트 Life Cycle동안 추적하는데 활용하는 도표.
- 프로젝트 종료 시: 요구사항 문서에 승인된 요구사항이 인도 되도록 지원
- 제품 범위 변경: 변경을 관리하는데 유용한 도구 이다.

5,2 범위 정의: 향후 프로젝트 관련 의사소통의 기준으로써 상세한 프로젝트 범위 명세서를 개발.
* 범위 정의의 효익
(1) 원가 / 기간 / 자원 산정에 대한 정확성 향상
(2) 성과 측정 / 통제를 위한 기준선 명시
(3) 분명한 책임 배정 가능..
5.2.1 Input
1) 프로젝트 헌장
2) 요구사항 문서
3) OPA
5.2.2 Tool & Technique
1) 전문가 판단
2) 심층 워크샵
3) 제품 분석(분활)
4) 대안 식별
5.2.3 Output
1) 프로젝트 범위 기술서: 미래의 프로젝트 결정과 이해관계자들 간에 프로젝트 범위에 대한 이해를 확인 / 개발하기 위한 문서화된 기초 제공
- 제품 범위 명세서 / 프로젝트 인도물 / 제품 인수 기준
- 프로젝트 요구사항 및 경계 / 프로젝트 제외 사항 / 프로젝트 제약 및 가정 포함.
2) 프로젝트 문서 갱신

5,3 WBS 생성: 주요한 프로젝트 인도물(Deliverable) 기준으로 작업을 관리 가능한 수준으로 분할.
5.3.1 Input
1) 프로젝트 범위 기술서
2) 요구사항 문서
3) OPA
5.3.2 Tool & Technique
1) 분할(Decomposition): 인도물(Deliverable)들이 프로젝트 활동 개발을 지원할 수준으로 정의될 때까지 작고 / 관리 가능한 요소로 분할 한다.
* 수행 절차
(1) 식별: 프로젝트 주요 인도물을 식별
(2) 검증: 적합한 원가 / 지속 기간을 산정할 수 있을지를 검토
(3) 재식별
(4) 검증: 역방향 검증을 통해 누락 / 중복 여부 확인.
5.3.3 Output
1) WBS 사전: WBS 구성요소에 대한 상세한 설명을 제공
- 관리 작업 단위 식별 코드(Code of Account) / 작업 설명 / 담당 조직
- 일정 마일스톤 목록 / 연관된 일정 활동 / 필요한 자원 / 원가 산정치
- 품질 요구사항 / 인수기준이 상세하게 설명되어 짐.
2) 범위 기준선
- 프로젝트 범위 기술서 + WBS + WSB 사전3) 프로젝트 문서 갱신

* WBS(Work Breakdown Structure) - WBS는 산출물 / 인도물의 집합체. - Project Management Plan 작성도 WBS에 포함되어야 함. - All the work / Only the work: 모든 작업은 WBS화 해야 하며, WBS에 없는 일을 해서는 안된다. - WBS의 최하위는 인도물 / 산출물로 정의되어야 함(=Work Package)    (1) WBS의 최하위 수준    (2) 산출물로 정의    (3) Sub Project에서는 Work Package를 분할할 수 있음.    - Project의 특정 Work Package의 인도물을 외부업체에 의뢰한 경우(외부 업체 입장에서는 신규 프로젝트가 됨으로 분활) * WBS는 프로젝트의 전체 범위를 조직 / 구성하는 프로젝트 요소들을 산출물 지향적으로 집단화 한 것 - WBS의 3요소 1) Work Package: WBS의 최하위 구성요소로 산출물. 2) Code Of Account: Work Package를 식별하는 고유 식별자. 3) WBS 사전: 산출물 생성을 위해 수행하는 Task 명칭 / 내용 / 시기등을 기술한 문서 - WBS는 단순 인도물 / 산출물의 이름으로만 명시되어 있기 때문에 WBS 사전이 필요. - Work Package의 기능 / 비기능 정의, 원가 / 기간 산정치 / 인수기준 명시 - WBS 생성 Rule 1) 80Hr(2weeks): Work Package당 최대 기간 2) 40Hr(1week): Work PAckage당 최소 기간 3) 3~6 개월: Rolling Wave Planning 방식으로 점진적으로 구체화해야 함. - 아직 Work Package화 되지 않은 요소. 향후 Work Package화 되는 요소를 Planning Package라 함. * RAM(Responsibility Assignment Matrix): 책임 할당 매트릭스 => WBS + OBS * WBS는 - 품질 계획의 기본 토대 / 본질적으로 도구이지 목표가 아니다. 다양하게 사용된다. - 일정이 아니다. 효과적인 팀 구성 도구 이다.

* 감시 / 통제
5,4 범위 검증: 프로젝트 관리 계획서에 정의된 성과 목표를 달성하기 위해 1) 프로젝트 진행을 추적 2) 검토 3) 조정하는 프로세스
5.4.1 Input
1) 프로젝트 관리 계획서
2) 성과 보고서: 성과, 마일스톤, 식별된 이슈, 문제점 등이 자세히 기술되어 있다.
3) OPA
4) EEF
5.4.2 Tool & Technique
1) 전문가 판단
5.4.3 Output
1) 인수된 인도물: 인수기준을 충족하는 인도물은 고객 / 스폰서가 공식적으로 서명.
2) 변경요청: 완료되었지만 인수되지 않은 인도물을 인수거부 사유와 함께 문서화.
- 통합 변경 통제 프로세스에서 검토 / 처리 됨.
3) 프로젝트 관리 계획서 갱신

5,5 범위 통제: (1) 프로젝트 / 제품 범위 상태 감시 / (2) 범위 기준선에 대한 변경 관리
* 범위 통제는 반드시 다른 통제 프로세스(일정 통제 / 원가 통제 등)와 완전히 통합되어 수행되어야 한다.
5.5.1 Input
1) 프로젝트 관리 계획서
2) 요구사항 문서 / 요구사항 추적 매트릭스
3) OPA
5.5.2 Tool & Technique
1) 차이분석: 기준선에 대한 차이의 발생 이유를 판별, 차이에 대한 예방 / 시정 조치가 필요한지 결정.
* 목표 관리(MBO: Management By Object) - SMART
- S: Specific(명확)
- M: Measurable(측정가능)
- A: Attainable(성취가능)
- R: Reality(현실적)
- T:Timely(주기적 점검을 통해 수정)
5.5.3 Output
1) 작업성과 측정치
2) 변경요청
3) 프로젝트 관리 계획서 / 프로젝트 문서 수정