범위 관리

범위 관리에서 다루는 내용

건설업자는 공사 현장에 울타리를 세워 경계를 표시합니다. 프로젝트의 범위를 정하는 목적도 같습니다. 범위 관리는 프로젝트에 필요한 작업을 정의하고, 팀이 그 작업을 모두 완료하며 합의한 경계를 지키도록 합니다.

범위를 어떻게 결정하고 관리하고 통제할지 미리 계획합니다. 모든 이해관계자로부터 요구 사항을 수집하고 명확하게 정의한 범위를 공식 승인받습니다. 스폰서나 소수의 사람에게만 요구 사항을 수집하면 범위를 잘못 정할 수 있습니다. 대규모 프로젝트에서는 요구 사항 수집에 더 많은 시간, 노력, 자원이 들기 때문에 범위를 명확히 정의하는 것이 특히 중요합니다.

승인된 범위를 기준으로 범위 관리 계획서 안에서 작업을 수행합니다. 골드 플레이팅, 즉 불필요한 기능이나 작업을 더하는 행위는 금지됩니다. 범위를 계속 감시해 모두가 어떤 작업이 프로젝트에 포함되고 어떤 작업이 범위 밖인지 구분할 수 있도록 합니다.

범위 변경이 시간, 원가, 위험, 품질, 자원, 고객 만족도, 기타 관련 영역에 미치는 영향을 평가합니다. 통합 변경 관리로 변경을 승인합니다. 변경을 제안한 사람이 변경 요청서를 갱신하고, 변경 사항은 변경 통제 등록부에서 추적합니다.

전체 크기 도표 열기 ↗

전체 크기 도표 열기 ↗

제품 범위

제품 범위는 “고객이 무엇을 원하는가?”라는 질문에 답합니다. 조직은 제품 범위를 정의하는 별도의 프로젝트를 진행할 수도 있고, 현재 프로젝트의 요구 사항을 수집하면서 정의할 수도 있습니다.

소프트웨어 프로젝트의 제품 범위는 예를 들어 “내부 및 외부 고객의 요구 사항을 충족하는 새 워크플로 애플리케이션”일 수 있습니다. 프로젝트가 제품 범위를 충족했는지 확인하려면 완성된 애플리케이션을 요구 사항 문서와 프로젝트 범위 기술서에 기록된 요구 사항과 비교합니다.

프로젝트 범위

프로젝트 범위는 제품 범위를 구현하는 데 필요한 작업입니다. 소프트웨어 사례에서는 애플리케이션 개발 작업과 이를 인도하는 데 필요한 계획 수립, 조율, 관리 활동이 포함됩니다. 회의와 보고가 그 예입니다. 이러한 작업은 프로젝트 관리 계획서와 그 일부인 범위 관리 계획서에서 다룹니다. 프로젝트나 단계가 끝나면 완료된 작업을 프로젝트 관리 계획서의 범위 기준선과 비교해 합의된 범위를 충족하는지 확인합니다.

범위 관리 계획서

범위 관리 계획서는 범위의 계획, 실행, 통제를 다룹니다. 여기서 사용하는 프로세스 체계에서는 팀이 프로젝트 관리 계획 수립 과정에서 범위 관리 계획서를 작성하고 이를 프로젝트 관리 계획서에 포함합니다. 다루는 내용은 다음과 같습니다.

• 프로젝트가 범위에 명시된 작업을 완수하는 방법.
• 범위에 명시된 작업을 완수하는 데 팀이 필요로 하는 도구.
• 팀이 고려해야 할 기업 환경 요인.
• 팀에 필요한 조직 프로세스 자산.
• 팀이 프로젝트 전반에 걸쳐 범위를 관리하고 통제하는 방법.

조직은 범위 관리용 템플릿, 양식 또는 표준을 갖춰야 합니다. 이는 프로젝트 작업에 필수적입니다. 계획서 일부를 표준화할 수 있지만 프로젝트마다 별도의 계획서가 필요합니다. 프로젝트 관리자는 범위 관리 계획서를 참고해 종료 시점까지 프로젝트를 이끌고 측정합니다.

계획서를 단계별로 만들고 계획 수립 중 수정할 수 있습니다. 먼저 범위를 정의하는 방법을 정합니다. 프로젝트 전체를 계획한 뒤, 범위를 어떻게 이행하고 통제할지 정해 범위 관리 계획서에 추가합니다. 이후 인적 자원 계획처럼 후속 계획을 세우는 과정에서 범위가 추가로 식별되어 계획서를 다시 수정해야 할 수도 있습니다.

계획서를 작성하려면 프로젝트 관리자가 범위를 충분히 이해해야 합니다. 작업을 시작하기 전에 제품 범위와 프로젝트 범위를 모두 파악합니다. 범위 관리 계획서 작성은 프로젝트 관리의 필수 절차입니다.

범위 관리 프로세스

1. 요구 사항을 파악합니다. 프로젝트 헌장에 설명된 비즈니스 케이스를 근거로 각 요구 사항이 프로젝트에 도움이 되는지 확인합니다.
2. 제품 범위와 프로젝트 범위를 정의할 때 이해관계자의 필요를 고려합니다.
3. 작업 분류 체계(WBS)로 범위를 관리하기 쉬운 작은 단위로 나눕니다.
4. 고객의 관점에서 프로세스를 설계합니다.
5. 프로젝트 전반에서 범위 성과를 측정하고 필요에 따라 조정합니다.

불필요한 작업을 거절할 준비를 합니다. 범위를 추가하면 원가, 시간, 노력이 더 들어갑니다.

요구 사항 수집

요구 사항은 프로젝트나 제품이 명시된 목표를 달성하기 위해 무엇을 필요로 하는지 설명합니다. 품질, 비즈니스 프로세스, 규제, 규정 준수, 프로젝트 관리 등 여러 영역을 다룰 수 있습니다. 요구 사항 수집은 제품 요구 사항과 프로세스 요구 사항을 모두 다룹니다. 요청을 포함하기 전에 각 요청을 목표와 대조해 확인합니다.

착수 단계에서 프로젝트 헌장은 프로젝트와 제품의 상위 수준 요구 사항을 담습니다. 요구 사항 수집에서는 모든 이해관계자로부터 더 구체적인 정보와 관련 가정을 수집합니다. 요구 사항을 놓치면 실패하거나 변경이 반복되거나 프로젝트 내내 갈등이 발생할 수 있습니다.

먼저 이해관계자를 파악하고 이해관계자 등록부에 기록합니다. 한 프로젝트에 수백 명의 이해관계자가 있을 수 있으며, 집단마다 의견을 수집하는 방식이 다를 수 있습니다. 프로젝트 작업이 시작되기 전에 요구 사항 수집에 필요한 시간과 노력을 따로 확보합니다. 수집이 불완전하면 비용과 노동력이 많이 드는 변경이 발생할 수 있습니다. 과거 정보와 교훈이 도움이 될 수 있습니다. 프로젝트와 이해관계자에 맞는 기법을 고릅니다. 위험 관리에서 위험을 식별할 때도 이러한 기법을 쓸 수 있습니다.

과거 기록 검토

과거 기록과 교훈은 유사 프로젝트에 무엇이 필요했는지 보여 주고 관련 프로세스를 파악하는 데 도움이 됩니다. 프로젝트에 새로 합류한 사람이 여러 팀의 기대를 이해하는 데도 도움이 됩니다. 다른 프로젝트 관리자가 범위를 정의할 때 저지른 실수를 확인해 그 프로젝트에서 놓친 요구 사항을 파악할 수도 있습니다.

인터뷰

전문가 인터뷰라고도 하는 인터뷰는 프로젝트 관리자가 이해관계자의 제품 또는 프로세스 요구 사항을 파악하는 데 도움이 됩니다. 일대일이나 집단으로 진행할 수 있고 이메일, 전화, 서신이나 다른 방법을 이용할 수도 있습니다.

집중집단

사회자나 진행자가 선정된 이해관계자나 분야 전문가 집단에서 의견과 요구 사항을 수집합니다. 토론은 제품이나 프로젝트의 한 측면에 초점을 맞출 수 있습니다.

진행자가 이끄는 워크숍

진행자가 이끄는 워크숍에서는 관점이 서로 다른 이해관계자들이 모여 제품이나 서비스의 요구 사항을 정의합니다.

브레인스토밍

브레인스토밍은 참가자들이 서로의 아이디어를 발전시켜 짧은 시간에 많은 아이디어를 내는 방법입니다. 예를 들어 한 참가자가 범위를 정의하는 방식을 제안하면, 그 제안이 다른 사람의 아이디어를 자극하고, 다시 또 다른 아이디어로 이어집니다. 조직 안팎에서 담당 기능, 배경, 관점이 서로 다른 사람들을 초대합니다.

명목 집단 기법

브레인스토밍을 마친 뒤 참가자들이 가장 좋은 아이디어에 순위를 매깁니다.

델파이 기법

이 합의 기법에서는 전문가들이 직접 모이지 않고 익명으로 참여합니다. 전문가들에게 정보를 요청하고 답변을 취합한 뒤 결과를 다시 보내 추가 검토를 요청합니다. 전문가들이 합의할 때까지 반복합니다.

마인드맵

마인드맵은 아이디어를 내고 논리적으로 묶는 데 도움이 됩니다. 중심 아이디어에서 가지를 뻗어 주요 아이디어를 표시하고, 다시 각 가지에서 관련 아이디어를 뻗어 나갑니다.

친화도

다른 요구 사항 수집 기법에서 나온 아이디어를 유사성에 따라 묶습니다. 각 요구 사항 묶음에 제목을 붙입니다.

전체 크기 도표 열기 ↗

설문지와 설문조사

설문지로 여러 질문에 대한 답변을 수집합니다. 설문지와 설문조사를 이용하면 많은 사람에게 의견을 물을 수 있습니다.

관찰

제품을 사용할 가능성이 있는 사람이 일하는 모습을 관찰합니다.

시제품

시제품은 제안된 제품의 모형입니다. 이해관계자에게 보여 주고 의견을 구합니다. 모든 요구 사항을 파악하고 모형을 확정해 승인하려면 팀이 여러 버전을 만들어야 할 수 있습니다.

집단 의사결정

여러 이해관계자의 의견을 받으면 서로 충돌하는 아이디어나 혼란, 갈등이 생길 수 있습니다. 각 아이디어를 검토하고 분석해 채택 여부를 결정합니다. 채택한 아이디어는 우선순위를 매긴 뒤 프로젝트 문서에 기록합니다.

• 만장일치. 모두가 요구 사항에 동의하므로 결정을 내리기 쉽습니다.
• 독단적 결정. 한 사람이 집단 전체를 대신해 결정합니다. 결정은 빠르지만 다른 이해관계자가 동의하지 않을 수 있습니다.
• 과반수. 구성원의 절반을 초과하는 인원이 지지하는 결정을 채택합니다.
• 최다 득표. 과반수의 지지를 얻은 선택지가 없다면 가장 많은 사람이 지지한 선택지를 채택합니다.
• 합의. 집단이 받아들일 수 있는 결정을 내립니다. 다른 선택지를 선호했던 구성원도 대다수가 지지하는 결정을 받아들입니다.

요구 사항 문서

팀이 요구 사항을 수집한 뒤에는 명확하고 모호하지 않게 기록합니다. 요구 사항 문서는 요구 사항 수집의 산출물입니다. 표현이 불명확한 요구 사항은 오해를 부를 수 있습니다. 문서에 기록된 요구 사항이 명시된 목표를 충족하는지 이해관계자에게 확인해 달라고 요청합니다. 이들의 의견은 적절한 요구 사항을 수집했는지, 결과 산출물을 인수할 수 있을지 확인하는 데 도움이 됩니다.

이해관계자 요구 사항의 균형 조정

프로젝트가 목표를 달성할 수 있도록 요구 사항에 우선순위를 매기고 갈등을 해결합니다. 모든 요구 사항을 충족할 수 없다면 범위, 시간, 원가, 품질, 자원, 위험, 고객 만족도에 관한 상충하는 요구 사이에서 균형을 잡을 방법을 찾습니다.

수집을 마친 뒤에도 요구 사항 사이의 균형을 계속 조정합니다. 나중에 일부 이해관계자의 요구 사항이 프로젝트의 요구 사항이나 다른 이해관계자의 요구 사항과 충돌할 수 있습니다. 프로젝트 관리자는 이러한 요구를 프로젝트의 이익과 비교해 갈등을 해결합니다.

프로젝트 목표를 명확히 설정하고, 요구 사항 수집에서 모든 이해관계자의 요구 사항을 빠짐없이 파악하고 우선순위를 매깁니다. 두 가지 모두 요구 사항 사이의 균형을 맞추기 위한 전제입니다.

상충하는 요구 사항 해결

각 부서가 프로젝트에서 원하는 바는 다를 수 있습니다. 예를 들어 위험 관리 팀은 위험을 발견해 프로젝트 속도를 늦추고 싶어 하지만 운영 팀은 더 빨리 끝내려 할 수 있습니다. 양쪽이 모두 받아들일 해결책을 찾습니다.

복잡한 갈등에는 경영진의 참여가 필요합니다. 프로젝트 관리자는 어떤 요구 사항이 비즈니스 케이스를 뒷받침하는지 확인하고, 프로젝트 헌장, 범위 기술서, 제약을 검토합니다.

최초 프로젝트 추진 이유와 관련 있더라도 프로젝트 목표나 승인된 헌장의 범위를 벗어난 요청은 거절합니다. 헌장 변경 제안은 스폰서와 논의해 승인을 받습니다. 원가가 가장 중요한 제약이라면 원가를 올리는 요청은 채택될 가능성이 낮습니다. 다른 제약에 심각한 영향을 주지 않고 원가를 억제하는 요청은 채택될 가능성이 더 높습니다. 이러한 기준에 맞지 않는 요청은 향후 프로젝트에서 검토할 수 있습니다.

요구 사항 관리 계획서

이 장에서는 요구 사항 관리 계획서를 요구 사항 수집의 산출물로 설명합니다. 계획서는 다음 질문에 답합니다.

• 어떤 방법으로 요구 사항을 식별할 것입니까?
• 각 요구 사항에 어떤 분석이 필요합니까?
• 요구 사항의 우선순위는 어떻게 정합니까?
• 요구 사항은 어떻게 관리합니까?
• 요구 사항은 어떻게 추적합니까?
• 요구 사항 추적 매트릭스는 어떤 정보를 제공해야 합니까?

요구 사항 추적 매트릭스

대규모 프로젝트에서는 문서화가 미흡하면 요구 사항을 놓칠 수 있습니다. 하나의 요구 사항에서 여러 세부 내용이나 추가 설명이 생기면 각 내용이 어디에서 비롯됐는지 기억하기 어렵습니다. 요구 사항의 근거를 놓치면 프로젝트 목표를 달성하지 못할 수 있습니다.

요구 사항 추적 매트릭스는 요구 사항 수집의 또 다른 산출물입니다. 요구 사항을 프로젝트 목표, 다른 요구 사항 또는 둘 다에 연결해 전략적 목표를 뒷받침합니다. 프로젝트 전반에서 제품 범위나 프로젝트 범위의 변경 제안을 분석할 때 사용합니다.

전체 크기 도표 열기 ↗

범위 정의

요구 사항 수집에서 나온 요구 사항 문서, 프로젝트 헌장, 프로젝트 위험·가정·제약 정보를 사용해 제품 범위와 프로젝트 범위를 정의합니다. 프로젝트와 산출물에 포함되는 항목과 제외되는 항목을 명시합니다.

계획 수립은 반복적인 과정입니다. 요구 사항이 파악되면 이를 바탕으로 일정과 예산을 개발합니다. 일정이나 예산이 경영진 또는 스폰서의 기대를 충족하지 못하면 프로젝트 제약을 검토하고 요구 사항을 예산 및 일정과 조율합니다. 범위, 시간, 원가 목표를 충족할 수 있는 대안을 경영진에게 제시합니다. 일정 단축, 다른 작업 방식 모색, 예산이나 범위 조정 등이 대안이 될 수 있습니다. 목표는 범위에 명시된 작업을 완수할 수 있는 현실적인 일정과 예산입니다.

제품 분석

고객과 스폰서가 제공한 제품 목표와 설명을 분석합니다. 분석 결과를 바탕으로 구체적인 산출물을 식별합니다.

프로젝트 범위 기술서

프로젝트 범위 기술서는 범위 정의의 주요 산출물입니다. 작성에 시간이 걸리며 외부 전문가를 비롯한 여러 이해관계자의 의견이 필요할 수 있습니다. 두 가지 유형의 제외 항목을 명시합니다.

1. 승인되지 않은 범위. 요청이 있었으나 범위에 포함하도록 승인된 적이 없는 작업을 식별합니다.
2. 불필요한 범위. 사람들이 오해하기 쉬운 경계를 명확히 합니다.

프로젝트 범위 기술서는 WBS 및 WBS 사전과 함께 범위 기준선을 구성합니다. 범위 기준선은 프로젝트 관리 계획서의 일부입니다. 기술서에는 다음 항목을 포함할 수 있습니다.

• 제품 범위.
• 프로젝트 범위.
• 산출물.
• 제품 인수 기준.
• 범위 밖 활동.
• 제약과 가정.

작업 분류 체계(WBS) 작성

크고 작은 모든 프로젝트에는 WBS가 필요합니다. WBS는 프로젝트 전체 범위를 관리 가능한 산출물로 나눕니다. WBS가 없으면 프로젝트가 예정된 완료일을 넘기고 프로젝트 관리자가 중요한 활동을 놓칠 수 있습니다.

전체 크기 도표 열기 ↗

대부분의 프로젝트 관리자는 실행 항목 목록을 만듭니다. 목록이 길면 다루기 어렵고 산출물이 빠질 수 있으며 대규모 프로젝트를 관리하기 쉬운 단위로 나누기도 어렵습니다. 읽는 사람이 프로젝트를 이해하거나 목록을 작성한 사람이 누구인지 파악하는 데 어려움을 겪을 수 있습니다.

WBS에는 모든 실행 항목이 반영됩니다. 계층 구조로 작업을 작업 패키지로 나누는 방식과 산출물 사이의 관계를 보여 줍니다. 이해관계자와 팀의 의견을 반영하면 지지를 확보하고 성과를 높이는 데 도움이 됩니다. WBS를 작성하면서 팀은 프로젝트의 전 과정을 머릿속으로 검토하고 계획을 개선할 수 있습니다. 덕분에 실행은 쉬워지고 위험은 줄며, 참여를 장려하고 프로젝트가 실현 가능하다는 인식을 높일 수 있습니다.

WBS는 조직도처럼 보일 수 있습니다. 목적은 프로젝트와 산출물에 필요한 작업을 계획하고 조직하고 관리하고 통제할 수 있는 단위로 나누는 것입니다. 최상위부터 시작해 산출물과 작업을 작업 패키지라는 더 작은 단위로 분해합니다.

WBS 작성 규칙

1. 팀을 참여시킵니다.
2. 작업을 더 세분화하기 전에 첫 번째 수준을 완성합니다.
3. 각 수준은 바로 위 수준을 세분화한 것이어야 합니다.
4. WBS의 모든 수준을 종합해 전체 프로젝트를 이해할 수 있게 합니다.
5. 이 프로젝트의 산출물만 포함합니다.

작업 패키지와 통제 계정

산출물이 다음 조건을 충족하면 작업 패키지로 볼 수 있습니다.

1. 현실적이고 신뢰할 수 있게 산정할 수 있습니다.
2. 빠르게 완료할 수 있습니다.
3. 중단하거나 추가 정보를 기다리지 않고 완료할 수 있습니다.
4. 적절한 경우 외주를 주거나 계약을 통해 맡길 수 있습니다.

WBS를 완성한 뒤 각 작업 패키지에 식별자가 부여되도록 수준별로 번호를 매깁니다. 일부 프로젝트에서는 작업 패키지 수준 대신 통제 계정이라는 더 높은 WBS 수준에서 원가를 관리합니다.

계획 단계에서 팀은 범위 기술서, WBS, WBS 사전을 사용해 작업 패키지를 산출물을 만드는 데 필요한 활동으로 나눕니다. 이 활동 목록은 시간 관리의 활동 정의 과정에서 만듭니다.

WBS는 이후 프로젝트 계획의 토대입니다. 계층을 시각화해 모든 산출물을 식별합니다. 프로젝트에 속하는 활동은 반드시 WBS에 포함된 작업과 관련되어야 합니다. WBS는 팀이 프로젝트의 모든 부분을 검토하도록 돕고 다른 프로젝트에 재사용할 수도 있습니다. 계층은 WBS로, 활동의 의존 관계는 일정 네트워크 다이어그램으로 보여 줍니다.

프로젝트 관리자는 WBS를 사용해 프로젝트를 분해합니다. 이 문맥에서 해체(deconstruction) 및 분해(decomposition) 는 같은 과정을 뜻합니다.

전체 크기 도표 열기 ↗

WBS 사전

WBS 사전은 각 작업 패키지의 작업을 설명합니다. WBS 작성의 산출물입니다. 범위가 통제 없이 늘어나는 것을 막고 모든 사람이 산출물에 대해 명확한 설명을 얻도록 돕습니다. 다음과 같이 활용할 수 있습니다.

• 작업 패키지의 시작 시점을 표시해 작업 승인 시스템 역할을 합니다.
• 일정 마일스톤, 인수 기준, 그 밖의 작업 패키지 세부 사항을 기록합니다.
• 어떤 작업을 수행하는지 통제하는 데 도움이 됩니다.
• 이해관계자가 작업 패키지에 필요한 노력을 파악하도록 돕습니다.

전체 크기 도표 열기 ↗

범위 기준선

기준선은 프로젝트 관리 계획서 일부의 최종 승인본입니다. 범위 기준선은 범위 기술서, WBS, WBS 사전으로 구성됩니다. 작업을 시작하기 전에 경영진과 이해관계자가 세 가지를 모두 승인해야 합니다. 실제 진행 상황을 범위 기준선과 비교합니다.

범위 기준선에서 벗어나는 사항이 있으면 변경을 요청합니다. 통합 변경 통제 수행을 통해 요청을 처리합니다. 승인되면 범위 기술서, WBS, WBS 사전과 영향을 받은 다른 문서나 구성 요소를 갱신합니다. 요구 사항 및 범위 기준선 충족 여부로 프로젝트 성공을 측정합니다.

범위 검증

범위 검증은 프로젝트가 승인된 범위에 맞게 진행되도록 합니다. 고객이나 스폰서와 정기적으로 대화하고 완료된 산출물의 인수를 요청합니다.

범위 검증의 입력물

• 품질 통제 수행에서 확인된 산출물.
• 범위 기술서, WBS, WBS 사전.
• 요구 사항 추적 매트릭스.
• 요구 사항 문서.

범위 검증의 산출물

• 인수한 산출물.
• 변경 요청.
• 프로젝트 문서 갱신.

범위 검증은 각 단계가 끝날 때나 프로젝트 전반에 걸쳐 감시 및 통제의 일부로 수행할 수 있습니다. 고객이 중간 산출물을 공식 인수하는 과정입니다. 프로젝트 또는 단계 종료에서는 전체 프로젝트나 단계에 대한 최종 인수 또는 서면 승인을 받습니다.

범위 통제

범위 통제의 주요 책임은 두 가지입니다. 프로젝트 범위 또는 제품 범위, 혹은 둘 다의 성과를 측정하고 범위 기준선의 변경을 관리합니다. 작업이 계획대로 진행되는지 범위를 자주 점검합니다.

필수 입력물 두 가지는 프로젝트 관리 계획서의 범위 기준선과 지금까지 완료된 작업입니다. 요구 사항 문서와 요구 사항 추적 매트릭스도 도움이 될 수 있습니다. 기준선에서 벗어난 사항을 파악하고 시정 조치나 예방 조치를 권고합니다. 변경이 필요하면 변경을 요청하고 통합 변경 통제를 수행한 뒤 필요한 문서를 갱신합니다.

프로젝트 관리자는 프로젝트 관리 계획서의 기준선에 비추어 프로젝트를 선제적으로 통제합니다. 범위를 변경할 때는 항상 변경 관리 프로세스를 따릅니다.