계획에 따라 승리한 전쟁은 없다. 하지만 계획 없이 승리한 전쟁도 없다.
저는 20년 넘게 IT분야에서 기획, 컨설팅, PM, PMO의 역할로 다양한 프로젝트를 진행하였습니다.
그중에 PM의 업무를 가장 많이 하였고 프로젝트 관리 방안을 위한 프로세스, 문서의 표준화 작업도 진행한 바 있습니다.
프로젝트 관리에 대해 누구보다도 중요함을 느끼는 사람으로서 학술적인 내용에 대한 정리와 실제 경험하면서 만든 산출물 위주로 프로젝트 관리에 대해 설명하려고 합니다.
지금 이 글을 읽고 계신 분들은 프로젝트관리에 관심이 있어서 오신 것이라 생각하고 싶습니다.
제 경험상 프로젝트관리에 대해 많은 분들이 오해를 하고 있다는 것입니다.
얼마 전 모 회사에서 프로젝트관리에 대한 교육을 진행하면서 아래와 같은 질문을 받았었습니다.
프로젝트 관리 때문에 현재 작업하는데 어려움이 있습니다.
이런 문서를 작성해라, 저런 문서를 작성해라, 관리보다는 인력 지원을 해주시는 게 좋지 않을까요?
현재 진행하는 프로젝트에는 요구사항의 정의 없이 프로젝트가 진행되고 있습니다. 지금까지 작업 진행하는데 문제 되지는 않았는데 그래도 프로젝트 관리가 필요한 건가요?
프로젝트 관리가 중요하다는 건 알겠는데
직접적으로 저에게 와닿는 것이 없어서 필요성을 못 느끼겠습니다.
왜 프로젝트 관리가 필요한 거죠?
보통 프로젝트 관리라고 하면 문서들을 만들고 회의를 해서 이래저래 작업할 시간을 뺏기는 요소로만 생각하는 분들이 많습니다.
또한, 관리 업무가 많지 않을 것으로 판단하여 관리업무와 수행업무를 같이 하는 개발자들도 보았습니다.
중복된 업무를 진행하는 이유를 물으면 PM은 간단한 문서 정리와 고객과 커뮤니케이션만 진행하는 존재로 알고 있는 분들도 많았습니다.
안타까운 것은 이런 경험을 한 회사는 다음 프로젝트에서도 PM업무를 또 맡긴다는 것입니다.
이렇게 프로젝트를 계속 진행하다 보면 사람의 평가는 두 가지 업무를 성공시키는 팀원이 훌륭하게 해낸 것으로 평가를 합니다.
안타깝지만 현실적으로
자체 방법론 없이 프로젝트를 진행하는 SI 업체는 너무나도 많고 방법론/프로젝트관리 등의 필요성을 못 느끼는 SI업체도 많다는 것입니다.
그렇다면 프로젝트 관리는 무엇이고 왜 필요한 것일까요?
프로젝트가 무엇일까요?
사전적 의미로 Project(프로젝트)는 라틴어에서 유래했고 PRO(프로 : 미래를 항하다)와 JACERE(야세레 : 던지다)의 합성어라고 합니다.
지금까지 진행했던 프로젝트를 이해하면서 뜻을 풀이해 보면
'어떤 목적을 향해 던지다, 해보다'라는 뜻이 올바른 해석이라 생각됩니다.
개인적으로 Project의 해석을 아래와 같이 해석하고 있습니다.
프로젝트는 미래에 어떤 목적을 해결하기 위해서 진행하는 것
그렇다면 프로젝트는 언제부터 시작했을까요?
인류가 시작되는 시점부터 프로젝트는 진행해 왔었습니다.
쿠퍼왕의 대피라미드
- 넓이 : 277m
- 높이 : 148m
- 돌하나의 평균 무게 : 2.5톤
- 동원인력 : 10만 명
- 제작기간 : 20년
지금으로부터 4천7백 년 전에 만들어졌습니다.
이때는 청동기시대로 우리나라는 고인돌을 만들던 시기 이죠. 저 큰 돌을 정확한 크기에 맞춰 자르고 높이 쌓아야 하는데 어떻게 이렇게 만들었을까요?
돌하나의 평균 무게는 2.5톤이고 동원인력은 10만 명이고 제작기간은 20년이라고 합니다.
쿠퍼왕이 태어나자마자 죽으면 들어갈 묘지를 계획하였다는 얘기입니다.
이렇게 많은 인력과 오랜 시간을 거처 제작하게 된다면 인력관리, 비용관리, 위험관리 등을 안 할 수는 없었겠죠?
만리장성
- 기원전 220년 건설
- 전체 길이 : 5,000km ~ 6,000km
- 동원인력 : 150만 명
- 제작기간 : 1,000년
기원전 220년 경에 만들어진 만리장성은 전체 길이가 5,000km에서 6,000km에 다다른다고 합니다.
동원인력은 150만 명이고 제작 기간은 1,000년이 걸렸다고 합니다.
이렇게 인류의 역사 속에는 다양한 프로젝트가 있었습니다.
현대에 와서 프로젝트는 어떤 의미를 갖고 있을까요?
미국의 PMI의 PMBOK Guide에서는 프로젝트를 “유일한 제품, 서비스 또는 결과를 창출하기 위하여 수행하는 한시적인 활동”이라고 정의하고 있습니다.
PMI (Project Management Institute)
- 사이트 : https://www.pmi.org
- 프로젝트 관리 연구소(Project Management Institute, PMI)는 프로젝트 관리를 위한 미국 비영리 전문 단체이다.
국제표준기구에서 만든 IOS 21500에서는 “프로젝트의 목표 달성을 위하여 수행되는 고유한 프로세스의 집합으로 구성되며, 프로세스는 시작일과 종료일이 정해져 있고 조정되고 통제되는 활동으로 이루어진다.”라고 정의하고 있습니다.
ISO (International Organization for Standardization)
- 사이트 : https://www.iso.org
- 여러 나라의 표준 제정 단체들의 대표들로 이루어진 국제적인 표준화 기구이다. 1947년에 출범하였으며 나라마다 다른 산업, 통상 표준의 문제점을 해결하기 위해 국제적으로 통용되는 표준을 개발하고 보급한다.
PMBOK에서는 프로젝트는 3가지의 특징이 있다고 하였습니다.
첫 번째의 특징은 프로젝트는 명확한 시작과 끝이 있다는 것입니다.
두 번째의 특징인 유일한 프로덕트나 서비스를 만든다는 것입니다.
세 번째의 특징은 점진적으로 구체화된다는 것입니다. 프로젝트 초기 단계에서는 러프한 모양을 볼 수 있다면 프로젝트가 종료되는 시점에서는 구체화된 모양을 볼 수 있습니다. 그래서 프로젝트는 시작과 끝이 있고 유일한 프로덕트를 만들고 점진적으로 구체화된다는 것이 프로젝트의 3가지 특징입니다.
프로젝트는 사업의 목적 달성을 위한 일시적(Temporary)이며, 유일한(Unique) 업무를 말하고 오퍼레이션(운영 업무)은 사업의 목적 달성을 위한 지속적(On-Going)이며, 반복적(Repetitive)인 업무를 말합니다. 프로젝트는 일시적인 일정을 갖고 유일한 업무를 진행하는 반면 오퍼레이션(운영 업무)은 지속적인 일정과 반복적인 업무를 진행합니다.
프로젝트와 오퍼레이션의 차이점이 있다면
프로젝트는 일시성, 유일성, 점진적 구체화라는 특징이 있는 반면 오퍼레이션(운영 업무)은 지속적이고 반복적인 특징이 있습니다.
두 가지 모두 사람이 수행하고 제안된 자원의 제약을 받으며, 계획, 실행, 통제된다는 공통점이 있습니다.
지금까지 프로젝트에 대해 알아봤는데 우리가 오늘 배우려고 하는 프로젝트 관리에 대해 알아보도록 하겠습니다.
PMBOK에서 프로젝트 관리를 “프로젝트 관리는 프로젝트 요구사항을 충족시키기 위하여 지식, 기능, 도구 및 기법을 프로젝트활동에 적용시키는 것”이라고 정의합니다.
PMBOK에서는 프로젝트관리의 4가지 구성요소가 있다고 정의하였습니다.
프로젝트의 중요 구성요소는 요구사항 정의, 프로젝트의 목표 수립, 품질, 범위, 일정, 원가에 대한 균형, 이해관계자들의 기대 이상의 사양을 적용하는 것입니다.
보통 요구사항 정의에 대한 중요도는 누구나 느끼는 부분이나 프로젝트 수행에서 가장 중요한 부분은 달성 가능하고 명확한 목표의 수립입니다. 경험상 각 파트마다 다른 프로젝트의 목표 수립은 프로젝트 진행 시 문제점을 야기합니다.
그리고 중요한 이해관계자의 관심과 확인이 중요하다 하겠습니다.
어떤 이해관계자는 참여하지 않고 결정하지 않으려 합니다. 특히 현업 담당자라면 무엇보다도 참여할 수 있는 여건을 만드는 것이 중요하다 하겠습니다.
저는 이런 이유 때문에 착수보고나 수행계획서에 업무지원요청을 보고 하고 있습니다.
보통 착수보고에서는 고객사의 최종 결정권자가 참석하기 때문에 각 파트별 현업 담당자의 동참/결정/협조는 무엇보다 중요하다 하겠습니다.
진행했던 프로젝트의 착수보고서(수행계획서)에서 아래와 같이 현업 사용자의 동참, 의사결정/보고체계 등의 업무 지원요청을 결정권자에게 보고 하여 요청하였습니다.
프로젝트관리의 제약조건은 범위와 일정, 원가와 품질로 얘기할 수 있으며 이중 범위, 일정, 원가는 서로 상충관계로, 어느 한 가지가 변경될 경우 다른 요소에 영향을 미칩니다.
그리고 3가지 요소 사이의 균형이 프로젝트의 품질에 영향을 줍니다.
프로젝트 관리에 필요한 전문 지식을 PMBOK Guide에서는 다음과 같이 얘기하고 있습니다.
1. 프로젝트관리 지식 체계가 있어야 한다.
The Project Management Body of Knowledge
2. 응용분야의 지식, 표준, 법규에 대한 정보를 가지고 있어야 한다.
Application area knowledge, standards, and regulations
3. 프로젝트환경에 대한 이해가 있어야 한다.
Understanding the project environment
4. 일반적인 관리 지식과 기술을 익혀야 한다.
General management knowledge and skills
5. 대인관계의 커뮤니케이션 스킬이 있어야 한다.
Interpersonal Skils
각각 자세하게 설명하면
대표적인 프로젝트관리 지식체계는 미국의 PMI에서 만든 PMBOK Guide(Project Management Body of Knowledge)와 국제표준기구에서 만든 ISO 21500이 있으며, 영국에서 만든 PRINCE2가 있습니다.
프로젝트관리 지식체계는 각 회사에 적용하여 사용하되 각각 회사에 맞게 회사의 프로젝트에 맞게 수정하여 회사만이 지식체계를 만들어야 합니다.
- PMI PMBOK Guide
PMBOK Guide는 미국 PMI에서 1983년 발간을 시작하여 계속된 개정을 거쳐 현재 7판 (2019년)까지 발간하였습니다.
10개의 지식영역과 5개의 프로세스 그룹에 따라 49개의 논리적으로 연결된 프로세스로 구성되어 있습니다.
- ISO 21500
국제표준화기구(ISO)에 의해 개발된 프로젝트 관리국제표준(37개국에서 참여하여 2012년 9 월 1일에 발표) PMBOKGuide와 유사하게 10개 주제그룹과 5개의 프로세스 그룹에 따라 논리적으로 연결된 39개의 프로세스들로 구성되어 있습니다. 우리나라는 2013년 11월에 ISO 21500 이행가이드를 개발하였습니다.
- PRINCE2
다음은 영국에서 만든 PRINCE2입니다.
PRINCE:PRojects IN Controlled Enviroments의 약자로 통제된 환경에서의 프로젝트라는 뜻을 갖고 있습니다.
1989년 영국의 OGC(OfficeofGovernment Commerce)에서 개발되어 1996년 PRINCE2로 개정하였습니다. 원래는 IT프로젝트관리를 위한 영국 정부의 표준으로 개발되었으나 IT 이외의 프로젝트에도 확대적용하고 있습니다. 프로세스 기반 프로젝트 관리방법으로 8개의 프로세스와 45개의 활동으로 구성되어 있습니다.
프로젝트관리에 필요한 전문 지식의 두 번째는 응용분야의 지식, 표준, 법규에 대한 정보를 가지고 있어야 한다고 하였습니다.
아파트를 건설하는 프로젝트에서 건설에 대한 지식이 없는 사람이 아파트를 건설한다면 무엇보다도 위험한 부분일 것입니다.
기술적인 구성요소뿐만이 아닌 정부 계약, 법규등에 대한 지식도 알아야 합니다.
프로젝트에 영향을 미치는 조직 문화적, 사회적 환경, 국제적, 정치적 환경, 프로젝트가 영향받는, 또는 프로젝트 의해 영향 미치는 물리적 환경의 이해가 있어야 합니다.
재무 및 회계, 구매 및 조달, 계약 및 상법, 제조 및 유통전략 기획과 운영 기획, 조직구조 / 조직 행위 / 직원관리 / 보상 / 복지, 건강 및 안전 실무, 정보 기술에 대하 지식과 기술을 익혀야 합니다.
- 효과적인 의사소통(정보 교류)이 가능해야 합니다.
- 어떤 내용일지라도 조직에 좋은 영향을 주는 능력이 있어야 합니다. (일이 되게 하는 능력)
- 리더십과 비전, 전략 개발과 이의 달성을 위한 동기부여를 전달하여야 합니다.
- 협상과 갈등을 관리하여 합의를 이끌 수 있어야 합니다.
- 문제가 발생하면 문제를 정의하고 분석하여 대안을 만들어 담당자와 의사결정을 하여 문제를 해결하여야 합니다.
프로젝트의 경험은 조직(회사)에서 가장 중요한 자산이 됩니다.
프로젝트의 종료 시 참여한 모든 이해관계자들은 회고를 진행하여 좋은 점과 나쁜 점 수정해야 할 점을 의논하고 회고록을 작성해야 합니다.
실패한 사례는 좋은 경험이 되어 유사 프로젝트 진행 시 실수를 줄이고 성공할 수 있는 가이드가 됩니다.
이런 프로젝트의 경험은 종류별로 모아 다음 프로젝트 진행 시 찾아볼 수 있도록 카테고리화해야 합니다.
이를 프로그램관리라 합니다.
아래의 예시는 신차 개발 프로그램 하위에 공통적인 디자인 프로젝트, 트랜스미션 개선 프로젝트, 엔진 개선 프로젝트, 인테리어 개선 프로젝트 등 다양한 관련 프로젝트의 모음이 프로그램관리이다.
이런 카테고리, 종류별 모음은 향후 관련 프로젝트 진행 시 해당 프로그램의 프로젝트를 우선 검색하여 확인할 수 있다.
만약 실패한 케이스가 있다면 해당 실패 케이스는 프로젝트의 리스크요소로 관리를 할 수 있다.
포트폴리오는 효율적 관리를 목적으로 기업의 전략적 목표를 달성하는데 필요한 프로젝트나 프로그램들을 모아 놓은 집합체입니다.
아래의 예시는 세단 포트폴리오에 관련된 신차 개발 프로그램, 그랜저/아슬란 등의 프로그램이 있을 수 있습니다.
포트폴리오 하위에는 관련 포트폴리오도 있을 수도 있고 관련 프로그램/프로젝트도 있을 수 있습니다.
얼마 전 프로젝트관리에 대한 교육을 진행하면서 느꼈던 부분은 사업관리의 중요성이었습니다.
요구사항 정리도 없는 프로젝트와 PM과 개발실무를 같이 하는 팀원, 프로젝트가 어려워져도 위기의식이 없는 경영진.
교육하면서 이런 교육이 얼마나 도움이 될지 잘 모르겠다고 얘기하였습니다.
프로젝트가 실패하면 실패한 이유를 체크하고 다음부터 그런 일이 없도록 개선하는 것이 프로젝트의 관리입니다.라고 얘기하고 교육을 끝냈습니다.
좋은 프로젝트관리체계가 있다고 해도 이해하고 적용하고 관리할 수 있는 사람의 의지가 없다면 해당하는 회사는 어려움에 직면하게 될 것입니다.
그때 다시 프로젝트관리에 대한 방안을 마련한다 해도 늦지 않을까 싶습니다.
프로젝트관리는 일 년 이 년 안에 정리가 되는 것이 아닙니다. 다양하고 많은 경험, 프로젝트의 경험이 쌓이고 해당 경험을 관리하게 될 때 정립되는 것입니다.