범위

범위 계획 (프로젝트 성공률 1% 높이기)

by
“아니 그때 다 이야기된 것 아니었나? 뭐가 이렇게 자꾸 나와?”
 
 

프로젝트 범위

무슨 일이든 정해진 범위가 있다. 해야 할 일이 무엇이고 어디까지 해야 한다는, 각각의 일들이 기간을 가지고 있고 우선순위가 있지만 이 모두는 한 박스에 넣어진다. 넘칠 것 같으면 다른 박스에, 아니라면 더 작은 박스로 옮길 수도 있다. 이렇듯 일에 맞는, 범위에 맞는 일을 정해놓지 않으면 서로 얼굴 붉힐 일만 남을 뿐이다.
 
그럼 프로젝트에서 범위는 뭘까? 범위는 프로젝트가 고객에게 제공해야 할 서비스의 집합체로 계획을 수립하고 통제하는 대상이자 시작점이다. 이에 따라 계획의 적정성, 실현 가능성 및 구체성이 결정되고 범위가 변경된다고 하면 다른 영역들에 지대한 영향을 미친다. 예산이 모자를 수도 있고 투입인력이 탈출할 수 있으며 프로젝트 자체가 폐기될 수도 있는 중차대한 일이다.
 
프로젝트 범위는 그만큼 중요하다. 그래서 이의 관리를 위해 기본방침으로 잡는 것들이 있다. 첫째. 꼭 필요한 일들로 범위를 최소화하는 것이다. 총합으로서 또는 이를 구성하는 단계 내 범위를 최소화, 군집화하는 것이다. 둘째. 범위의 변경 또한 최소화한다. 범위가 변경되면 작업이 중단되거나 계획을 다시 수립해야 하고 많은 재작업이 발생할 수 있기 때문이다. 셋째. 불필요한 작업을 방지해야 한다. 특히 고객의 요구사항을 제대로 파악해야 하며 이를 통해서 고객의 지나친 요구사항들을 제어해야 하기 때문이다.
 
 

범위의 계획

범위 기술서가 우선 필요하다. 수많은 입력값을 토대로 작성한다. 입력값들은 프로젝트 착수 단계에서 고려된 계획과 제약사항들을 분석하여 의사결정과 이해관계를 정리하는데 중요한 단서가 된다. 이러한 일련의 일들은 PM이 주로 작성하고 여러 수행조직과 고객에게 프로젝트 범위에 대한 합의 기준, 의사소통 기준 및 프로젝트 종료 기준을 마련하는 목적을 갖는다.
 
여기서 범위 기술서는 WBS나 SOW와 차이점이 있다. SOW(Statement Of Work)는 보통 작업지시서, 작업 기술서 또는 시방서라 부르며 공급할 제품/서비스에 대한 상세한 설명을 담고 있다. WBS(Work Breakdown Structure)는 말 그대로 업무 분해 구조로 범위 기술서에 정의된 정보를 바탕으로 제품/서비스를 개발하는 과정에서 필요한 여러 단계의 작업 요소들을 상세하게 구성하고 조직화하는 것이다. 그래서 범위 기술서로 범위 기준을 설정하고 이 내용을 바탕으로 작업을 지시하며 이 작업을 수행하기 위해 범위를 정의하고 관리 틀을 만들어 운영한다고 보면 된다.
 
 

범위의 정의

프로젝트 범위를 한눈에 볼 수 있는 것이 뭐가 있을까? 앞서 이야기한 WBS가 이 범위를 산출물 중심으로 프로젝트 여러 요소를 군집화해 보여준다. WBS는 반복되는 분할로 더 작고 관리하게 편한 크기로 작업을 나눠 프로젝트 산출물을 체계화했다고 보면 된다. 이는 보통 PM과 프로젝트팀에서 작성하는데 이를 통해 프로젝트 전체를 조망하고 관리할 수 있는 매우 중요한 문서이다.
 
그래서 WBS는 외부적으로 PM과 고객, 내부적으로는 PM과 상위 관리자 간의 실질적 계약으로 볼 수 있으며 모든 계획의 근간이 된다. 그래서 정해진 업무 외 추가적인 요구사항이 나온다면 그 수용 여부에 대해서 고객을 설득할 수 있는 증거물로도 그 역할을 톡톡히 한다. 
 
 
WBS 작성은 범위 기술서를 바탕으로 한다. 목적을 염두에 두고 기능요구사항을 정의한 뒤 이의 달성을 위해 주요 액티비티를 정의한다. 이후 관리를 용이하게 하고 누락을 없애기 위해 계층적 분할을 하며 조직화하고 군집화한다. 여기까지 되었다면 일정을 산출하고 원가와 연계시킬 수 있으며 진척도를 관리할 지표로 사용할 수 있다.
 
 

WBS (Work Breakdown Structure)

WBS의 핵심 구성요소에는 Work Package(작업패키지) 가 있다. 이는 측정 및 관리가 가능한 WBS 최하위 작업 요소라고 보면 된다. 즉 분할의 최소단위인데 보통 80시간(2주) 내의 기간을 가지게끔 분할 규모를 설정한다. 또한 유일한 ID로 관리하는데 이를 Code of Account라고 한다. 전체적으로 보면 프로젝트 – 단계(Phase) – 작업(Task) – 작업패키지가 그것이다. 산출물 또한 중요한데 이것은 액티비티의 결과로 만들어지며 최하위 작업패키지에 매핑한다.
 
그래서 작업패키지를 어떻게 잡는가가 관건인데 의 적정 수준은 크게 두 가지로 본다. 첫째. 너무 개괄적인 분해는 아닌지? 둘째. 너무 세밀한 분해는 아닌지? 이렇게 보면 어떻게 잡으라는 말인가 하고 의문이 들 수 있는데 이 역시나 경험이 필요하다. 어느 하나 똑같은 경우는 없으며 프로젝트마다 모두 다르기 때문에 많은 시도와 결과를 통해 적정한 규모로 만들어가는 노력이 필요하다. 다만 이를 평가하는 일종의 법칙이 있다.
 
 
하나는 1~10%의 법칙인데 전체 프로젝트 기간을 영업일 기준으로 산정하고 여기에 1%에서 10%의 범위로 규모를 나누는 것이다. 또 하나는 1보고 기간의 법칙이다. 이는 작업 지연을 최소화하기 위한 것으로 프로젝트 최소 감시 주기 이내로 작업을 분할하는 것이다. 예를 들어 주간 보고가 최소 감시 주기라 하면 이 이상을 벗어나는 작업은 마지막에 가서야 결과를 통보받을 수 있기 때문에 그 위험성이 증가할 수 있는 것이다.
 
 
 
 
※ WBS 만들기
요즘 툴들이 너무나도 좋아져서 기본적인 내용만으로도 작업이 가능하다. 하지만 말이 좋아 그렇지 WBS를 만드는 일은 만만하지 않다. 역시나 어디까지 할 일을 분할해야 하는가에 대한 고민은 머리를 빠지게 한다. 그래서 여기서도 MECE(Mutually Exclusive, Collectively Exhaustive)를 중요하게 쓸 수 있다. 중복됨 없이 하나라도 누락되지 않게끔 정리하고 80시간 이내로 자르며 이것이 최소 감시 주기를 벗어나지 않게만 해도 반은 성공이다. 여기까지도 힘 드는가? 그렇다면 동료와 같이 작성하자. 왜냐면 프로젝트는 나 혼자만 하는 것이 아니니까 말이다.

프로젝트관리란? (프로젝트 성공률 1% 높이기)

by

프로젝트관리란?
앞서서 프로젝트에 대한 정의를 살펴봤다. 그렇다면 이 프로젝트를 관리한다는 것은 무엇을 의미하는가? 이 지점에서 관리라는 용어도 살펴보고 가자. 관리란 흔히 사람을 통제하고 지휘 감독하는 것이나 여러 시설이나 물건의 유지·개량 따위를 꾀하는 것을 말한다. 이를 프로젝트에 대입해 보면 목표를 세우고 계획을 짜며 일들을 수행하고 목표를 달성해 가는 과정에서 필요한 수많은 자원과 시간 그리고 노력은 프로젝트의 관리 측면이다. 이는 매우 필수적이고 중요하며 프로젝트와 관리가 별개가 아닌 하나로서 인식해야 할 필요성을 느낀다.

그래서 프로젝트관리는 “프로젝트 요구를 만족시키기 위해 지식, 기술, 도구 및 기법들을 프로젝트 활동 중에 사용하는 것“이라 할 수 있다. 다시 말해 프로젝트 요구사항을 충족시키고 만족시키는 것, 이를 위한 모든 요소를 잘 이해하고 관리하여 목적한 바를 달성해 나아가고 더 나아가 프로젝트의 성공적 완료를 가능케 한 자원, 특히 조직의 역량을 확보하고 강화하는 것이 그 이면이라고 본다.

그러면 이러한 프로젝트의 성공률은 얼마나 될까? 다소 오래된 자료이긴 하나 지금까지도 유효한 Standish Group의 2010년 Chaos Summary를 보면 30% 정도의 프로젝트만 성공한다고 한다. 그렇다면 나머지 70%는 실패한다는 이야기인데 그 원인은 주로 1) 요구사항의 부정확성 2) 사용자 환경의 이해 부족 3) 불충분한 자원 4) 비현실적인 사용자 기대치 5) 관리지원의 부족 6) 변경 관리의 미흡 7) 프로젝트 계획의 미비 등이라고 한다. 이는 곧 관리 부재의 결과이고 특정 몇몇 사람이 아닌 조직 전체의 문제로 비친다. 특히 관리의 제약 측면에서 살펴보면 다음과 같다.

 

프로젝트 관리의 3대 제약
프로젝트는 아래 3가지에서 절대 벗어나지 않는다. 이는 프로젝트의 성공과 실패를 구분하는 기준이며 모든 단계의 품질을 좌지우지한다.

● 범위
: 프로젝트에 존재하는 필요와 기대 사이의 요구사항이다. 프로젝트 초반 고객의 요구사항을 제대로 파악하지 못하면 범위는 계속 흔들린다. 상세한 요구사항은 프로젝트의 첫 단추다. 이를 위해 요구사항관리라는 별도의 프로세스를 만들어 놓고 있으며 이를 통해 유기적인 범위관리에 신경을 쓴다.

● 일정
: 프로젝트의 시작과 끝, 그 기간이다. 프로젝트계획 시 범위에 기반한 일정을 수립하지만 철저한 관리가 되지 않는다면 일정은 자연스럽게 지연이 된다. 프로젝트관리자는 일정에 민감해야 한다. 전체 일정과 하루 일정. 진척도는 관리되어야 하며 이슈가 발생하면 전파하고 해결책을 찾아야 한다.

● 원가
: 프로젝트에 할당된 예산은 타당한가? 제대로 된 수요조사와 시장조사를 통해 원하는 사양에 충족한 것들을 선별, 구매했는가? 특히 인건비는 제대로 평가받고 있는가? 예산이 부족하다고 제일 먼저 인건비에 손을 대지는 않았는가? 그래서 실력 있는 개발자들을 외면하고 있지는 않은가? 아니면 한 사람에게 너무 의존하는 것은 아닌가?

 

성공과 실패
모든 프로젝트는 성공하여야 한다. 그 끝을 위해서 모든 이해당사자는 서로 협력한다. 하지만 성공과 실패의 기준이 무엇인가에 대해서는 의견이 분분하다. 알고는 있지만 서로 상대적인 개념 사이에서 위의 3가지 제약은 훌륭한 기준을 마련해준다. 이를 바탕으로 프로젝트를 관리하고 관리의 성공과 실패 여부는 핵심 이해당사자들에게 달려있다.

이해당사자. 이들은 프로젝트와 밀접한 경영진, 개발자, 관리자, 고객 등이 있다. 이 중에서 고객의 요구사항에 얼마나 잘 부응했는가가 성공을 가늠한다. 3가지 기준에 충실한 관리, 그러면서 고객 요구사항의 충족. 성공은 멀리 있지 않다. 그만큼 실패도 성공의 반대편 가까운 곳에 서 있다. 부정확한 요구사항, 사용자의 몰이해, 충분하지 못한 자원들, 비현실적인 기대치와 무관심, 변화무쌍한 상황들의 관리 부재, 이들을 아우르는 계획의 미비. 그렇다고 유명하단 프로세스나 방법론이 모든 문제를 해결해 줄 수는 없다.

프로젝트는 요리와도 같다. 여러 좋은 재료들을 모아 정해진 레시피대로 정성껏 요리하면 맛 좋은 음식 맛을 볼 수 있다. 이 요리에 있어 요리사는 전체적으로 볼 수 있어야 하고 집중하여 관리하며 문제가 발생했을 때 이를 개선하는 노력을 통한 최적화! 나에게 맛 좋은 음식도 중요하지만, 고객의 입맛에 맞게, 원하는 사항들을 충족시키고 더 나아가 미처 모르던 맛까지 제공한다면 프로젝트는 성공이라 말해도 부족하지 않다.

 

이해당사자
프로젝트에는 수많은 이해당사자가 존재하며 이들은 프로젝트의 성공 여부를 결정짓는 매우 중요한 개인 혹은 조직이다. 영어로는 stakeholder. ‘지주를 붙잡는 사람’이라는 뜻처럼 각각의 역할과 책임이 막중하다.

  º 프로젝트관리자: 프로젝트 수행 전반의 책임자
  º 고객: 프로젝트 결과물을 사용하게 될 개인 혹은 조직
  º 기능부서 관리자: 프로젝트팀원이 속한 부서의 관리자
  º 경영진: 프로젝트를 수행하는 조직의 최고 관리자
  º 프로젝트부서: 프로젝트를 수행하는 사람 혹은 조직

이들은 그 특성과 영향력 수준에 따라 분류할 수 있고 각자의 이해 분야가 다르기 때문에 여러 갈등의 양상을 보일 수 있다. 이에 프로젝트관리자는 갈등 당사자 간의 이해의 합의를 구하고 해결책을 제시해야 하고 고객의 입장에서 움직여야 한다. 그래서 조직적인 대응으로 PMO를 구성하기도 하고 프로젝트 조직을 프로젝트 상황, 기업조직구조, 방침 등에 따라 기능 조직, 매트릭스 조직, 프로젝트 조직 등으로 나누어 사전에 결정하고 깊게 운영하여야 한다.

 

 

※ 너는 너, 나는 나
얽히고 섥힌 사람들로 북적이는 프로젝트에서 프로젝트관리자는 너무나도 중요하다. 그런데 요즘은 이런 부담을 떠안기 싫어 도망가는 사람들로 PM을 할만한 사람 찾기가 하늘의 별 따기 수준이다. 저는 개발만 하고 싶어요! 라는 사람들도 업무를 알아야 개발이 될 텐데 하물며 PM은 어떠할까? 세상은 바뀌어도 PM은 가치는 영원하다.