12. 프로젝트 관리방법론이란?
프로젝트? 프로젝트!
컨설팅도 프로젝트이므로 컨설팅 방법론의 가장 근간이 되는 것은 프로젝트 관리(Project Management) 방법론이라 할 수 있다. 프로젝트에 관해서는 PMI[1]와 같은 전문교육기관이 주도하고 있어 많은 사람들이 참고하고있다. 이 장에서는 PMI의 가이드를 참고해서 일부 소개하고자 한다. 우선, 프로젝트가 무엇인지 생각해보아야한다. 다양한 산업은 물론 초등학교에서도 사용할 정도로 많이 듣던 단어인데 이를 정의해보라 하면 쉽게 하지 못한다. 매우 다양한 관점에서 프로젝트를 정의할 수 있겠지만 그 중 빠지지 말아야 할 세 가지 속성은 다음과 같다.
일시적(Temporary)
고유함(Unique)
결과물(Deliverables)
프로젝트는 일시적이다. 즉, 시작과 끝이 있어서 해당 기간 안에 프로젝트를 끝내야 한다. 또한, 프로젝트는 고유하다. 어떤 프로젝트도 동일한 것은 없다. 마지막으로 모든 프로젝트는 결과물이 있다. 도로가 생기고 발전소가 생기는 것처럼 컨설팅 프로젝트도 문서 기반의 다양한 산출물이 남는다. 프로젝트 관리 방법론이라는 것은 이런 속성들을 가진 프로젝트를 효과적으로 운용하기 위한 가이드(guide)이자 템플릿(template), 사례(Best practice)를 포함한 것이라 할 수 있다.
Figure IV-3. 프로젝트 관리 방법론의 개념프로젝트 관리 방법론은 Figure IV-3과 같이 5개의 프로세스가 상호작용하고 있다. 프로젝트 초기화 (Initiating)는 프로젝트 추진을 위한 각종 준비 단계라 할 수 있다. 프로젝트 계획(Planning) 단계는 일정 및 비용 계획, 추진 조직을 확정하는 단계이고 실행(Executing) 단계는 정해진 절차에 따라 일을 진행하는 단계, 종료(closing)와 모니터링 단계로 구성되어 있다.
12.1 프로젝트 관리의 개념
프로젝트 관리는 Figure IV-3에 소개된 프로젝트 업무 그룹을 좀 더 상세하게 구분하여 관리하는 것이라 할 수 있는데, 프로젝트 관리 협회(PMI)에서는 프로젝트 관리 업무를 Table IV-1과 같이 9가지 범주[1]로 나누어 소개하고 있다.
Table IV-1. 프로젝트 관리의 9가지 관점미션(mission)은 명확하지만 유한한 자원을 가지고 결과물을 만들어야 하는 프로젝트는 그 정의처럼 각 영역별 관리가 철저하게 진행되어야 한다. 범위관리에서는 전체 일의 범위를 정의하는 일을 한다. WBS(Work Breakdown Structures)라 불리는 작업분류체계를 만들어 그 순서대로 일을 수행한다. WBS는 일의 수행 주체와 기간이 표기된다. 간트(Gantt) 차트[3] 형식을 이용해서 누가, 언제 무엇을 시작하고 끝내는지, 그리고 어느 시점에 무엇을 점검하는지 등 마일스톤(Milestone) 같은 것을 표기하고 관리한다.
Figure IV-4. 간트차트 사례범위와 일정 관리는 기본적으로 PERT/CPM기법[4]에 근간을 두고 있다. 자원과 시간이 배정되면 그에 따른 비용을 관리해야 한다. 프로젝트에 주어진 예산은 얼마인데 집행되는 비용은 얼마이어서 결과적으로 프로젝트 손익은 흑자이다 또는 적자이다. 예상치 못한 비용 발생을 고려하여 우발비용(Contingency Cost)를 잡기도 하며 각 공정마다 제대로 비용이 집행되고 매입, 매출이 발생하는지 목표대비 차이(Variance)를 관리하기도 한다. 한편, 프로젝트를 추진할 팀을 구성하기 위해 인원을 수배하고 역할과 책임을 분담하는 일도 매우 중요하며 프로젝트에 필요한 장비를 구매하고 계약하는 일도 매우 중요하다. 이 모든 일들이 프로젝트 진행 과정에서 발생할 수 있는데 그와 관련하여 위험 요소를 식별하고 이를 정성적/정량적으로 관리하는 것도 필수이다. 아울러 이런 것들은 다양한 커뮤니케이션 형식을 빌어 공유되고 관리되어야 한다. 한마디로 프로젝트는 종합예술을 하는 것과 같아서 PM은 정말 수퍼맨이 되어야 한다라는 부담도 많이 가진다.
Break #17. 프로젝트를 보는 시각
정보시스템을 개발하는 프로젝트와 관련해서는 Figure IV-5와 같은 유명한 이야기가 있다. 내용은 고객은 나무에서 그네가 타고 싶다고 한다. 그것에 대해 프로젝트 매니져(PM)가 이해한 것, 업무 분석가가 이해한 것, 개발자가 이해한 것이 각각 다르다는 것이다. 결국 고객이 나무에서 그네를 타고 싶다고 할 때는 그냥 타이어 하나 매달아도 될 것을 Figure IV-5와 같이 여러 가지 모양의 결과물이 나오게 되었다. 이런 현상은 실제로 정보시스템 개발 현장에서 심심치 않게 발생하고 있다. 고객의 만족도를 높이고 싶다면 고객이 정확하게 무엇을 원하는지를 파악해야 하고 또 그것을 정확하게 제공해야 한다.
Figure IV-5. 소프트웨어 개발과 요구사항의 괴리
1.2 PMO의 역할과 책임
프로젝트의 규모가 커지거나 다수의 프로젝트를 관리해야 할 필요가 생길 때에는 고객은 PMO 서비스를 요청하기도 한다. PMO는 ‘Project Management Office’의 약자로 프로젝트 팀과는 별도로 프로젝트를 성공적으로 이끌기 위한 방법을 고민하고 이를 지원하는 사업관리 조직이라 할 수 있다. 국내 금융 대형IT사업의 경우, 컨설턴트들이 PMO를 구성하여 이를 많이 지원하며 동남아 등 개발도상국의 대형 SOC 프로젝트의 경우도 전문가와 컨설턴트들이 PMO를 구성하여 프로그램/프로젝트 관리를 수행한다. 쉽게 말하면 각종 보고와 산출물, 진척 상황 등 챙겨야 할 것들이 많아서 고객이 이를 감당하기 어려울 때 그 관리를 위해 전문가들을 고용했다고 보면 된다. PMO의 관점은 프로젝트와 거의 유사하나 그 일의 깊이와 범위가 차이가 있다. Table IV-2는 프로젝트 팀과 PMO가 프로젝트 각 영역에서 수행하고 있는 일을 비교한 것이다.
Table IV-2. PMO와 프로젝트 팀의 업무 비교PMO가 왜 필요할까? 금융권 차세대 IT프로젝트 등을 넘어서 대형 건설 프로젝트 등에서도 PMO의 필요성은 최근 더욱 부각되고 있다. 최근 많이 회자되고 있는 사례로 송파 가든파이브 건설은 여러 가지 문제들이 지적되고 있지만 주요 엔터티(Entity)간에 커뮤니케이션이 제대로 되지 않아 발생한 문제가 매우 크다고 한다. 많은 사람들이 잘 알고 있듯이 송파 가든파이브는 청계천 복원 당시 주변 상가의 이주 대책으로 만들어진 건물이다. 건물 자체는 많은 TV 프로그램에서 본 것처럼 매우 웅장하며 훌륭한 외관을 자랑하고 있다. 그렇지만 많은 사람들이 이 프로젝트를 본래의 목적인 ‘청계천 상가의 상인들의 이주’라는 관점에서 보면 30%에 미치지 못하는 이주율이 보여주듯이 송파 가든파이브 프로젝트는 실패했다라는 것에 동의한다. 그 원인을 살펴보면 발주처와 입주민, 시공사 사이의 커뮤니케이션에 문제가 많았던 것으로 파악된다. 원래 프로젝트의 발주처는 서울시였지만 이 복합단지 건설을 위한 요구사항을 낸 사람들은 청계천 상가 이주민 협의체였다. 즉 실질적인 고객이라 할 수 있는데 이주민 협의체는 멋진 건물이 되기를 바라는 마음에 이런 저런 요구사항을 내었고 시공사는 이를 충실히 수행했지만 결과적으로 입주 부담금이 높아져 입주할 수 없게 되어버린 것이다.
Figure IV-6. 송파가든파이브 구상도설계에서도 문제가 있었는데 복개 전 청계천 주변상가의 대부분은 ‘마지꼬바(町工場(まちこうば))[5]’라고 불리던 소규모 기계가공업체들이 많았다. 그림 그려다 주면 뭐든 뚝딱 만들어주는 도깨비 방망이 같은 기업들이었지만 이들은 영세했고 복합유통단지를 목표로 만들어진 건물 안에 기름 때 뭍은 자신들의 장비를 놓기에는 적당하지 않다라는 것을 나중에야 알게 되었다. 기계 공단을 가보면 길에 검은 띠와 반짝이는 가루들이 있는데 이것은 대부분이 기계의 윤활유가 만들어 내는 흔적이며 기계 가공 과정에서 나오는 금속 가루들인데 복합유통단지에는 그것들을 수용하고 처리할 수 없는 것이다. 적어도 그것들을 처리할 수 있는 별도의 공간이 필요했던 것이다. 결과적으로 이렇게 되었지만 계약 상 보면 시공사나 감리업체는 책임질 것이 없었다. 고객이 해달라는 대로 해주었고 감리 역시 특별히 지적할 사항이 없었기 때문이다. PMO는 바로 이런 경우에 관여하게 된다. 전문적 지식과 경험을 기반으로 한 PMO 구성원들이 고객이 진정으로 원하는 것이 무엇인지, 시공사는 고객의 요구를 제대로 충족시킬 수 있는지, 결과물은 프로젝트 본래 목적에 부합하는지 등을 판단하고 알려주는 일을 맡게 된다. 그래서 제대로 갖춰진 PMO 구성원들을 보면 해당 업에 대한 최고전문가들로 구성되어 있는 경우가 많고 해외 대형 프로젝트에서 PMO를 수행한 경험을 가질 수 있게 되면 글로벌 인재로 거듭나면서 그런 사람에 대한 높은 수요와 대가를 지불받게 된다.
1.3 컨설팅 프로젝트 관리
한편, 컨설팅 프로젝트는 건설이나 기계산업의 프로젝트와 달리 업무의 대부분이 문서 작업이기때문에 철저하게 문서 산출물을 어떻게 생성하고 어떻게 고객에게 검수받을 것인가하는 것이 가장 중요하다. 한국의 경우, 글로벌 Top 3 전략컨설팅 기업이 처음 진출하던 시절만 해도 경영진 보고 몇 번하고 A4 몇장의 보고서를 최종 산출물로 내고 철수하는 경우도 많았다.[6] 그러나 요즘은 그렇게 해서는 컨설팅 사업을 수주하고 이행하기 어렵다. 경우에 따라서는 사업대가대비 과도하게 생각되는 요구를 하는 경우도 있고, 고객사에도 풍부한 컨설팅 프로젝트 경험을 가진 전직 컨설턴트들이 많이 포진하고 있기 때문에 그들의 눈높이에 맞는 산출물을 만드는 것도 쉽지 않다. 저자가 경험한 바에 의하면 산출물의 질적인 부분보다도 산출물의 양적인 측면에서 가장 까다로운 것은 공공 IT컨설팅이다. 법률에 의해 각 단계[7]별로 어떤 문서가 만들어져 나와야 하는지 정해져 있고, 가이드가 있기 때문에 매우 정형화되어 있다. ISP와 같은 정보화 전략 계획을 위한 컨설팅 기업 고유의 방법론을 기본으로 하되 전체적인 프로젝트 관리는 정보시스템 구축 프로젝트를 테일러링해서 사용한다. Table IV-3.은 정보전략 컨설팅 프로젝트의 각 단계별 주요 내용과 주요 산출물을 정리해본 것이다. 소위 말하는, Value Pack List인데 지식과 경험이 풍부한 컨설팅 기업들은 TableIV-3과 같은 형태로 폴더를 구성하고 문서 템플릿, 참고할 수 있는 사례 등을 묶어서 컨설턴트들 사이에서 공유한다. Value Pack이 잘 구성되어 있으면 고객의 상황에 맞게 약간만 수정하여 산출물들을 만들 수 있다. 컨설팅 사업이 지식 사업(Knowledge Business)이라는 것의 반증이고, 산업 유형 또는 사업 유형 등 다양한 구분에 따른 유의미한 Value Pack이 많을수록 컨설턴트들이 일의 본질에 고민할 수 있는 시간이 더 많아지며 결과적으로 보다 효율적으로 일할 수 있게 된다.
컨설팅 사업에서 Value Pack은 필수적이다. 양질의 Value Pack을 갖출수록 보다 빠르게 수준 높은 결과물을 만들어낼 수 있다. 사실 문제의 본질에 대한 고민에 많은 시간을 보내야 하는데 그 짧은 기간에 프레임워크 고민하고, 문서 양식 고민하고 한다면 고객의 기대에 부응할 수 없을 것이다. 또한, 시니어 컨설턴트 이상이 되면 보통 2~3개의 프로젝트에 직간접으로 관여하게 되고 PM을 하고 있지만 다음 사업 수주를 위한 마케팅이나 영업, 제안도 해야 하기에 잘 갖추어진 Value Pack만큼 소중한 것이 없다. 그렇지 못하면 낮에는 프로젝트 수행, 밤에는 영업이나 제안 작업이 일상이 된다
Table IV-3. IT컨설팅 프로젝트 단계 및 주요 내역 사례[8]Table IV-3을 보고는 ‘음.. 이건 컨설팅이 아니라 구축 사업 아냐?’라고 생각하는 사람들도 있을 것이다. 이 경우 컨설팅 결과물이 정보시스템 구축 프로젝트와 이어지기 때문에 IT컨설팅 산출물은 당연히 그것과 연관된 것도 많고, 컨설턴트들만 일하는 것이 아니라 프로젝트 팀에 아키텍처, 개발자들도 같이 합류하여 일하는 것이 일반적이다. 또한, 공공 프로젝트는 감리를 해야 하기 때문에 RFP에 있는 항목들이 제대로 준수되고 있는지를 제3자 시각의 관점에서 점검하는 일도 발생한다. 따라서 문서의 종류는 많지만 매우 정형화되어 있고 한번 제대로 경험해보면 크게 어렵지는 않다. 저자의 경험을 돌이켜보면 공공 IT컨설팅을 수행해 본 경험이 있는 컨설턴트들은 민간 기업의 컨설팅도 쉽게 적응해나갔다. 그러나 그 반대의 경우, 상대적으로 복잡하고 상세한 절차, 다양한 산출물의 작성 및 테일러링 경험이 부족하여 잘 대응하지 못하였다. 그렇기에 산출물의 재사용 및 자산화는 컨설팅 기업의 큰 경쟁력이 되고 있다.
[1] Project Management Institute. http://www.pmi.org
[2] PMI에서는 4년마다 PMBOK를 업데이트하면서 내용을 변경하고있다. 관리 범주의 구분과 내용도 계속 업데이트되고 있는데 Table IV-1은 PMBOK 3판을 기준으로 하였다.
[3] Henry Gantt(1861 ~ 1919)에 의해 창안된 공정계획양식. 작업계획과 실제 작업량을 막대 모양의 작업시간으로 표기하고 관리함
[4] PERT: Program Evaluation and Review Technique. 1958년 미국 해군이 폴라리스 미사일 개발 프로젝트의 일정 계획 및 통제를 위해 개발함. CPM: Critical Path Method. 1957년 미국 RemintonRand사에서 개발. PERT는 각 활동시간을 3가지로 추정하여 평균시간을 계산하는 일종의 확률모형인데 비해 CPM은 각 활동시간을 확정적으로 추정함. 즉, PERT는 프로젝트의 시간적 측면만 고려하는데 비해, CPM은 시간과 비용을 모두 고려함
[5] 주로 발주자의 요구에 맞출 능력을 갖추지 못한 영세 사업장을 비하하는 의미로 사용
[6] 이 부분은 논란의 여지가 있을 수 있는데 산출물은 그렇지만 사실 CEO를 포함하여 경영진들은 또 다른 비즈니스 네트워크를 만드는 성과도 얻게 되므로 실무자가 접하는 보고서와 경영진이 얻게 되는 가치(Value)는 좀 다를 수 있다. 물론, 지식과 경험이 풍부한 컨설턴트들이 들어와서 일을 한다는 전제에서 말이다.
[7] 여기서 단계는 컨설팅 방법론의 단계를 의미한다. 컨설팅 방법론은 컨설팅 기업마다 다르며, 고객과 합의하여 테일러링한 후 결정하는 것이 일반적이다.
[8] 비용관리의 경우, 요즘은 정보시스템이 잘 구축되어 있어 비용도 사후정산보다 법인카드로 처리하는 경우도 많고, 사업대가 청구도 전자세금계산서를 활용하는 방식이 일반화되어 있다.
Prologue
Part I. 컨설팅 산업은 부활할까?
1. 컨설팅의 정의와 종류 (1/2)
1. 컨설팅의 정의와 종류 (2/2)
2. 컨설팅 산업의 현황 (1/2)
2. 컨설팅 산업의 현황 (2/2)
3. 컨설팅 기업들의 전쟁
Part II. 컨설팅 스킬
4. 논리적 사고 (1/2)
4. 논리적 사고 (2/2)
5. 문제해결기법 (1/3)
5. 문제해결기법 (2/3)
5. 문제해결기법 (3/3)
6. 커뮤니케이션 스킬 (1/3)
6. 커뮤니케이션 스킬 (2/3)
6. 커뮤니케이션 스킬 (3/3)
Part III. 컨설팅 도구와 기법
7. 경쟁 및 산업 분석 (1/4)
7. 경쟁 및 산업 분석 (2/4)
7. 경쟁 및 산업 분석 (3/4)
7. 경쟁 및 산업 분석 (4/4)
8. 고객 요구 분석 (1/3)
8. 고객 요구 분석 (2/3)
8. 고객 요구 분석 (3/3)
9. 수익성 분석 (1/2)
9. 수익성 분석 (2/2)
12. 프로젝트 관리 방법론
13. 경영전략 수립 방법론
14. 프로세스 혁신
15. 신사업 개발
16. 사업타당성 분석
17. 정보전략컨설팅(BPR/ISP) 방법론
Part V. 컨설팅 사업 개발 및 이행
18. 컨설팅 사업 개발
19. 성공하는 컨설팅 사업 제안
20. 컨설팅 이행과 지식경영
Epilogue
#컨설팅_방법론, #프로젝트관리_개념, #프로젝트관리_방법론, #간트차트, #PMO, #PMO_역할, #컨설팅_프로젝트_관리, #Value_Pack,
