PMP 도전기_04

챕터 2 프로젝트 수행의 환경

 

2.1 개요

프로젝트는 환경에 영향을 받으며 진행된다.

두 가지 요소가 있다. 기업 환경요인(EEF)와 조직 프로세스 자산(OPA)로 구분된다. 

거의 대부분의 프로젝트 관리 프로세스의 INPUT으로 활용된다.

 

2.2.1 EEF (기업환경요인)

프로젝트 팀의 통제 하에 있지않으나 프로젝트에 영향을 주거나 제약이 되는 내/외적 요인을 말한다.

기획 프로세스에서는 필수 맛집으로 들어가나 시험에 나오진 않을거같음 ㅇㅇ

 

조직내부와 외부로 나눌 수 있는데, 내부는 뭐 인프라, 직원 능력, 설비 및 자원, 기업 문화등이 여기에 해당된다.

주목해야할 부분은 이해관계자의 리스크 한계선이다. 대충 이해하기로는 부장님 상무님 사장님의 빡침 한계선 정도로 보인다. 프로젝트가 삽을 푸든 인력을 추가로 넣어야 하든 이해관계자(여기서는 상급자로 보임)의 허용한도가 가장 중요한 내부 EEF로 보인다.

 

예를들면 회장님 말씀이라하면 말도 안되는곳에 빅데이터, 인공지능을 어찌저찌 넣는 프로젝트의 경우 프로젝트에 대한 지원이 매우 커서 PM이 업무를 보기에 용이할 수 있다. 물론 매우 힘들 수 도 있다.

정보 기술 SW도 이에 해당되는데 PMIS를 말한다.

 

조직 외부 EEF는 시장 여건, 정치적 변화, 법적 제한, 산업 표준, 근로 조건, 환율 등등이 이에 해당된다. 

이 부분은 EEF임을 정확히 알자

 

2.2.2 OPA (조직 프로세스 자산)

오파는 오빠로 외우기로했다. 조직프로세스 자산이란 조직이 과거 경험했던 지식 기반이기 때문에 내 동생한테 꼰대처럼 말하는 오빠충 멘트를 생각하여 '오빠가~ 옛날에 이거 해봤는데'~로 생각하니 너무 잘 외워졌다.

 

크게 두가지로 나눌 수 있는데 개념은 프로젝트 팀에서 활용하는 조직 내의 프로세스, 정책, 절차 등 축적된 지식기반 전체를 통칭하는 표현이다.

뒷 프로세스에서 자주 나오는 input과 output은 작업 수행 프로세스, 문서 템플릿과 같은 업데이트가 되지않는 정책 및 절차와 과거 프로젝트 기록, 선례 정보(Historical data), 교훈(lessons learned), 형상관리 지식, 이슈 및 결함 관리 지식등이 있다. 이후에 프로젝트 프로세스 output에 변경사항이나 이슈에 대한 보고서, 교훈등은 바로바로 프로젝트 중에 문서 업데이트를 진행하며 프로젝트가 끝난 이후에 OPA에 이관하여 저장한다고 한다. 

 

2.3.1 조직 시스템

프로젝트는 조직 시스템 내의 제약 안에서 운영된다. 

프로젝트 관리자는 조직 내의 담당 업무, 권한 ,영향력, 정치까지 모두 고려하기 위해 조직 시스템을 고려해야 한다.

즉 PM은 두루두루 잘 알아야하고 눈치가 빨라야 한다. 

 

조직 거버넌스 = 구성원의 행동을 결정하고 그 행동에 영향을 주도록 고안된 조직 내 합의사항이 이에 해당된다. 

조직에서 권한이 행사되는 기본 체계로 이해하면 좋다.

프레임워크 = 정책, 절차, 프로세스, 시스템, 규범, 관계 등등 대기업과 스타트업의 거버넌스와 프레임워크가 같을 수 없다. 이런부분들을 전부 조직 시스템으로 이해한다. 조직 체계? 라는 단어로 알면 좋다고 한다.

 

PMP 시험에 나오는 내용은 모든 조직에 효과적인 거버넌스 프레임 워크는 없으며 각 문화와 프로젝트 유형, 요구사항에 맞게 거버넌스가 Tailering 되어야 한다.

구글의 거버넌스 프레임워크를 따른다고 해서 K 구글이 되는 것이 아니라는 말로 이해했다.

 

2.3.2 조직 시스템 유형

 

기능 조직 < 매트릭스 조직 < 프로젝트 기반 조직

이 파트는 표로 정리된 내용을 보면 매우 쉽게 이해가 된다.

위 순서로 PM의 권한이 커진다.

 

(과거 회상)

내가 작년에 했던 PM은 기능 조직 PM이였다. 

PM 권한 수준, 자원 가용성, 예산관리 권한, PM 역할, 프로젝트 관리 행정담당자의 역할 모두 슬픈 수준이였다.

다행스럽게도 프로젝트를 위해서는 이해관계자(상무님들)를 괴롭힐 수 있는 성격과 그걸 또 적당히 받아주시는 상무님들 덕분에 프로젝트는 어찌저찌 마쳤다. 처음에 기획한 설계는 베르사유 궁전이였으나 결과물은 어찌저찌 기능은 하는 콘크리트 건물이 되었다. 어쩌겠나 기존 PM이던 부장님의 퇴사로 데이터 분석가에서 땜빵 PM이 되었다. 그래도 첫 작품치곤 나쁘지 않았다. 유한 성격의 이해관계자들 덕분이라 생각한다. 뭐 결과적으로는 크게 성장할 수 있었던 한 해였다. 이렇게 제대로된 PM, PO가 되기위해 PMP 자격증 준비를 하고 있지않은가? 

 

2.4 PMO 

프로젝트 매니지먼트 오피스의 첫글자를 딴 단어이다. 간단히 설명하면 프로젝트를 지원하는 그런 조직이다. 

비지니스 목표와 연계성을 유지하기 위해 프로젝트 생애주기 전반에 걸쳐 핵심 이해관계자와 함께 의사결정자 역할을 수행하는 권한이 있다.

 

PM이 해결 못하는 상황에서 PMO라는 엘리트 그룹의 지원이 있다면 큰 도움이된다. 

 

PMO의 역할을 묻는 문제는 자주 출제된다고 한다.

모든 프로젝트 전반에 걸친 공유 자원 관리, 프로젝트 멘토링 및 교육, 감독, 프로젝트 관리 방법론 개발 및 채택

전사 관점에서 리스크 관리 수행, 프로젝트 간의 의사소통 조정( 내가하는 프로젝트에 투입되어야 할 자원인 개발자A가 다른 프로젝트 수행으로 나의 프로젝트 수행에 소홀하다면 다짜고짜 옆팀 PM이랑 싸울 것이 아니라 PMO의 중재하에서 진행되어야 한다는 말이다. 작년의 나는 싸우진 못했다. 맨날 유능한 개발자들을 뺏겼다.)

지식 이전 및 OPA 관리 역시 PMO에서 도맡는다. 프로젝트 심사와 감사를 진행하며 프로젝트 드랍에 대한 의사결정 권한을 가지고 있다.

 

PMO는 조직 전체의 목표 달성이 그들의 최종 목표이다. PM보다 더 상위 관리자라 생각하면 된다.