프로젝트 범위 관리
- 요구사항 수집 : 제안 요청서, 프로젝트 헌장, 식별된 이해관계자 등으로부터 요구사항을 수집
- 범위 정의 : 프로젝트의 주요 인도물을 다루기 쉬운 요소들로 분할
- WBS (작업 분류 체계) 작성 : 실제 작업 가능한 수준으로 WBS를작성
- 범위 검증 : 완성된 프로젝트 인도물의 공식적 인수에 필요
- 범위 통제 : 프로젝트 범위의 변경 여부 및 내용을 통제
목적
이해관계자의 요구사항들이 프로젝트 범위에 포함되었는지 보장하고, 오로지 필요한 작업만 수행될 수 있도록 관리하는 지식 영역임. 고객이 요청하지도 않은 작업을 수행할 경우 불필요한 비용 증가 및 일정 지연을 초래할 수 있기 때문임. 따라서 범위에 포함/미포함되는 요구사항을 확실하게 식별할 수 있어야 함.
범위
- 프로젝트 범위
- 특정 특색과 기능의 제품, 서비스, 결과물 등을 인도하기 위해 수행하는 작업
- 프로젝트 계획에 따라 결정됨.
- 제품 범위
- 제품, 서비스, 결과물 등을 특징짓는 특색과 기능
- 프로젝트 요구사항에 따라 결정됨.
생애주기
프로젝트 범위 관리는 생애주기에 따라 달라짐.
1. 예측적 생애주기
초기에 모든 범위가 결정되기 때문에 이후 발생하는 범위 변경은 통합 변경통제 수행 절차에 따라 꾸준히 관리됨
범위 기준선은 승인된 프로젝트 범위 기술서, WBS, WBS 사전
이 기준선은 반드시 공식적인 변경통제 절차를 통해서만 변경될 수 있고, 범위 화인과 범위 통제 등 감시/통제 프로세스의 기준선으로 작용함. 즉, 현재 프로젝트 범위가 범위 기준선에서 벗어날 경우 범위 확인이 완료될 수 없으며, 이때 범위 통제 프로세스를 실시해야 함.
2. 적응적/애자일 생애주기
프로젝트가 일련의 반복 작업으로 나뉘어 시행됨.
작업이 시작되기 전에 팀은 우선순위에 따라 정렬된 제품 백로그(Product Backlog) 목록을 보고, 다음 번 반복에서 완료될 수 있는 항목의 개수를 결정. 범위 기준선이 아닌 백로그에 요구사항이 반영되어 있으며, 매 반복 작업마다 요구사항 수집, 범위 정의, WBS 작성 프로세스를 거침.
- 전통적인 삼각형 : 범위가 초기에 정의되므로 일정과 원가가 변동됨.
- 애자일 삼각형 : 일정과 원가가 고정되어 있는 상태에서 범위가 변동됨.
-> 이해관계자가 매 반복 작업 결과물에 대한 피드백을 제공하고 제품 백로그가 실제 요구사항을 반영했는지 체크해야 하기 때문. 이 때 범위 확인과 범위 통제 프로세스가 반복됨.
프로세스
1. 범위 관리 계획 수립
프로젝트 전반에 걸쳐 프로젝트 범위 관리에 대한 지침과 방향을 제공하는 범위 관리 계획서를 작성
- 프로젝트 헌장 : 상위 수준의 프로젝트 상세 설명, 가정, 한계, 요구사항 등을 기재한 문서
- 도구 및 기법 : 데이터 분석 기법이 사용될 수 있음.
- 범위 관리 계획서 : 범위에 대한 정의, 개발, 감시, 통제, 검증하는 전반적인 계획이 포함된 문서
- 요구사항 관리 계획서 : 이해 관계자들의 요구사항을 분석, 문서화 및 관리하는 방법을 기술한 문서
2. 요구사항 수집
이해 관계자의 니즈와 요구사항을 결정, 문서화 및 관리하는 단계
요구사항이란 인도물에 반드시 포함되어야 하는 조건이나 능력을 의미.
수집된 요구사항들은 WBS로 발전함.
비즈니스 분석가는 요구사항을 정의, 관리, 통제하는 핵심적인 역할을 함.
PM은 비즈니스 분석가와 협력해 이해 관계자들의 요구사항이 충실히 반영하도록 노력해야 함.
-> 비즈니스 분석가는 요구사항에 책임이 프로젝트 매니저는 프로젝트 인도에 대한 책임이 있음.
3. 범위 정의
프로젝트와 제품에 대한 구체적인 세부 설명을 개발하는 단계
제품, 서비스 또는 결과물의 경계와 승인 기준을 설명.
범위 정의 프로세스는 상당히 반복적일 수 있는데, 반복적 생애주기 프로젝트에서 전체 프로젝트에 대한 통찰은 상위 수준에 머무르고, 상세한 범위는 매 반복 주기 때마다 결정됨.
프로젝트 범위 기술서
프로젝트 범위와 주요 인도물, 가정사항, 제약사항 등을 기술한 문서
실행 단계에서 팀 작업의 방향을 안내하며, 변경 또는 추가 요청이 프로젝트 경계를 벗어나는지 여부를 평가하는 기준선을 제공함.
4. 작업 분류 체계(WBS) 작성
프로젝트 범위를 쪼개고 또 쪼개어 가능한 가장 작은 작업까지 분할하여 도식화한 문서
목표를 달성하고 필요한 인도물을 산출하기 위해 수행할 전체 작업의 범위를 세분한 수직적 계층로임.
5. 범위 확인
고객이 '인도물을 검토해봤더니 내가 요구한 건 다 해줘서 만족스럽다. 서명해주겠다.' 까지의 단계 또는 '인도물을 검토해봤는데 수정이 필요한 부분이 있으니 수정해달라. 그 후에 서명해주겠다'의 단계임.
-
검수된 인도물(품질 통제 프로세스의 출력물)이 입력물로 들어와서 -> 인수된 입력물이 출력물로 나감
-
품질이 검증된 인도물만이 범위 확인 과정을 거칠 수 있음.
-
고객이나 스폰서와 함께 인도물을 검토하는 활동 및 인도물을 공식적으로 인수하는 절차가 수반됨.
범위 확인은 1. 프로젝트가 종료되었을 때 2. 매 단계가 종료되었을 때 시행됨.
주로 매 단계 종료 시 범위 확인을 하는 것이 더 일반적인데, 범위 확인에 대한 시기는 사전에 범위 관리 계획 수립 프로세스의 출력물인 범위 관리 계획서에 반영된 사항이어야 함.
- 고객 검토 후 결함이 발견되면 변경 요청을 해야 함.
이 때 발생한 결함이나 고객의 미승인 사유를 문서화해야 하므로 프로젝트 문서를 갱신함.
6. 범위 통제
범위 상태 감시 및 범위 기준선에 대한 변경 사항을 관리하는 단계
- 범위를 늘리고 좁힘에 따라 목표, 주공정, 성과지표, 자원 등 여러 요소가 영향을 받게 되므로 범위 통제는 매우 중요함.
- 특히 가장 중요해야할 두 가지는 1. 범위 추가와 2. 금 도장임.
- 범위 추가
고객의 예고없는 범위 변경 요청에 정해진 절차를 무시하고 바로 승인하는 행위 - 금 도장
프로젝트가 완료되고 예산이 남았울 경우 고객이 요청하지도 않은 기능을 마음대로 추가 설치하여 '인도물을 불필요하게 장식'하는 행위 (요구사항 초과 실행)
만일 고객의 요구사항이 변경되어 범위가 변경되어야 하는 경우 범위 기준선 뿐만 아니라 다른 기준선들이 모두 변경되어야 함. 범위 추가로 인해 비용과 일정이 늘어나는 것은 당연한 일이기 때문임.
따라서 프로젝트 관리 계획서를 갱신해야 하고, 요구사항 문서와 요구사항 추적 매트리스가 포함된 프로젝트 문서 또한 갱신해야 함.
참고 자료
이런 유용한 정보를 나눠주셔서 감사합니다.