PMBOK 7판의 집필관점
《PMBOK지침서 》7판은 <프로젝트관리 표준(The Standard for Project Management)>와 <PMBOK 가이드(A Guide to the Project Management Body of Knowledge)>로 구성된다.≪PMBOK 지침서≫7판의 구성체계를 정리하면 아래 그림과 같다.
[그림. ≪PMBOK 7판≫의 구성체계]21년 8월에 발간된 ≪PMBOK 지침서≫7판은 이전 버전과 비교해 볼 때 내용과 형식이 혁신적으로 바뀌었다. ≪PMBOK 지침서≫ 7판의 변경내용을 ‘애자일 선언’의 형식으로 정리하고자 한다. 애자일 선언의 각 내용은 두 개의 문장으로 구성되며, 왼쪽의 문장보다 오른쪽의 문장이 중요하다는 형식을 취하고 있다.왼쪽의 문장이 잘못되었다는 것은 아니기 때문에, 4년 전의 ≪PMBOK 지침서≫의 내용이 틀린 것은 아니다. 아래 내용들은 PMI가 어떤 의도나 관점을 가지고 ≪PMBOK 지침서≫ 7판을 집필했는지를 생각하면서 읽어보기 바란다. 저자의 의도를 알아야 학습이 쉬울 뿐 아니라 시험에서 정답을 선택할 가능성이 높아진다.
① 프로세스를 분석하는 것보다, 원칙에 대한 이해를 중요하게 생각한다.
≪PMBOK 지침서≫ 6판은 10개의 지식영역, 49개의 프로세스로 구성되었으며, 각 프로세스는 다시 투입물, 도구 및 기법, 산출물로 정리하였다. 프로젝트 관리활동을 프로세스 형태로 정리한 이유는 다음과 같다.
- 이해하기 쉽고 익숙한 형식이다.
대부분의 조직에서 사용하는 프로세스(업무) 매뉴얼은 프로세스를 계층적으로 나열한 뒤 최하위 프로세스는 투입물, 도구 및 기법, 산출물의 형식으로 정리한다. 이전의 ≪PMBOK 지침서≫는 이러한 형식으로 프로젝트 관리 활동을 설명했다. 이전 버전의 ≪PMBOK 지침서≫를 학습했던 수험생들은 프로세스 들의 투입물, 도구 및 기법, 산출물을 이해하고 암기하는데 많은 시간을 소모했다.
- 프로젝트 관리 활동의 순서를 설명하기 쉽다.
초보 프로젝트 관리자에게 프로젝트 관리활동을 설명하기 위해서는 ‘어떤 활동을 어떤 순서로 수행하라’는 형식이 직관적이다. 프로젝트 관리활동을 프로세스 형태로 정리하면 흐름도(flow chart) 형식으로 활동순서를 정의할 수 있다. 예들 들어 ‘프로젝트 범위 정의 → 활동 정의 → 활동순서 정의 → 활동수행을 위한 자원 정의 → 활동수행을 위한 예산 정의’와 같은 방식으로 프로젝트 계획수립을 설명하는 식이다.
≪PMBOK 지침서≫7판은 <프로젝트 관리 표준>에서 12개의 원칙을, <PMBOK가이드>에서 8개의 ‘성과도메인(Performance Domain)’을 제시한다. 프로젝트 목표달성을 위해 유사한 관리활동을 8개의 성과도메인으로 정리했지만 프로세스 흐름도, 도구 및 기법, 산출물과 같은 상세내용은 없이 핵심개념만 설명한다. 12개 원칙과 8개 성과영역의 내용을 이해하고 이에 맞는 모델, 기법, 산출물을 선택하라는 메시지다. PMI는 다양한 프로젝트의 다양한 프랙티스를 온라인에서 제공하기 위해 ‘PMIstandards+’라는 디지털 콘텐츠 플랫폼도 개발하였다.
PMI가 ≪PMBOK 지침서≫ 7판에서 설명하기도 쉽고 학습하기에도 용이한 프로세스 형식을 버리고, ‘원칙’이나 ‘마인드 셋’ 중심의 형식을 채택한 이유는 무엇일까? 그것은 현실에서 접하는 프로젝트 상황(조직문화, 프로젝트 관리성숙도, 프로젝트 중요도, 위험에 대한 수용, 이해관계자의 참여형태, 기술의 복잡도 등)이 달라 프로젝트 관리활동을 하나의 정답으로 제시하기 힘들기 때문이다. 이러한 상황을 맥락(context)이라기도 한다. 프로젝트 맥락에 따라 적합한 개발전략, 프로세스, 산출물이 달라진다. 예를 들어 대규모의 데이터센터를 구축하는 프로젝트와 작은 규모의 온라인 쇼핑몰을 구축하는 프로젝트의 관리방식은 달라야 한다. 이 둘을 동시에 설명할 수 있는 하나의 프로세스는 없다.
애자일의 마인드셋을 설명하는 ‘being 애자일’과 애자일을 실천 프랙티스를 설명하는 ‘doing 애자일’이 있다. 사람들은 ‘내가 무엇을 하면 되는지’를 원하지만, 모든 상황에 그대로 적용할 수 있는 상세 프랙티스는 드물다. ‘어떻게 하면 프로젝트를 성공할까’라는 질문은 ‘어떻게 살면 행복해질까?’만큼이나 다양한 정답이 있다. 사람마다 행복의 방정식이 다르듯이 프로젝트마다 성공의 방정식이 다르다고 해도 과언이 아니다.
그러나 철학자들이 행복한 사람들의 삶에서 공통적인 가치를 찾아내듯이 성공하는 프로젝트에서도 공통적인 원칙은 있을 수 있다. 원칙이나 마인드 셋을 정확하게 이해해야 다양하고 급변하는 프로젝트 상황에서 정답에 가까운 프랙티스를 결정할 수 있다. 예전의 PMBOK은 구체적인 프랙티스를 제시하려고 노력했다고 하면 지금의 PMBOK은 프로젝트에 적용할 프랙티스 선택을 독자에게 넘긴다. PMI는 복잡하고 다양한 프로젝트 상황을 하나의 프로세스로 설명해야 하는 부담에서 벗어났지만, 수험생은 원칙기반의 ≪PMBOK 지침서≫를 이해하여 시험에서 주어진 상황에서 구체적인 선택을 해야 하는 부담이 생겼다.
첫 번째 변경내용은 다음과 같이 요약할 수 있다.
프로세스를 분석하는 것보다, 원칙에 대한 이해를 중요하게 생각한다.
→ 원칙에 대한 이해를 기반으로 상황에 맞는 프로세스를 만들 수 있어야 한다.
② 산출물(deliverables)보다, 가치(value)를 중요시한다.
이전 ≪PMBOK 지침서≫에서도 프로젝트 결과물이 제공하는 가치가 산출물보다 중요하다고 강조하였다. 그러나 49개 프로세스에서 작성해야 하는 산출물의 종류와 내용 설명에 많은 분량을 할애하였지만 가치창출에 대한 내용은 아주 일부였다.
모든 프로젝트는 이전에 없던 가치를 창출하기 위해 수행한다. 따라서 프로젝트 관리는 보다 많은 가치를, 보다 작은 비용으로, 보다 빨리 제공하는 것에 집중해야 한다. 가치는 가치를 인정하는 사람이 있어야 한다. 고객, 사용자, 내부 이해관계자, 외부 이해관계자 등 사람에 따라 프로젝트의 가치는 달라진다. 프로젝트가 목표로 한 산출물을 일정 내에, 예산 내에 만든다고 프로젝트가 성공하는 것이 아니다. 그 산출물이 목표로 하는 가치를 창출해야 한다. ≪PMBOK 지침서≫7판에서는 가치창출 강조하기 위해 PMO(Project Management Office)를 VDO(Value Delivery Office)로 부르기도 한다.
프로젝트가 제공하는 가치는 세 가지로 구분할 수 있다.
- 고객에게 제공하는 가치 (Customer value)
기업이 고객에게 제공하는 제품이나 서비스에 내재된 유용성 또는 쓸모를 의미한다.
- 기업에게 제공하는 비즈니스 가치 (Business Value)
프로젝트 수행결과 원가 절감, 매출 또는 이익 향상과 같은 비즈니스 성과를 의미한다.
- 환경, 지역사회, 커뮤니티에 제공하는 사회적 가치(Social value)
최근 기업의 친환경, 사회적 책임이 강조되고 있다. 프로젝트 수행을 통해 친환경 또는 지역사회와 커뮤니티에 기여하는 가치를 의미한다.
가치를 높이는 한 가지 방안은 낭비를 줄이는 것이다. 린(lean) 개발에서는 고객에게 가치를 제공하지 않는 모든 활동은 낭비로 정의하고 있다. 린 스타트업, 애자일에서는 가치창출 관점의 프랙티스를 많이 개발하였다. ‘가치 흐름도(Value streaming map)’’최소 존속제품(MVP, Minimum Viable Product)’’스크럼’이 대표적인 예이다.
현실 프로젝트 관리 활동의 의사결정이나 시험에서 정답을 선택하기 위해서는, 이해관계자와 고객에게 제공하는 가치의 효과성과 효율성 관점에서 판단해야 한다. 가치의 효과성은 가치의 쓸모를 의미하고, 가치의 효율성은 가치획득을 위한 비용을 의미한다. 제품을 구매하는 사용자 관점에서 ‘가치’는 ‘편익(benefit)-가격’이다. ≪PMBOK 지침서≫7판에서는 가치와 유사한 의미로 ‘의도한 결과물(intended outcomes)’을 사용한다.
③ 하드 스킬보다 소프트 스킬을 중요시한다.
하드 스킬은 논리적 분석 모델을 활용하여 정답을 찾는 기법들이다. 주 경로(Critical Path), 획득가치 분석(Earned Value Analysis)이 대표적인 예이다. 소프트 스킬은 리더십, 이해관계자 관리와 같이 상황에 영향을 받기 때문에 정답이 없다. PMBOK 개정6판의 10개 지식영역(Knowledge Area)중 핵심(Core) 지식영역으로 분류되었던 범위, 일정, 원가 지식영역은 하드 스킬을 중심으로 기술되었다. ≪PMBOK 지침서≫ 7판에서는 지식영역을 8개 성과도메인(Performance Domain)으로 바꾸었는데 성과도메인중 범위, 일정, 원가는 사라졌다. 대신 지식영역의 마지막이었던 ‘이해관계자 관리’가 성과도메인의 첫번째로 위치한다. 시험에서도 계산문제의 출제비중은 줄어들 것으로 보인다.
프로젝트 관리자가 하드 스킬을 잘 몰라도 프로젝트는 성공적으로 관리할 수 있다. 반면 소프트 스킬이 미흡한 프로젝트 관리자는 프로젝트 관리에 실패할 가능성이 높다.
④ 유형의 제품(예:건축물)을 개발하는 프로젝트 보다, 무형의 소프트웨어를 개발하는 프로젝트를 전형적인 프로젝트로 설정한다.
건설, 영화, 게임, 의약, 온라인 쇼핑몰, 국가행정, 가전제품, 자동차등 모든 업종의 제품과 서비스는 프로젝트 수행의 결과물이다. 그러나 업종에 따라 프로젝트를 수행하는 방식, 사용하는 용어는 다르다. 프로젝트 관리활동에 대한 표준과 가이드를 설명하는 ≪PMBOK 지침서≫는 가장 일반화된 업종의 프로젝트 관리 용어나 개념을 선택할 수 밖에 없다.(물론 ≪PMBOK 지침서≫의 내용은 모든 업종의 모든 프로젝트에 적용 가능하다.) 건설은 인류에게 가장 익숙한 업종중 하나로 고대 피라미드부터 시작하여 현대의 초고층 빌딩까지 지속되고 있다. 그 결과 90년대 ≪PMBOK 지침서≫는 건설업종의 프로젝트 관리 내용을 주로 반영했고, PMP 자격취득도 건설사 직원들이 중심이었다. 건설 프로젝트 관리의 특징은 복잡한 활동을 순차적으로 수행하는 계획을 수립하고 통제하는 것이었는데, 그 내용을 반영하다 보니 ≪PMBOK 지침서≫의 프레임웍(framework)은 프로세스 중심이었다.
2010년 후반기 이후에는 AI, 빅 데이터, 클라우드 기술을 기반으로 4차 산업혁명이 많은 업종에 영향을 끼쳤고 이러한 추세는 디지털 전환(Digital Transformation)으로 이어져 거의 모든 업종에 확산되고 있다. 그 결과 자동차, 가전제품, 유통, 의료 등 거의 모든 업종의 제품과 서비스에서 소프트웨어가 차지하는 비중이 높아지고 있다. PMI도≪PMBOK 지침서≫6판(2017년)에서 소프트웨어 개발에서 사용하는 애자일 개념을 반영하기 시작해서, ≪PMBOK 지침서≫7판(2021년)에서는 애자일 개발의 원칙과 프랙티스를 중심으로 서술하고 있다. 따라서 ≪PMBOK 지침서≫를 학습하는 수험생들은 본인이 경험했던 프로젝트의 내용보다 앱 개발, 온라인 쇼핑몰 개발, 기업의 전산시스템 구축과 같은 소프트웨어 기반의 제품이나 서비스 개발을 염두에 두고 ≪PMBOK 지침서≫를 학습하는 것이 효과적이다.
≪PMBOK 지침서≫7판의 혁신적 변경을 초래한 소프트웨어 제품 개발의 특징은 다음과 같다.
- 잦은 출시로 개발주기가 짧아져 전통적인 계획과 통제 프로세스 적용이 어려워졌다.
≪PMBOK 지침서≫7판 이전에는 착수시점에 계획을 수립하고, 진행과정에 변경을 통제하고, 종료시점에 결과물을 제공하는 방식으로 프로세스를 설명했었다. 이러한 방식은 하드웨어 제품개발이나 건설에서는 적합했었다. 프로젝트 계획수립의 예를 들면 다음과 같은 방식이었다.
.착수시점에 수행할 업무범위를 명확히 정의한다.(정의되지 않은 범위는 엄격한 변경통제 절차를 적용한다.)
. 업무범위 이행을 위한 작업(WBS, 작업분류체계)과 상세 활동(Activity)을 정의한다.
. 상세활동 이행을 위한 자원과 작업순서를 정의한다.
. 자원 유형별 투입규모를 계산하여 프로젝트 예산을 수립한다.
. 작업의 내용과 자원의 생산성을 고려하여 작업기간을 추정한다.
. 작업기간과 작업순서를 고려하여 개발계획을 수립한다.
. 범위, 일정, 원가를 종합적으로 고려하여 프로젝트 기준선을 확정한다.
위와 같은 계획수립은 프로젝트 종료시점에 결과물을 한번 제공하는 일정규모 이상의 프로젝트에서는 적합했다. 그러나 소프트웨어 제품과 서비스는 2주, 1개월 단위로 새로운 기능을 출시하는 경우가 많다. 2주 단위로 출시하는 프로젝트 개발에 위와 같이 범위관리, 일정관리, 원가관리를 상세하게 순차적으로 수행하는 것이 노력대비 효율적일까? ≪PMBOK 지침서≫7판의 성과도메인에서 범위, 일정, 예산을 별도 주제로 다루지 않고 통합적 관점(holistic view)과 시스템적 사고를 강조하는 이유가 여기에 있다.
- 프로젝트와 운영의 경계가 모호한 제품개발팀에 적용할 수 있는 새로운 프레임웍(framework)이 필요했다.
전통적인 프로젝트 팀은 착수시에 프로젝트 목표 달성에 적합한 역량을 갖춘 적정규모의 인원을 투입하고 종료시에 해체한다. 전통적인 프로젝트에서는 구현범위와 정해진 일정을 지킬 수 있는 신규 팀을 구성하여 중앙집중 방식으로 상세한 계획을 수립하고 통제했다. 프로젝트가 끝나면 운영조직으로 업무를 이관한 뒤 프로젝트 팀은 해체했다. 그러나 소프트웨어 개발은 데브옵스(Devops)라는 용어가 생길 정도로 프로젝트와 운영의 경계도 애매한 경우가 많다. 특히 소프트웨어 제품과 서비스를 최초 출시한 이후에는 더욱 그러하다.
소프트웨어 제품은 정해진 사람들이 지속적으로 개발을 하는 경우가 많으며 이를 안정적 팀(stable team)이라 한다.. 안정적인 팀은 중앙집중식의 계획과 통제 대신에 업무수행 방식과 의사결정을 팀원에게 위임 할 수 있어 프로젝트 관리 방식도 달라질 수 있다. 안정적인 팀에게는 상세한 규정보다 모두가 공유할 원칙만 제공하면 된다. 대부분의 일은 팀이 알아서 한다.
제품이 추구하는 가치를 이해하는 안정적인 팀은 다음과 같은 이유로 아주 높은 성과를 달성할 수 있다
. 프로젝트팀이 유지되기 때문에 품질수준이 높고 유지보수성이 높아진다.
제품 출시후 다른 사람이 운영할 때와 본인이 지속적으로 운영할 때는 품질에 대한 마인드가 달라질 수밖에 없다. 오늘 나의 행동이 미래의 나에게 영향을 미치기 때문이다.
. 암묵적 지식의 유실이 없어 생산성이 높아진다.
프로젝트 팀이 운영팀에게 업무를 문서로 이관한다면 많은 지식들이 유실되고 그 결과 시행착오를 겪는다. 안정적인 팀은 지식 이관과정이 없기 때문에 생산성이 갈수록 높아진다.
.고객지향적(customer centric)으로 사고하고 행동한다.
특정제품 이나 서비스를 오래 개발하면 사용자들에 대한 공감능력이 높아진다. 사용자들이 무엇을 필요로 하고, 무엇이 불편한지 잘 알게 되어 고객가치를 확보한 제품 개발의 가능성이 높아진다.
≪PMBOK 지침서≫7판은 프로젝트마다 새로운 팀을 구성하고 종료시점에 해체하는 프로젝트와, 안정적인 팀을 지속적으로 유지하는 프로젝트 모두를 설명할 수 있는 프레임웍(framework)을 구축하고자 했다.
https://brunch.co.kr/@kbhpmp/160
