PMP 도전기_02

PMBOK GUIDE 구성

챕터 1, 서론

챕터 2, 프로젝트 운영 환경

챕터 3, 프로젝트 관리자의 역할

챕터 4 ~ 13 프로젝트 관리 지식영역

 

챕터 4부터 13에서 거의 대부분의 문제가 나온다. 

해당 챕터는 챕터 4와 나머지 챕터로 나눌 수 있다.

챕터 4는 Intergration Management(통합 관리)로 아래 챕터 5~ 13까지의 내용을 통합하여 관리한다는 내용이다.

따라서 PM은 챕터 5부터 13까지의 관리 지식영역을 어느 한쪽에 치우치지 않게 통합적으로 관리하여 프로젝트 수행을 해야 한다.

 

이 블로그는 내가 복습겸 공부하려고 작성하는 메모 개념이기 때문에 유저 프렌들리 하지않다. 

시험 합격이후 뭐 언젠가는 다시 정리할 예정이다. 그래서 영문도 그냥 발음대로 갈겨 쓸 생각이다.

 

챕터 4, 통합 관리

챕터 5, 범위 관리

챕터 6, 일정 관리

챕터 7, 원가 관리

챕터 8, 품질 관리

챕터 9, 자원 관리

챕터 10, 의사소통 관리

챕터 11, 리스크 관리(위험 관리)

챕터 12, 조달 관리

챕터 13, 이해관계자 관리

 

챕터 5~13은 보조관리영역으로 부른다.

 

- 프로젝트 정의

프로젝트는 유일한 제품/서비스/결과를 만들기 위하여 수행되는 한시적 노력이다.

여기서 포인트는 유일성한 프로덕트를 만든다는 점, 한시적인 노력이라는 점, 그리고 변화 ASIS -> TOBE가 있어야한다는 점, 마지막으로는 비지니스 가치를 창출해야 한다는 점이있다.

 

완벽한 프로젝트를 수행했다고 하여도 비지니스 가치를 창출하지 못한 프로젝트는 성공이라 할 수 없다.

 

- 프로젝트 관리

프로젝트 요구사항을 만족시키기 위하여 각종 지식, 기법, 도구를 프로젝트 활동에 적용하는 것을 말한다.

프로젝트 관리는 조직이 프로젝트를 보다 효과적이고 효율적으로 수행하도록 지원한다.

 

- 프로그램 관리

프로젝트의 상위 개념으로 개별적으로 관리해서는 가치를 달성할 수 없는 연관 프로젝트를 관리하는 것을 의미한다. 회사에서는 부서장급의 레벨이 하는 업무이다.

주의 사항은 특정 목표를 달성하기 위해 필요한 프로젝트간 상호 연관성(상호의존관계)를 관라한다.

예를들면 공유 일정 관리나 리스크 및 이슈등을 관리하는 것이 프로그램 관리의 방법이다.

 

- 포트폴리오 관리

프로그램, 프로젝트의 상위 개념으로 조직의 전략적 목표를 달성하기 위해 하나의 그룹으로 관리하는 운영의 집합을 말한다. 보통 C클래스가 하는 업무를 말한다.

투자 타당성 평가를 통한 적합한 프로젝트/프로그램인지를 판단하고 투자대비 성과 측정을 통한 성공여부 측정을 진행한다.

 

- 운영 관리

운영 관리는 프로젝트가 끝난 이후 프로덕트의 지속적인 생산과 유지와 연관이 있는 범위로 현업에서는 여기도 매우매우 중요하지만 PMP 시험 범위 외이기 때문에 글을 줄인다.

 

- 프로젝트 생애 주기 PLC 

 

PLC PLC 요즘 노래를 부르는 회사들이 많다. 이번 기회에 제대로 개념을 장착하고 가게 될 것 같다.

프로젝트 착수부터 종료까지 거쳐가는 일련의 단계(Phase)의 집합이다.

제품 생애 주기와는 전혀 관계없는 개념이다. 오해 ㄴㄴ 

 

일반적인 특징은 프로젝트 진행 단계에 따라 불확실성과 이해관계자의 영향력의 변화를 알둘 필요가 있다.

 

- 개발 생애주기 DLC 

프로젝트 생애 주기 내에는 프로덕트 개발과 연관된 하나 이상의 단계가 있으며 이를 개발 생애 주기라 한다.

개발 생애 주기는 다음과 같은 5가지 모델로 구성될 수 있다. 사실은 더 많다~ 

 

워터폴 방식 (예측형 생애주기)

애자일 방식 (반복적, 점증적, 적응형)

하이브리드 방식 (혼합형)

 

이 부분은 매우 중요하여 필기로 공부함~ 

놀라웠던 점은 애자일 방식의 두가지 원칙이였다.

1) 이해관계자의 요청사항을 최대한 반영한다. (고객/사용자 지향) -> 이건 워낙 유명하니까~ 알았다.

2) Iteration으로 정한 기간은 절대 지연하지 않는다. (스프린트 일정의 철저한 통제)

솔직히 현실 애자일에서는 스프린트 일정을 철저하게 통제하기가 쉽지 않다. 일반적으로 고객님에게 요구사항과 피드백을 받기 시작하면, 10중에 5는 아침의 요구사항과 저녁의 요구사항이 달라지는 경우가 왕왕 발생한다. 애자일 사상에 따르면 이를 최대한 받아들여야 한다고 하는데 ㅎ... 그래서 최근 나온 프로젝트 오너, 기획자 책을 보면 고객이 진정으로 원하는 가치란 무엇인가? 기저에 깔려있는 숨은 요구사항을 실체화하는 역량이 매우 중요하다고 강조되고 있다.

뭐 너무나 당연한 말이지만 말이다. 고객이랑 내적 친밀감을 어떻게 형성하는가가 포인트가 아닌가 싶다.

조금 멋있게 말하자면 라포형성이 될 것이고 친숙하게 말하자면 한숨 돌리면 맥주도 한 잔하고 공감대를 찾아 떠들다보면 이해기반의 신뢰관계가 형성된다.

 

2022년에 맡게 되는 프로젝트의 경우 워터폴이 아닌 하이브리드 방식으로 진행 할 계획이다.

애자일의 회고, 반복 검증, 데일리 스탠드업과 같은 개념을 도입하고자 한다. 그리고 최대한 요구사항을 세분화하여 그 안에서 MVP 개발과 반복 검증을 진행하는 방향으로 프로젝트를 이끌고 싶다. 물론 Servant형 PM이 되어 작년보다 더 열정적으로 격렬하고 디자이너와 개발자, 고객 사이에서 눈치게임과 리더쉽을 발휘해야 가능한 방식이이다.

작년 프로젝트 수행에도 분명 애자일로 했을 경우 시행착오를 줄일 수 있는 프로덕트가 있었다.

 

개발생애주기 유형의 비교에 대해서는 읽고 읽다보니 자연스럽게 이해가 되었다.

 

- 프로젝트 단계(페이즈)

프로젝트 단계는 논리적으로 연관 된 프로젝트 활동들로 구성되며 한가지 이상의 인도물이 완성되면서 종료된다.

프로젝트 단계는 다양한 요인을 기준으로 설정되며 여러 개의 별도 단계나 허위 요소로 구분될 수 있다.

단계 종료 시 프로젝트 성과와 진척을 판단해야 하며, 의사결정(수정, 진행, 중단)을 위해 단계 심사를 거친다.

 

- 프로젝트 관리 프로세스 그룹

착수 -> 기획 <-> 감시 및 통제 프로세스 <-> 실행 -> 종료 

총 49가지의 프로젝트 방법을 5가지 프로세스 그룹으로 분류가 된다.

 

- 프로젝트 관리 데이터 및 정보

 

작업 성과 데이터 (WPD) 

프로젝트 작업을 수행하면서 얻어지는 실제 관찰 & 측정 데이터를 의미한다.

 

작업 성과 정보 (WPI)

개별 통제 프로세스에서 얻어진 성과 정보, 분석 및 예측 정보를 의미한다.

-> WPD에서 얻어진 로우 데이터를 1차 가공을 하여 정보(KPI, %, 현황, 진행상태)로 가공된 것을 의미한다.

 

작업 성과 보고서 (WPR)

의사결정, 이슈제기 등을 목적으로 작업 성과 정보를 종합한 보고서나 대시보드를 의미한다.

 

 

- 프로젝트 관리 비지니스 문서

비지니스 문서란 프로젝트가 비지니스 목표로 어떤 방법으로 기여해야 할 지를 결정하는데 고려하는 문서이다.

프로젝트 착수 이전에 개발되고 착수~종료까지 지속적인 검토 대상이되는 문서이다.

1) 비지니스 케이스 (경제적 타당성, 프로젝트 목표, 이유, 비용-편익 분석)

프로젝트 GO or No decission에 대한 의사결정에 활용

작성을 위해 요구 평가(needs assessment)가 선행되어야한다.

비지니스 목표 및 목적, 이슈와 기회, 권고사항이 포함되어 있다.

비지니스 케이스 개발 및 유지 책임은 고객사(스폰서)에개 있다.

 

2) 편익 관리 계획서 (