[PMP] 범위관리
이 글은 제가 과거에 운영했던 사이트인 http://dotnet.mkexdev.net 의 글을 옮겨온 것입니다.
그 전에 운영했었던 사이트(mkex.pe.kr)은 흔적도 없이 사라 졌습니다. 그속의 글들도 모두...
그래서 이 사이트도 사라지기 전에 옮기고 싶은 글을 조금씩 이 블로그로 이동시키려 합니다.
(원본글) http://dotnet.mkexdev.net/Article/Content.aspx?parentCategoryID=2&categoryID=27&ID=483
---
프로젝트의 범위는 일정과 비용에 직접적인 영향을 주는 근간이 된다
흔히 말하는 스펙(Spec)인데, 무엇을(What?) 만들 것인가에 대한 정의라 할 수 있다
범위는 제품범위(Product Scope)와 프로젝트범위(Project Scope)로 나눌 수 있는데,
제품범위는 최종 결과물에 대한 스펙 정의이며
프로젝트 범위는 최종 결과물은 물론 중간 산출물, 중간에 수행되어야 하는 일등을 모두 포함한 개념이다
PM(Project Manager)은 제품범위를 만족시키는 것은 물론 프로젝트 범위도 만족시켜야 한다
* 범위관리 프로세스
범위기획 -> 범위정의 -> WBS 생성 -> 범위검증 -> 범위통제
범위기획에서는 프로젝트의 범위를 식별하고 범위에 대한 관리,통제를 위한 기준 및 절차를 정의하는 과정이다
범위정의에서는 이해관계자들을 식별하고 상세한 프로젝트 범위 명세서를 만드는 과정이다
여기서 재밌는 것은 범위정의 단계에서 이해관계자를 식별한다는 것이다
인적자원관리나 의사소통관리에서나 등장할 법한 이해관계자 식별 활동이 왜 범위정의에 포함되어 있는 것일까?
이는 바로, 이해 관계자들의 기대치를 제품 및 과정에 반영하고자 하는 이유에서다
즉 이해관계자를 분석해서 다양한 이들의 영향력과 관심사를 식별하고, 그들의 요구, 희망사항 및 기대치를
관리함으로써 프로젝트를 보다 효과적으로 수행하고자 하는 의미가 담겨져 있다
물론 범위정의 단계이 핵심 산출물은 '범위 명세서' 임은 두말 할 것이 없다
범위명세서에는 프로젝트 목표, 제품 범위, 프로젝트 요구사항, 인도물, 인수 기준, 위험, 일정 이정표, 자금 한계,
형상 관리 요구사항, 사양서 등을 구체적으로 기술하도록 한다
* WBS (Work Breakdown Structure)
작업분류체계라 해석되는 WBS는 범위관리에 핵심 산출물이라 할 수 있다
프로젝트의 범위와 인도물, 작업을 더 작고 관리하기 쉬운 구성요소로 분할한 것이다
WBS는 일정과 비용의 기준선이 되며 의사소통의 도구로써 활용된다
다음과 같은 과정으로 범위는 구체화 된다
요구사항 -> 예비 프로젝트 범위 명세서 -> 프로젝트 범위 명세서 -> WBS
중요한 것은 WBS는 관리가능한 수준으로 분할 한다는 것이다
WBS를 어느 정도 까지 분할, 즉 상세화 해야 하는 것일까?
분할을 너무 과도하게 하면 통제는 용이한 반면 관리 비용이 증가하며
분할을 약하게 하면 관리 비용은 감소하지만 통제에 대한 어려움이 있을 수 있다
WBS의 분할 원칙에 대한 기준을 참고하도록 하자
1) 40 시간의 원칙
주 5일, 일일 8시간 근무 환경에서 40시간은 작업 소요 기간이 1주가 된다는 의미이다
즉 WBS 의 최소 크기를 1주 단위로 정하는 것을 말한다
2) 80 시간의 원칙
작업 소요 기간이 2주가 된다는 의미이다
WBS의 최대 크기를 2주로 제한하는 것이 좋다는 말이다
WBS 에는 프로젝트 범위의 모든 것이 기술되어져야 한다. WBS에 없는 것은 프로젝트 범위 밖에 있는 것이다
다음은 WBS의 3가지 구성요소이다
Code of Account, WBS 사전, Work Package
Work Package
WBS의 더 분할한 산출물이다, WBS의 최하위 수준의 작업 요소를 정의한 것이다
Code of Account
WBS의 고유 식별 번호로써, Work Package를 고유하게 식별하는 식별자이다
분류된 위치와 레벨(깊이)를 알 수 있게 하는 분류 체계이다
WBS 사전
수행해야 하는 작업의 명칭, 내용 및 시기 등을 기술한 문서이다
즉 업무, 일정, 계획, 수립 정보를 포함하는 작업요소에 대해 설명된 문서이다
* 범위 검증
말 그대로 범위대로 작업이 되었는지 검증하는 단계이다
이해관계자들로부터 프로젝트 범위를 공식적으로 인정받는 중요한 과정이다
만일 프로젝트가 완료되기 전에 중단되더라도 반드시 해당 단계의 완료 수준과 범위를 문서화 해야 한다
범위검증은 품질 통제와 구별된다
품질 통제가 Q/A 담당자에 의해 품질 기준선에 만족 했는지 심사하는 과정이라고 한다면
범위검증은 고객이 제품 인수를 위해 검증하는 단계라 할 수 있다
만일 품질검사는 만족했는데 고객이 만족하지 못한다는 것은 무슨 뜻이 될까?
바로 요구사항 분석이 실패했다는 것이다
즉 제품은 범위명세 대로 잘 만들었고 품질도 그러한 기준에서 통과 했지만 최종 고객이 만족하지 않는 것은
최초 범위 명세 부터 잘못되었다는 의미가 된다
* 범위 통제
범위를 중간에 변경하는 것이 매우 크리티컬한 것이 된다
범위 통제는 일정 통제, 원가 통제, 품질 통제와 완전하게 통합되어 같이 관리되어져야 한다
그리고 범위 변경은 반드시 변경 통제 시스템를 통해 정형적이고 절차적인 과정을 통해 수행되어져야 한다
범위 변경으로 인해 발생하는 여러 가지 사항들을 면밀히 검토해야 하며 수반되는 일정 및 원가의 변경을
같이 고려해야 하며 적절한 승인절차를 거쳐서 이루어 져야 한다