범위 크리프 관리 방법: 프로젝트 관리자를 위한 팁

주요 시사점

• 범위 크리프는 시간, 예산 또는 리소스의 조정 없이 프로젝트의 범위가 확장되게 하는 승인되지 않은 작업입니다.

• 보통은 작고 합리적인 요청으로 시작되지만 일정 지연 및 비용 초과로 이어집니다.

• 해결책은 단순히 거절하는 것이 아니라 명확한 범위 기준선과 변경 제어를 도입하여 상충 관계를 가시화하는 것입니다.

• 등록부의 변경 사항을 추적하고 범위를 매주 검토하여 범위 크리프를 조기에 파악합니다.

프로젝트 계획은 계속 확장되는데 마감 날짜는 그대로라면, 유연하게 대처하고 있는 것이 아니라 범위 크리프가 실시간으로 일어나는 것을 관찰하고 있는 것입니다.

범위 크리프는 프로젝트의 요구 사항이 시간, 예산 또는 리소스의 적절한 조정 없이 기존 합의 범위를 벗어나 확장되는 현상입니다. 

이것이 왜 중요합니까?

범위는 세 가지 제약 조건 중 다른 두 가지 조건인 시간 및 비용과 연관되어 있습니다. 하나를 변경하면 거의 틀림없이 나머지에도 영향을 미치게 됩니다.

범위 크리프를 해결하지 않으면 프로젝트 실패 및 비용 초과가 발생할 위험이 높아집니다. 이는 업계에 관계없이 언제든지 모든 프로젝트에 영향을 미칠 수 있습니다. 

이 가이드를 따라 범위 크리프를 조기에 발견하고 혼란 없이 변경 사항을 제어하며 새로운 요청이 있을 때마다 상충 관계에 대해 이해 관계자 정렬을 이루는 방법을 알아보세요.

범위 크리프란 무엇입니까?

범위 크리프는 프로젝트의 목표, 작업 또는 산출물이 원래 계획을 넘어 통제되지 않은 상태로 확장되는 것입니다. 일반적으로 적절한 검토 또는 승인 절차 없이 프로젝트에 새로운 요구 사항을 추가할 때 발생합니다.

이로 인해 프로젝트 지연, 비용 증가 및 리소스 부족이 빈번하게 발생합니다. 하지만 효과적인 범위 관리는 위험 및 지연 시간을 크게 줄여 프로젝트가 예정대로 진행되도록 합니다.

프로젝트 관리에서 범위 크리프는 어떻게 나타납니까?

프로젝트 관리에서 범위 크리프는 일반적으로 3개 부분의 확장으로 나타납니다.

1. 기능, 산출물 및 작은 요청 또는 요구 사항이 늘어날 경우 범위가 확장됩니다. 

2. 작업이 늘어나 프로젝트 완료까지 추가 시간이 필요할 경우 일정이 연장됩니다.

3. 더 많은 시간, 리소스 또는 공급업체가 필요할 경우 예산이 증가하며 이는 비용 상승으로 이어집니다.

프로젝트 범위가 통제되지 않은 변경 사항 또는 요구 사항 관리 문제로 인해 초기 합의를 넘어 확장되는 경우 범위 크리프가 발생합니다.

1. 발견 후: 이해 관계자가 초기 초안을 확인한 후에 '작은' 개선을 원하는 경우입니다.

2. 빌드 또는 실행 중: 제약 조건이 나타나고 해결 방법으로 인해 추가 작업이 발생하는 경우입니다.

3. 마무리 단계: 예외 사례 또는 최종 수정이 갑자기 필수 요소가 되는 경우입니다.

범위 크리프가 처음부터 과도한 요구로 나타나는 경우는 거의 없다는 점을 알아두어야 합니다. 일반적으로 범위 크리프는 합리적으로 들리는 일련의 추가 사항에서 시작됩니다.

범위 크리프의 원인은 무엇입니까?

불분명한 범위 정의는 범위 크리프의 가장 일반적인 문제 중 하나입니다. 프로젝트 경계가 모호하거나 세부 사항이 부족하면 잘못된 해석과 통제되지 않는 변경이 발생합니다.

요구 사항이 모호하거나 미흡하게 정의되어 있을 때 범위 크리프를 초래하는 가장 큰 원인은 다음과 같습니다. 

이해 관계자와의 원활하지 않은 커뮤니케이션

팀이 동일한 완료의 정의를 공유하지 않으면 요구 사항을 다르게 해석하고 재작업이 어느새 새로운 작업으로 둔갑합니다. 커뮤니케이션 문제는 일반적으로 대화를 원활하게 진행하거나 쉽게 찾게 도와주는 도구가 부족할 때 발생합니다.

이메일 커뮤니케이션은 메시지가 누락되거나 끝없는 컨텍스트 전환으로 인해 요구 사항을 완전히 파악하지 못하는 경우 범위 크리프의 주요 원인이 될 수 있습니다.

간단한 솔루션은 참조 자료를 도입하여 모든 프로젝트 설명서의 중앙 정보 출처로 사용하는 것입니다. 이러한 도구를 사용해 커뮤니케이션을 중앙 집중식으로 관리합니다.

또한 Loom을 통해 화면 녹화 동영상을 제공하여 이해 관계자가 최신 정보를 파악할 수 있도록 지원할 수 있습니다. AI 대화 내용 기록 기능을 사용하면 프로젝트 범위 또는 요구 사항 문서에 자동으로 삽입하는 것이 쉬워집니다.  

불분명한 프로젝트 목표

프로젝트 목표가 불분명하거나 너무 단순하면 명확한 성공 메트릭을 기준으로 새로운 요청을 평가하기 어려워집니다. 정의된 프로젝트 목표가 없다면 실제로 전체 목표에 도움이 되는 요청을 판단하기 어렵습니다.

팀은 제공해야 하는 것을 자주 오해하곤 합니다. 업무를 시작하기 전에 이해 관계자와 내용을 명확하게 확인하고 정렬을 이루어 이 문제를 해결할 수 있습니다.

하지만 정확한 프로젝트 목표 없이 이러한 대화를 시작하려고 하면 오해 및 범위 크리프의 여지가 생깁니다.

너무 많은 이해 관계자

프로젝트에 너무 많은 이해 관계자가 참여하면 각자가 저마다의 아이디어, 우선 순위 및 기대치를 내세웁니다. 

여기서는 '나쁜 아이디어란 없다'는 말이 그리 도움이 되지 않습니다. 여러 이해 관계자(및 의견)가 있으면 대개 빈번한 변경, 새로운 요청 또는 수정이 발생하고 이는 프로젝트 범위에 영향을 줍니다.

피드백 및 승인을 관리하는 명확한 프로세스가 없으면 상충하는 의견들로 인해 프로젝트 팀은 금세 감당하기 힘든 상태가 될 수 있습니다. 결과적으로 프로젝트가 원래 목표를 넘어 확장되어 일정 및 예산을 준수하기가 어려워질 수 있습니다.

이해 관계자 과잉으로 인한 대가를 치르지 않으려면 초기에 명확한 역할 및 의사 결정 권한을 수립해야 합니다. 프로젝트 범위를 보완하기 위한 역할 및 책임 템플릿을 사용해 보세요.

비효율적인 변경 제어 프로세스

초기에 좋은 계획을 세웠더라도 변경 사항이 비공식적인 방식(Slack, 복도에서의 요청, "이것만 처리해 줄 수 있나요?"와 같은 요청)으로 도입된다면 범위 크리프가 발생합니다.

공식적인 변경 제어 프로세스 및 효과적인 요구 사항 관리를 구현하는 것은 범위 크리프를 관리하고 프로젝트 범위에 대한 무단 수정을 방지하는 데 필수적입니다.

범위 크리프를 식별하고 방지하기 위한 6가지 모범 사례

프로젝트 초기에 명확한 프로젝트 범위를 수립하는 것은 범위 크리프를 방지하기 위해 필수적입니다. 하지만 새로운 요청이 나타날 때 가장 큰 영향을 미치는 위험을 어떻게 빠르게 식별할 수 있을까요?

다음은 너무 늦기 전에 범위 크리프를 식별하고 방지하는 데 도움이 되는 몇 가지 방법입니다.

1. 스탠드업 미팅 도입

스탠드업 미팅은 소프트웨어 개발 분야에서 일반적으로 볼 수 있지만, 이제는 다른 유형의 팀도 매일 또는 주간 스탠드업 미팅의 이점을 빠르게 체감하고 있습니다. 더 큰 규모의 교차 부서 프로젝트의 경우 Atlassian 개발자이자 팀 리드인 Bruce Templeton은 스크럼의 스크럼 미팅을 사용합니다.

이러한 여러 팀 간의 스탠드업 미팅은 범위 변경을 더 빠르게 식별하는 데 도움이 됩니다. 스크럼의 스크럼은 지식 공유의 기회를 제공하고 범위 크리프로 발전할 수 있는 중요한 문제를 조기에 드러내 줍니다.

이러한 모임에서 핵심 항목을 문서화하는 데 도움이 필요하다면, 무료 매일 스탠드업 미팅 템플릿을 사용하여 팀 전반의 모든 진행 상태를 추적해 보세요.

2. 간결한 범위 명세서 작성

요구 사항 또는 다음 단계에 대해 다르게 해석할 여지가 없게 하세요. 범위 명세서는 이해 관계자가 실제로 읽고 핵심 정보를 파악할 수 있을 정도로 간결하게 작성합니다.

공식적인 범위 명세서 또는 작업 범위(SOW)는 모든 산출물, 프로젝트 마일스톤 및 경계를 요약하고 오해 및 범위 크리프를 방지하기 위해 범위에 포함되지 않는 사항을 명시적으로 문서화해야 합니다.

가장 좋은 방어책은 팀원들이 실제로 참조할 수 있는 범위 기준선을 마련하는 것입니다.

3. 산출물 및 제외 사항을 목록으로 명확하게 작성

상세한 프로젝트 범위가 없다면 프로젝트 산출물에 포함되는 항목과 포함되지 않는 항목에 대해 명확하게 정의하여 미리 승인한 통제 기준을 마련하지 못합니다. 이러한 '포함/제외' 항목의 명확성이 중요한 이유는 범위 크리프가 종종 명시되지 않은 가정을 통해 발생하기 때문입니다.

프로젝트 범위에 다음이 포함되어 있는지 확인하세요.

• 산출물:프로젝트 산출물 및 요구 사항(예: 온보딩 흐름 화면, 체크리스트, 이메일 시퀀스, 업데이트된 도움말 문서 및 분석 이벤트)을 나열하면 모두가 포함되는 항목과 제외되는 항목을 이해하는 데 도움이 됩니다.

• 제외 사항: 선제적으로 가격 변경, 청구 마이그레이션, 신규 통합 또는 계정 설정 재설계를 포함합니다.

4. SMART 프로젝트 목표 설정

성공 기준은 산출물의 완료를 나타내고 프로젝트 성공을 보장할 수 있도록 명확하고 측정 가능한 SMART 목표로 정의해야 합니다. 참고로 SMART 목표는 다음을 의미합니다.

• 구체성(Specific): 무엇이 변경되는가

• 측정 가능성(Measurable): 성공 여부를 어떻게 알 수 있는가

• 달성 가능성(Achievable): 제약 조건 내에서 실행 가능한가

• 관련성(Relevant): 비즈니스 성과와 연결되는가

• 시간 제한(Time-bound): 언제까지 완료해야 하는가

목표를 상세히 설정하는 데 도움이 필요하다면, SMART 목표 템플릿을 사용하여 프로젝트 공동 작업 및 프로젝트 성공을 달성하는 방법을 확고히 하는 체계적인 프레임워크를 제공하세요.

5. 조기에 이해 관계자 승인 확보

프로젝트 후원자 및 주요 이해 관계자에게서 승인을 받으면 처음부터 정렬을 이루게 됩니다. 승인된 범위 기준선은 변경을 막는 것이 아니라 변경을 명확하게 드러내 줍니다.

기준선 범위를 작업 자체에 연결하세요. 애자일 프로젝트 관리 도구를 사용하면 프로젝트 브리프를 에픽에 연결한 다음, 수용 기준에 연결할 수 있습니다.

에픽 인사이트 보기는 승인이 이메일에 갇혀 지체되는 것을 방지하는 데 도움이 됩니다. 승인은 모든 관계자가 투명하고 명확하게 확인할 수 있어야 하며, 중앙 집중식 대시보드가 있으면 모두의 효율성이 높아집니다.

6. 변경 제어 프로세스 준수

모든 것에 '아니요'라고 말한다고 해서 범위 크리프를 방지할 수 있는 것은 아닙니다. 범위 크리프를 방지하려면 명확한 상충 관계와 함께 변경 사항을 가시화하고 평가하고 승인해야 합니다.

변경 제어 프로세스는 새로운 요청 또는 요구가 발생할 때마다 구체적인 계획을 준수할 수 있도록 도와줍니다. 따라야 할 간단한 변경 제어 프로세스는 다음과 같습니다.

1. 변경 요청을 제출합니다. 변경하려는 사항과 그것이 지금 시점에 중요한 이유를 파악하세요. 그리고 소유자 및 명확한 비즈니스 근거가 있는지 확인하세요.

2. 영향을 평가합니다. 일정에 미치는 영향을 추정하여 조정하거나 지연할 작업을 결정하고 새로운 비용, 인력 배치 또는 기회 비용과 같은 예산 또는 리소스에 미치는 영향도 확인하세요.

3. 상충 관계를 고려하여 결정을 내립니다. 승인, 거부, 연기 또는 범위 교체(예: "Y를 제외해야 X를 추가할 수 있음") 중에서 결정하세요. 어떤 경우에도 상충 관계를 고려하지 않고 '예'라고 답해서는 안 됩니다.

4. 결정을 기록합니다. 승인자, 승인 날짜 및 승인 이유를 기록하세요. 그러면 책임 의식을 조성하고 동일한 논쟁을 나중에 반복하는 것이 방지됩니다.

5. 계획 및 기록 시스템을 업데이트합니다. 승인되면 범위 기준선 및 프로젝트 타임라인을 업데이트합니다. 프로젝트가 현실을 반영하도록 백로그를 만들고 이해 관계자 커뮤니케이션을 추가합니다.

프로젝트가 피할 수 있는 범위 크리프로 인해 지장을 받지 않게 하기

범위 크리프는 아무리 잘 계획한 프로젝트에도 영향을 미치는 실제 도전 과제라는 사실을 잘 알고 있습니다. 승인되지 않은 변경 사항, 지연 및 비용 증가는 위험을 초래하며, 이는 프로젝트 실패로 이어집니다. 

프로젝트 목표를 명확히 정의하고 체계적인 변경 관리 프로세스를 수립하며 이해 관계자와 열린 커뮤니케이션을 유지하여 팀은 범위 크리프의 위험을 최소화합니다. 

Jira와 같은 도구는 팀이 범위 관리를 선제적으로 구현하여 프로젝트를 계획대로 진행하고 의도한 결과를 제공하도록 돕습니다. 지금 Jira를 무료로 사용하여 직접 확인해 보세요.

범위 크리프: 자주 묻는 질문

'추가' 요청이 있다면 어떻게 대응합니까?

추가 요청을 논의하기에 앞서 기준선 범위를 다시 한번 확인할 수 있게 합니다. 그러면 원래 합의한 내용에 맞춰 대화를 진행할 수 있습니다. 다음과 같은 표현을 사용하세요.

• "원래 범위에 따라 제공하기로 합의한 것은 다음과 같습니다."

• "이 새로운 요청으로 인해 변경되는 사항은 다음과 같습니다."

범위가 문서 속에 파묻혀 있게 두지 말고 System of Work에서 범위를 항상 확인할 수 있게 하세요. Jira에서 팀은 중간에 추가되는 작업을 보여주는 번다운 차트와 같은 보고 기능을 활용해 범위 변경을 조기에 파악하는 경우가 많습니다.

변경 사항이 가치가 있는지 어떻게 평가합니까?

모든 요청이 승인을 받기 전에 간단한 영향 확인을 거치게 합니다. 장기 프로젝트는 작은 추가 사항이 빠르게 누적되어 지연 및 예산 초과로 이어지기 때문에 특히 취약합니다.

다음과 같은 질문을 통해 변경 요청을 평가하고 있는지 확인하세요.

• 이로 인해 목표로 하는 결과가 바뀝니까?

• 이로 인해 마감 날짜가 바뀝니까?

• 이로 인해 노력, 비용 또는 위험이 증가합니까?

• 이를 수용하기 위해 무엇을 포기할 수 있습니까?

변경 요청의 수락이 통제 불가능한 범위 크리프로 이어지지 않도록 하려면 어떻게 해야 합니까?

요청을 수락하는 경우 무언가를 빼야 합니다. 포기 없이 수락만 하면 범위 크리프가 새로운 계획이 되고 맙니다. 선택할 수 있는 옵션은 다음과 같습니다.

• 가치가 낮은 작업의 중단 또는 연기

• 동일한 마일스톤 내 다른 부분에서 범위 줄이기

• 이해 관계자의 승인을 받아 마감 날짜 조정

• 리소스 추가(정당한 사유가 있고 계획된 경우에만)

끝없는 논쟁 없이 이해 관계자들을 어떻게 정렬합니까?

즉흥적인 논의를 간결하고 공식적인 검토 프로세스로 대체합니다. 채팅 스레드에서 같은 결정을 반복해서 논의하는 것보다 짧고 체계적인 변경 검토 미팅이 더 효과적입니다.

다음과 같은 쉬운 표현으로 절충안을 커뮤니케이션하세요.

• X를 추가하면 날짜를 조정하거나 Y를 중단해야 합니다.

이해 관계자는 보통 영향이 구체적이고 문서화되어 있을 때 절충안을 받아들입니다. 하지만 단호하게 절충안을 명시하지 않으면 추측을 불러일으키고 마감 날짜에 영향을 미칠 것이 분명한 범위 확장을 초래하게 됩니다.