1회를 연재하고 나서 저자의 의도를 묻는 질문이 왔다. 명화를 프로젝트 관리와 함께 기고하는 이유에 대한 것이었다. 프로젝트 관리의 주제와 함께 명화를 제시하는 것은 프로젝트 주제를 함축적으로 담은 명화를 보여줌으로써 보는 이로 하여금 여러가지를 떠오르게 하기 위해서다. 단순한 프로젝트 관리의 지식을 설명하기보다는 명화와 연상해서 독자들의 프로젝트에 대한 경험을 불러오기 위함이며, 아직 프로젝트가 낯선 이들에게는 명화를 통해 생생한 체험을 연결시키려고 하는 것이다. 기고를 읽는 것에서 한 발짝 더 나아가 눈으로 보고 기억에서 사상(寫像, mapping) 시켜서 독자들의 지식을 내재화시키기 위함이다. 이번 연재를 통해 필자는 프로젝트 관리에 대한 이야기를 풀어가면서 명화와의 만남을 계속 시도해 보겠다.
조희준 josephc@chol.com｜CGEIT, CISA, COBIT, CISM, CCFP, CISSP, CSSLP, ISO 27001(P.A), CIA, ITIL, IT-PMP, PMP, ISO 20000(P.A), PMS(P.A), (ISC)2 CISSP 공인강사, 정보시스템감리원과 한국정보화진흥원 사이버범죄예방교화 전문강사로 활동하고 있다. IT컨설팅/IT감리법인 씨에이에스 컨설팅 이사, 강원대학교 겸임교수, (사)한국정보시스템감사통제협회, (ISC)2 CISSP Korea 한국지부, 한국 포렌식조사 전문가협회에서 이사로도 활동 중이며 한국 정보기술 프로젝트관리 자격검정원 운영위원 활동을 하고 있다. IT감사, 내부감사, IT거버넌스와 정보보안 거버넌스, 내부통제가 관심분야다. 이와 관련해서 기고, 강의, 강연을 활발하게 하고 있다. ‘용기란 무엇인가?’에 대한 답을 2011년에 꼭 찾으려 한다. 두 번째 단행본인 『IT거버넌스 프레임워크 코빗』의 출간 후 다음 저서를 준비 중이다.
프로젝트(project)에 대한 정의를 알기 쉽게 이해하기 위해서는 운영업무(Operations)와 구별하면 그 의미가 뚜렷해진다. 일상적으로 반복되는 기업의 현업 업무를 운영업무라고 한다.
따지고 보면 정착된 운영업무는 과거에 프로젝트를 통해 기획되고 실행되고 완성되어 그 결과로 운영업무의 형태가 된 것이다. 이를 프로젝트와 운영업무의 수명주기(lifecycle)의 반복이라 한다.
조금 확장해서 프로젝트의 정의를 내리자면 전략(Strategy)을 달성하는 구체적인 전술(Tactics)의 형태가 프로젝트이며, 이와같은 전술적인 프로젝트 또한 완료되어 운영으로 전환된다. 계층적 구조로 설명하는 프로젝트의 정의라는 것이다.
<그림 1> 프로젝트와 운영업무의 수명주기
<그림 2> 프로젝트의 계층적 의미
이번 컬럼에서는 프로젝트의 지식영역(knowledge area)을 중심으로 한 내용을 연재할 것이다. 프로젝트 관리를 위한 지식영역은 단순한 관리항목을 지나서 지식영역 안에 있는 프로세스(Process)를 이해하는 것이 중요하다. 결국은 프로젝트를 성공으로 이끈다는 것은 각 지식영역의 프로세스를 잘 관리했다는 것을 의미한다.
이번 호의 주제는 통합 관리와 범위 관리다. 이해를 돕기 위해 다음에 제시한 명화를 보자.
<그림 3>은 통합 관리를 상징하는 명화, ‘곡예사’다. 아슬아슬 줄을 타는 곡예사는 한 순간도 방심할 수 없고 어떤 불확실성이 있는지를 판단해 가면서 줄을 탄다. 곡예가 끝나면 박수갈채를 받지만 곡예를 하는 동안은 살얼음 위를 걷고 있는 것이다.
프로젝트란 운영업무에 비해서 불확실성이 크다. 프로젝트의 종료시 까지 성공 여부에 대한 위험이 크다고 하겠다. 또한 프로젝트에는 프로젝트 매니저(Project Manager)는 물론 프로젝트 리더와 멤버들이 각자 맡은 지식영역(범위, 일정, 비용 등)을 가지고 책임과 역할을 다하는 유기체이다. 서로의 이해득실이 상충될 수도 있다.
우선순위가 서로 충돌되는 경우도 허다하다. 곡예를 하는 곡예사의 마음과 같다. 자칫 실수하면 줄에서 떨어지는 위험이 있다. 목표까지 가는 데는 많은 제약조건과 이해관계가 불확실하게 엉켜있다. 이 난관을 뚫고 가야 한다.
<그림 3> 곡예사(L'acrobate), 마르크 샤갈(Marc Chagall)
범위관리에 대한 이야기를 해보도록 하자. 범위 관리의 혜안을 갖게 하는 그림은 솔거의 ‘노송도’이다. 솔거는 신라 때의 화가로서 황룡사 벽에 그린 ‘노송도(老松圖)’에 새들이 앉으려다가 부딪쳐 떨어졌다는 일화가 있다. 안타깝게 전해지기가 않아서 겸재 정선의 ‘노송도’로 대신함을 이해해주길 바란다.
<그림 4> 노송도(老松圖), 겸재(謙齋) 정선(鄭敾)
소나무를 얼마나 사실과 똑같이 벽에 그렸으면 날아가던 새들이 나뭇가지에 앉으려다 부딪혔을까? 소나무를 정확하게 묘사하기 위해 관찰하기를 수년간 거듭한 화가의 마음을 헤아릴 수 있을 것 같다.
프로젝트에 있어서 고객의 요구사항을 구체화하는 것이 범위다. 프로젝트를 의뢰한 고객의 요구사항을 충족하는 것이 PMBOK(Project Management Body of Knowledge, 프로젝트의 지식체계)의 기본 첫 줄에 나와 있는 내용이다. 고객의 요구사항을 가장 현실과 가깝게 묘사하려면 솔거의 노송도 수준까지는 아니더라도 그 정신을 이어받을 필요는 있을 것이다.
통합이란 무엇인가
‘통합’이라는 말을 들으면 독자들은 어떤 느낌을 받는가? 기업 통합, 부서 통합 등 부정적인 의미가 와닿을 수도 있다. 기업 내에서 여러 하위 체제의 노력을 기업목표 수행에 적합하도록 통일시키는 과정에 통합이라는 말이 쓰인다. 또한 부분적인 결합에 의해 새로운 성질을 갖는 전체를 만들어 내는 것도 통합이라고 한다.
PMBOK가 얘기하는 통합이란, 통일하거나 하나로 결합하면서 부분들이 없어지는 것은 아니다. 부분 부분들을 최대한 살리면서 균형을 맞추어 나간다는 의미로 쓰인다.
PM(Project Manager, 프로젝트 매니저)의 역할로서 프로젝트 구성원(Project member)간의 의견과 이해관계를 조정하는 것을 말한다. 물론 고객과 프로젝트 후원자(Project Sponsor)까지 포함해서 얘기하는 것이다.
<그림 5> 통합의 의미
통합 관리(Integration Management)의 프로세스
통합 관리에서는 관련된 부분들 간에 일관성과 통일성이 유지되어야 하며, 다양한 부분들이 서로 균형을 이루며 프로젝트를 진행할 수 있어야 한다. 이를 위한 프로세스는 <표 1>과 같다.
<표 1> 통합 관리의 프로세스
통합 관리에서는 6개의 프로세스가 있다. 여기에서 질문이 나올 수도 있을 것이다. 그렇다면 4.1~4.6이란 숫자의 의미는 무엇일까? PMBOK는 총 12개의 장으로 구성되어 있다. 그 중에서 통합 관리는 4장이다. 전체 PMBOK의 장은 다음과 같다.
제 1장. 프로젝트 개요
제 2장. 프로젝트의 수명주기와 조직
제 3장. 프로젝트 관리 프로세스
제 4장. 통합 관리
제 5장. 범위 관리
제 6장. 시간 관리
제 7장. 원가 관리
제 8장. 품질 관리
제 9장. 인적자원 관리
제 10장. 의사소통 관리
제 11장. 위험 관리
제 12장. 조달 관리
변경 통제(Control the Change)
‘프로젝트란 고객의 요구사항을 충족시키는 것’이라고 한 마디로 정의할 수 있다. 프로젝트 팀이 고객의 요구사항을 잘 구현해주면 된다는 것인데, 이 요구사항이 ‘일편단심 민들레’가 아니리는 것이 문제이다. 고객의 마음은 그야말로 한 여름의 날씨와 같아서 변하게 되어 있다.
PMBOK에서는 ‘고객의 변경사항은 언제든지 수용해야 한다’라고 얘기한다. 단, 조건이 있다. 이러한 변경에 대해서 고객과 협의하고 이를 문서화하고 승인을 받아 놓아야 한다는 것이다. 프로젝트에서는 조그마한 변경도 전체 일정이나 예산에 영향을 줄 수 있을 뿐더러 품질이나 인수조건에 문제가 될 수 있기 때문이다. 통합관리의 5번째 프로세스가 ‘통합 변경통제 수행’으로 자리잡은 이유가 거기에 있다.
변경은 자유롭게, 그리고 그에 따른 책임은 고객과 프로젝트 팀이 합의하고 문서화하고 승인해야 한다.
프로젝트는 완성을 향해 끊임없이 감시하고 통제하고 교정하는 과정의 반복이라고 한다. 적절한 변경관리가 프로젝트의 최종 산출물을 고객의 요구사항에 아주 가깝게 만들어 줄 것이다.
<그림 6> 변경 관리
범위란 무엇인가 - MOT(Moments of Truth)
범위란 말이 익숙하게 들리는 이유는 무엇일까? 학교 다닐 때 시험범위를 가르쳐 달라고 선생님께 떼쓰던 그때를 기억해보자. 교재에서 전부를 공부하기는 힘드니 구체적으로 꼭 집어서 범위를 알려 달라고 했던 그때를 말이다.
프로젝트에서 얘기하는 범위도 마찬가지로 이해하면 된다. 고객이 원하는 요구사항(requirement)를 꼭 집어서 구체화하면 그것이 범위다. 고객의 요구사항은 특정제품이나 서비스 등등 유·무형의 형태를 갖고 있다. 무엇이든 간에 구체화하지 않으면 고객이 원하는 것을 만들어 낼 수 없다. 즉 프로젝트가 실패한다(이러한 범위를 잘못 잡아서 실패한 프로젝트가 대부분이다).
<그림 7> 진실의 순간 (MOT)
프로젝트에서 얘기하는 범위를 저자는 마케팅에서 사용하는 ‘진실의 순간 MOT(Moments of Truth)’라고 설명하고 싶다.
이는 고객의 접점(接點)이라고도 하는데, ‘고객과 접하는 모든 순간’을 의미한다. 고객과의 상담뿐만 아니라, 고객으로부터 전화를 받는 순간, 고객을 응대하는 순간 등을 말한다. 일반적으로 고객이 느끼는 브랜드의 인식보다는 ‘접점’ 그 순간에 느끼게 되는 것이 그 기업의 브랜드나 명성을 좌우한다는 것이다.
프로젝트에서 프로젝트 기업의 브랜드를 결정짓는 ‘진실의 순간’도 중요하지만, 저자의 의도는 조금 다르다. 고객과의 접점에서 프로젝트 멤버들이 요구사항을 구체화하기 위해 최대한으로 노력하는 ‘진실의 순간’으로 설파하고 싶은 것이다. 범위를 결정지을 수 있는 것은 오직 고객뿐이기 때문이다.
범위 관리(Scope Management)의 프로세스
범위 관리에서는 프로젝트를 통해 고객에게 제공하기로 협의한 제품 및 서비스의 총합, 즉 최종 산출물을 구체화하기 위한 일련의 프로세스와 활동을 얘기한다. 프로젝트 목적 달성을 위해 범위는 아래 3가지의 필요 충분 조건이어야 한다.
1. 꼭 필요한 일이어야 한다.
2. 완전하게 범위를 충족해야 한다.
3. 최소한의 노력으로 수행한다
범위 관리를 위한 프로세스는 <표 2>와 같다.
<표 2> 범위 관리의 프로세스
이번 컬럼에서는 프로젝트를 성공하기 위한 통합 관리와 범위 관리를 알아보았다. 프로젝트는 종합예술이라고 한다. 여러 가지 제약조건들과 수많은 이해관계자 속에서 헤쳐 나가야 하는 힘겨운 여정이다. 통합 관리는 그러기에 더욱 중요하다고 할 수 있다.
범위 관리 또한 고객의 요구사항을 충족하기 위한 노력이 절실하다고 할 수 있다. 고객과 만나는 진실의 순간을 잘 활용해야 한다. 단순히 비빔밥을 만들듯이 섞어놓은 것은 통합이 아니다. 부분별로 맛을 느껴야 하는 것이 통합이다.
<그림 8> 프로젝트의 어려움
스페인의 투우에서 나온 말인 ‘진실(眞實)의 순간(瞬間)’은 투우사가 소의 급소를 찌르는 순간을 말한다.
‘피하려 해도 피할 수 없는 순간’ 또는 ‘실패가 허용되지 않는 매우 중요한 순간’을 의미한다. 고객의 요구사항을 파악하는 ‘결정적 순간’이라 할 수 있다. 범위 관리의 핵심이다.
마르크 샤갈의 ‘곡예사’와 겸재 정선의 ‘노송도’를 통해 독자들이 통찰력(insight)를 얻기 바라며 명화를 보면서 프로젝트의 성공을 위해 불철주야 노력하는 독자들에게 힘이 되길 바란다.
보다 자세한 내용은 www.pmi.org 혹은 www.pmi.kr에서 찾아볼 수 있다.
|
.jpg)
.jpg)
.jpg)
