PMP - 통합

* 착수
4,1 프로젝트 헌장 개발(Project Chapter)
: 프로젝트 / 단계(Phase)를 공식적으로 승인하고, 이해관계자(stakeholders)의 초기 요구사항을 문서화 하는 프로젝트 헌장 개발.

* Project Chapter 1) 프로젝트 헌장은 프로젝트를 공식적으로 승인하는 문서. 2) PM에게 프로젝트 활동을 위해 조직 자원을 승인해 주는 기능 제공. 3) PM은 프로젝트 관리 기획(착수) 전이나 프로젝트 헌장이 작성될 때 임명되어야 한다. - 늦어도 실행단계 시작전(기획단계 완료전)에는 임명 되어야 한다. 4) PM이 변경되면 프로젝트 헌장도 변경되어야 한다. 5) 프로젝트 헌장에는 Project의 궁국적인 목표 / PM 권한 및 책임이 명시 6) Sponsor(후원자)가 직적 서명해야함.

4.1.1 Input
1) 프로젝트 작업 기술서(SOW: State Of Work)
- 프로젝트의 인도물인 제품이나 서비스를 설명.
   (1) 사업요구(Business Needs)
   (2) 제품 범위 명세서(Product Scope Description): 제품 / 서비스이 요구사항. <- 프로젝트 life cycle에 따라 점진적으로 상세화됨.
   (3) 전략 계획(Strategic Plan): 프로젝트의 방향성 제시. 의사결정에 영향을 미친다.
2) 비즈니시 케이스(Business Case): 비즈니스 요구와 원가 편인 분석을 통해 프로젝트 타당성 여부 결정시 사용.
3) 계약서 - optional
4) EEF(Enterprise Environmental Factors: 기업환경요인) - 상용 데이터 베이스, 프로젝트 관리 정보시스템(PMIS)
5) OPA(Organizational Process Assets: 기업 프로세스 자산)
- 지식기반 OPA: 교훈, 프로젝트 파일, 선례정보 등.
- 작업 수행을 위한 조직의 프로세스와 절차.
- KMS(Histronical Information / Lesson Learned)
4.1.2 Tool & Technique
1) 전문가 판단(Expert Judgment)
- Top Down 방식(대표적인 방법으로는 Delphi 기법)

* Delphi 기법 - 전문가 판단의 익명성 보장. - 반복적으로 실행함으로써 전문가 집단의 수렴된 의견 반영

4.1.3 Output
1) 프로젝트 헌장
: 비즈니스 요구, 현재 파악된 고객의 요구, 인도물(제품/서비스/결과)를 기술한 문서.
- 프로젝트 목적 / 측정가능한 목표 및 성공 기준 포함.
- 상위수준의 요구사항 / 상위 수준의 프로젝트 설명 및 리스크 포함.
- 마일스톤(Milestone) 요약 설명, 예산 요약, 프로젝트 승인 요구사항 포함.

* 기획
4,2 프로젝트 관리 계획서 개발
: 모든 보조 계획(각 영역별 계획서)를 정의, 준비, 통합, 조정 하는데 필요한 조치를 문서화.
- 프로젝트 관리 계획서 개발 단계에서는 3 constraints(범위 / 일정 / 원가)의 계획서의 정의를 포함한다.
4.2.1 Input
1) 프로젝트 헌장
2) 각 영역별 산출물
3) EEF
4) OPA
4.2.2 Tool & Technique
1) 전문가 판단
4.2.3 Output
1) 프로젝트 관리 계획서

* 프로젝트 관리 계획서 수립 방법

- Progressive Elaboration: 프로젝트는 점진적으로 구체화 된다. 
- Rolling Wave Planning 방식: 일정이 가까운 계획은 상향식으로 작성하고, 먼 계획은 하향식 접근을 적용한다.
- 상향식(Bottom-up): 구체적인 요구사항에 의해 작성되는 상세 수준 계획. 계획의 신뢰성은 높으나 시간이 오래 소요됨.
- 하향식(Top-Down): 상위 수준 계호기 수립시 용이, 비용 / 일정 목표를 맞추기 위해 적용, 작성이 쉽고 비용이 적게 들지만 정확성이 낮음.






* 참고<Project Life Cycle별로 PM의 Leadership이 변경됨>
=> Directing(지시형) -> Coaching(지도형) => Supporting(협조형) => Delegating(위임형)
|--> 프로젝트 초반 -------------> 프로젝트 중반 --------------> 프로젝트 후반 --->|

* 실행
4,3 프로젝트 실행 지시 및 관리
: 프로젝트 관리 계획서에 정의된 작업 수행 -> 이중적 활동의 수행(관리 방법론 + 개발 방법론)

1. Project 관리 프로세스: 프로젝트 관리팀에 의해 프로젝트 관리 계획상의 활동 수행.
2. 제품 지향적 프로세스: 프로젝트 범위 명세서상 활동을 프로젝트 수행팀에 의해 실행.

4.3.1 Input
1) 프로젝트 관리 계획서
2) 승인된 변경 요청: 예방 조치 / 시정조치를 위해 통합 변경 통제 수행 프로세스에서 승인된 변경 요청사항 수행하기 위함.
3) OPA
4) EEF
4.3.2 Tool & Technique
1) 전문가 판단
2) PMIS - 시스템을 통해 관리하겠다는 전략
4.3.3 Output
1) 인도물: 유일하고 검증 가능한 제품, 결과 또는 서비스 수행 능력(Capacity)
2) 작업 성과 정보(Work Performance Information)
- 범위: 인도물의 상태, 일정: 일정 진행률, 원가: 발생한 비용
3) 변경 요청
4) 프로젝트 관리 계획서/프로젝트 문서 갱신

* 감시 / 통제
4,4 프로젝트 작업 감시 및 통제
: 프로젝트 관리 계획서에 정의된 성과 목표를 달성하기 위해 1) 프로젝트 진행을 추적 2) 검토 3) 조정하는 프로세스
4.4.1 Input
1) 프로젝트 관리 계획서
2) 성과 보고서: 성과, 마일스톤, 식별된 이슈, 문제점 등이 자세히 기술되어 있다.
3) OPA
4) EEF
4.4.2 Tool & Technique
1) 전문가 판단
4.4.3 Output
1) 변경요청: 시정조치 / 예방조치/결함 수정
2) 프로젝트 관리 계획서 갱신
3) 프로젝트 문서 수정
4,5 통합변경통제 수행
: 인도물 / OPA / 프로젝트 문서 / 프로젝트 관리 계획서에 대한 1) 변경을 검토, 2) 변경사항 승인/거부 3) 변경 관리하는 프로세스
4.5.1 Input
1) 프로젝트 관리 계획서
2) 변경 요청
3) 작업 성과 정보
4) OPA
5) EEF
4.5.2 Tool & Technique
1) 전문가 판단
2) 변경 통제 회의(CCB): 변경 요청에 대한 승인 / 거부의 의사결정이 이루어짐.
4.5.3 Output
1) 변경 요청 상태 정보 갱신
2) 갱신된 프로젝트 관리 계획서 / 문서

* 종료
4,6 프로젝트 / 단계(Phase) 종료
: 행적적 종료에 필요한 모든 활동 및 단계별 방법론
- 완료 / 종료 기준을 충족하는 데 필요한 조치 / 활동
- 다음 단계 / 운영으로 인계하는데 필요한 조치 및 활동
- 프로젝트 / 단계 기록을 수집하고 프로젝트 성공 / 실패를 평가하여 습득한 교훈을 수집하여, lesson learn 갱신

* 변경 요청 처리 하는 방법 1) 고객으로 부터 변경 요청 - 종료 시점이 아닌 경우: 변경 요청 -> 변경에 따른 영향 분석 -> 고객 협상 -> CCB 요청 - 종료 시점인 경우: 변경 요청 -> 추가 계약 유도 2) sponsor로 부터 변경 요청 - 종료시점: 변경 요청 -> 대안 작성 및 보고 -> CCB(승인/거부) -> 이행

4.6.1 Input
1) 프로젝트 관리 계획서
2) 인수된 인도물: 범위 검증 프로세스에 의해 인수된 인도물
3) OPA: project / phase 종료 지침, 요구사항, 습득한 교훈 지식 기반과 선례정보
4.6.2 Tool & Technique
1) 전문가 판단
4.6.3 Output
1) 최종 제품 / 서비스 / 결과물 이전[인도물:Deliverables] <- 최종 검수 요청은 반드시 PM이 고객과 수행하여야 한다.
2)  OPA 갱신
   (1) 교훈 정리: lesson learned(프로젝트 수행 시 성공 / 실패를 논의)
   (2) 산출물 정리(packaging)하여 PMO에 이전
   (3) 팀원 해체 / 재조직 <- 이 시점이 프로젝트가 공식적으로 종료된 시점 임.