스코프 크립이란 무엇입니까? 예 및 예방 방법

게시 됨: 2022-07-15

범위 크리프는 거의 모든 서비스 제공업체나 프리랜서가 프로젝트를 처리하는 동안 직면한 만연한 문제입니다. 특히 소프트웨어 및 웹 사이트 개발 영역에서 범위 크리프는 시간, 생산성 및 이익 마진에 심각한 결과를 초래할 수 있습니다.

프로젝트 관리자는 착수하려는 프로젝트의 범위를 완전히 이해할 때까지 범위 확대를 억제하거나 관리할 수 없습니다.

이 기사에서는 범위 크리프가 의미하는 것과 일반적인 원인을 살펴보겠습니다. 또한 웹 사이트 프로젝트 관리에서 범위 크리프의 예와 이를 방지하는 실용적인 방법을 볼 수 있습니다.

프로젝트의 범위는 무엇입니까?

이름에서 알 수 있듯이 프로젝트 범위(또는 작업 범위)는 프로젝트를 시작하고 완료하는 데 필요한 작업 계획, 단계, 프로세스, 주요 결과물 및 요구 사항을 나타냅니다. 프로젝트에 대한 작업 분석 구조(WBS)가 있으면 프로젝트 범위를 구성하는 모든 사양, 이정표, 활동, 비용, 예산, 경계 및 프로젝트 일정을 쉽게 식별할 수 있습니다.

이 모든 것은 시작하기 전에 귀하와 귀하의 클라이언트가 프로젝트의 범위를 정의하는 데 도움이 됩니다. 프로젝트 작업이 진행됨에 따라 쉽게 상기시키는 역할을 하는 프로젝트 설명으로 이것을 줄이는 것이 가장 좋습니다.
클라이언트 인터뷰에서 프로젝트 범위를 정의하지 못하면 범위가 확대될 뿐만 아니라 클라이언트가 구상한 것과 완전히 다른 최종 제품이 나올 수 있습니다.

스코프 크립이란 무엇입니까?

기능 크리프라고도 하는 범위 크리프는 프로젝트의 원래 범위에서 추가 또는 이탈 요청입니다. 이것은 범위의 변경이 환영받지 못한다는 말은 아닙니다. 그러나 이러한 변경 요청이 프로젝트 일정, 리소스, 예산, 생산성, 시간 및 비용에 영향을 미치므로 프로젝트 범위에 맞게 변경 요청을 억제해야 합니다.

프로젝트가 시작된 후 클라이언트 또는 이해 관계자가 새로운 프로젝트 기능이나 요구 사항을 추가할 때 범위 크리프는 특히 견딜 수 없게 됩니다. 이는 팀이 원래 일정, 예산 및 리소스 내에서 프로젝트를 완료해야 하는 경우에 해로울 수 있습니다.

크립이라는 단어의 의미와 마찬가지로 일반적으로 프로젝트의 목적에 점차적으로 영향을 미치고 문제를 일으키는 사소한 요청으로 시작합니다. 프로젝트 범위에 대한 통제되지 않은 변경으로 인해 예산을 쉽게 초과할 수 있습니다. 이것은 당신의 이익 마진에 영향을 미치고 마감일을 놓치게 하고 고객이 정말로 원하는 것에서 벗어나게 할 것입니다. 이 모든 것이 당신의 평판에 치명적일 수 있습니다.

프로젝트의 범위를 정확하게 정의하지 않으면 프로젝트가 원래 기대치를 넘어 성장하기 쉽습니다.

스코프 크리프의 일반적인 원인

범위 크리프는 여러 가지 이유로 발생하며 클라이언트 또는 프로젝트 팀의 잘못으로 발생할 수 있습니다. 범위 크리프는 웹 디자이너, 개발자 및 기업가에게 영향을 줄 수 있습니다. 다음은 스코프 크립의 일반적인 원인 중 일부입니다.

모호하거나 정의되지 않은 프로젝트 범위

프로젝트 범위에 대한 정의가 명확하지 않은 것은 범위 확대를 조장하는 가장 쉬운 방법입니다. 프로젝트 관리자는 프로젝트를 완료하는 데 필요한 프로세스와 요구 사항을 이해해야 합니다. 그렇지 않으면 최종 제품이 고객의 의도에서 벗어나게 됩니다.

때때로 클라이언트는 원하는 것이 무엇인지에 대한 명확한 아이디어가 없기 때문에 프로젝트 범위의 모호성에 대해 책임을 져야 합니다. 이러한 클라이언트를 명확한 비전으로 안내하려면 적절한 프로젝트 관리 커뮤니케이션이 필요합니다. 프로젝트가 진행되면서 클라이언트가 "이해하기를 원하는" 것은 미래에 범위가 확장될 수 있다는 분명한 신호입니다.

프로젝트 관리 관행 회피

프로젝트 범위와 관리 관행을 갖는 것과 그 관행을 고수하는 것은 별개의 문제입니다. 사소한 변경 요청에 대한 프로젝트 관리 관행을 피하면 범위가 확대됩니다.

예를 들어, 클라이언트가 웹 페이지의 테마 색상을 약간 변경하도록 요청합니다. 이러한 변경 사항을 적용하는 데 한 시간도 걸리지 않으므로 정해진 관행 밖에서 구현하려는 유혹을 받을 수 있습니다. 그러나 이것이 스코프 크립이 미끄러지는 방식이며 시간이 지남에 따라 누적될 수 있습니다.

프로젝트 관리 관행을 따르면 승인된 기능 요청도 프로젝트가 원래 목표에서 벗어나는 것을 방지하면서 순조롭게 진행하는 데 도움이 됩니다.

문서화되지 않았거나 모호한 계약

고객과의 모든 서신 및 계약을 서면으로 줄이는 것은 범위 확대를 제한하는 좋은 방법입니다. 고객과의 커뮤니케이션을 문서화하는 쉬운 방법은 중요한 커뮤니케이션이 전화가 아닌 이메일을 통해 이루어지도록 하는 것입니다. 또는 물리적 회의를 통해 도달한 합의를 요청하고 이메일을 통해 통화를 재확인합니다.

또한 프로젝트의 상호 동의 조건, 의무 및 의무가 포함된 유연한 계약을 갖는 것은 명확성을 보장하고 클라이언트의 불필요한 기능 요청을 억제하는 좋은 방법입니다. 그러나 모든 문서가 모호하지 않고 명확하여 당사자 중 누구도 잘못된 인상을 받지 않도록 하십시오.

기능 요청의 규제되지 않은 프로세스

프로젝트 중 변경은 일반적으로 피할 수 없습니다. 전문 프로젝트 관리자로서 개선의 여지를 만드는 것이 실용적입니다. 모든 기능 요청은 비용, 리소스 및 시간이 고려되도록 하는 프로세스와 일치해야 합니다.

클라이언트 요청 외에도 때로는 프로젝트 팀이 클라이언트에게 깊은 인상을 주기 위해 추가 기능을 추가하는 데 집중할 수 있습니다. 이것은 역효과를 일으키지 않고 비용과 시간을 낭비하지 않도록 적절한 채널을 따라야 합니다.

추가 프로세스를 유연하게 만들어 창의성을 억제하지 않지만 범위 확대를 억제해야 합니다. 요청을 통합하기 위한 적절한 구조는 원치 않는 지연과 불만족스러운 클라이언트를 제거합니다.

만장일치 목표가 없는 여러 프로젝트 이해 관계자

범위 크리프의 이러한 원인은 일반적으로 클라이언트에 프로젝트의 다양한 측면을 감독하는 여러 사람이 있을 때 발생합니다. 일반적으로 각 사람은 프로젝트를 수행하는 방법에 대해 서로 다른 아이디어나 관점을 가지고 있습니다.

이것은 제대로 관리되지 않으면 '주방에 너무 많은 요리사가 있는' 전형적인 사례입니다. 클라이언트에 프로젝트에 대한 의사 결정 권한이 있는 여러 사람이 있는 경우 범위 크리프 문제를 피하기 위해 비전이 동일해야 합니다.

프로젝트 관리자는 이해 관계자 중 한 사람의 변경 요청을 시작하기 전에 이러한 불일치를 인식하고 이해 관계자 간의 시너지를 보장해야 합니다.

다른 원인은 다음과 같습니다.

  • 프로젝트 설명 부족
  • 클라이언트 인터뷰는 비공식적이고 모호합니다.
  • 비현실적인 예산과 기간
  • 고객사 경영 변화
  • 모호하거나 모호한 고객 비전
  • 비효율적인 프로젝트 관리
  • 클라이언트와의 커뮤니케이션 격차

스코프 크리프의 예

범위 크리프는 일반적으로 승인되지 않은 변경 요청으로 발생하지만 항상 그런 것은 아닙니다. 승인된 요청은 초기에 범위 이동으로 인식되지 않는 경우 동일한 문제를 일으킬 수 있습니다.
다음은 실제 시나리오에서 식별하는 데 도움이 되는 범위 크리프의 세 가지 예입니다.

예 1: 중단된 콘텐츠

전자 상거래 회사가 WordPress 웹 사이트를 만들기 위해 웹 사이트 개발 회사에 접근한다고 가정합니다. 당신은 클라이언트 인터뷰를 했고 프로젝트 범위는 양 당사자에 의해 승인되었습니다. 필요한 경우 사소한 변경 요청에 대한 절차도 제공했습니다.

그러나 웹 프로젝트의 요구 사항에서 클라이언트는 전자 상거래 웹 사이트에 대한 콘텐츠 제공을 주장하고 웹 사이트 콘텐츠 제공에 대한 귀하의 추가 서비스 사용을 거부했습니다. 웹사이트는 2개월 후에 런칭될 예정입니다. 클라이언트의 콘텐츠 전달은 출시 3주 전에 예정되어 있습니다.

클라이언트가 예약된 날짜에 웹 콘텐츠를 전달하지 못합니다. 예정된 출시 5일 전까지 클라이언트로부터 연락이 없었습니다. 클라이언트는 마침내 손을 뻗어 웹 콘텐츠 개발 및 검토 요청을 진행합니다. 예상되는 비용 영향은 있지만 예정된 출시 날짜의 연장은 없습니다.

이것은 스코프 크립이며 승인된 경우 승인되지 않은 것과 유사한 결과를 초래할 수 있습니다. 프로젝트 시간 제공에 대한 중요한 고려 사항이 없는 한 생산성, 인적 자원 및 가능한 출시 지연에 부담을 줄 것입니다.

예 2: 덴버 국제공항

이제 스코프 크리프의 실제 예인 덴버 국제공항(DIA) 사가. 스코프 크립이 얼마나 위험한지를 보여주기 때문에 꽤 유명합니다. 완전 자동화된 수하물 처리 시스템을 만들기 위한 공항 프로젝트는 2,000개 이상의 설계 변경이 있었습니다. 이 프로젝트는 예정보다 16개월 늦게 완료되고 예산보다 250%나 초과되었지만 결국 실패했습니다.

설계 단계에서 범위 크리프의 주요 원인은 항공사와 같은 계획 단계에서 모든 관련 이해 관계자를 참여시키지 않았기 때문입니다. 중요한 프로젝트 문제가 무시되어 수하물 처리 시스템도 실패했습니다.

이를 통해 클라이언트와 프로젝트 팀 모두의 실수를 관찰할 수 있습니다. 프로젝트 관리자는 프로젝트 범위를 생성할 때 작업분류체계(WBS) 생성에 우선순위를 두어야 합니다. 이 예에서 볼 수 있듯이 계속 진행하기 전에 클라이언트와 모든 이해 관계자가 같은 페이지에 있어야 합니다.

예 3: 디자인 수정

웹사이트 디자인이 필요하지만 최종 제품이 어떻게 생겼는지 전혀 모르는 고객을 생각해 보십시오. 클라이언트는 계획 프로세스에 결정적인 기여를 하지 않으면서 "내가 좋아하는 것을 보면 알게 될 것"이라고 말합니다.

디자인 단계에서 현재 디자인을 클라이언트에 제출하고 원하는 것을 캡처할 수 있는 것 같지 않아 만족하지 않습니다. 클라이언트는 디자인에 대한 수정을 계속 요구하여 전체 프로젝트를 좌절시킵니다. 예정된 출시까지 며칠 동안 디자인이 승인되었으며 출시 시간에 맞춰 웹사이트를 제공할 것으로 예상됩니다.

이 예에서 클라이언트의 모호한 지시는 끝없는 수정의 형태로 오는 범위 이동으로 이어질 수밖에 없다는 것이 분명합니다. 이로 인해 지연 가능성이 있어 생산성과 리소스가 저하됩니다.

스코프 크리프를 피하는 방법

범위 이동은 예산을 초과하고 지연되는 프로젝트의 주요 원인입니다. 특히 소프트웨어, 웹 사이트 디자인 및 개발 세계에서. 최소한의 무단 변경을 억제함으로써 프로젝트는 생산성, 이윤 및 시간 관리에서 상당한 개선을 목격하게 될 것입니다. 이렇게 하면 클라이언트의 필수 변경 요청에 참석할 수 있는 충분한 시간이 생깁니다.

다음은 범위 크리프가 프로젝트를 망치지 않도록 하는 5가지 가장 좋은 방법입니다.

1. 프로젝트 요구 사항 기록 유지

직관적인 것처럼 보이지만 클라이언트의 프로젝트 요구 사항을 문서화하는 것이 항상 완료되는 것은 아닙니다. 프로젝트 요구 사항을 기록하면 프로젝트 범위를 명확하게 정의할 수 있습니다.

고객 상담부터 시작하여 고객이 필요로 하는 것이 무엇인지 파악하십시오. 고객 회의에서 프로젝트 요구 사항을 문서화한 후에는 관련된 모든 당사자와 공유하십시오. 문서에는 프로젝트 진행 상황을 추적하는 데 필요한 모든 정보도 포함되어야 합니다.

모든 요구 사항이 가능하지 않을 수 있으므로 요구 사항의 중요도에 따라 요구 사항의 우선 순위를 지정해야 합니다. 이렇게 하면 팀이 중요하지 않거나 불가능한 작업에 집중하는 데 시간을 낭비하지 않도록 하여 팀을 계속 점검할 수 있습니다.

2. 변경 요청 절차 설정

프로젝트 범위가 얼마나 잘 준비되었는지에 관계없이 프로젝트가 진행됨에 따라 변경 사항이 있을 것으로 예상하는 것이 실용적입니다. 이것이 고객과의 계약에 변경 요청 절차를 제공하는 조항을 포함해야 하는 이유입니다.

이 변경 요청 절차는 예상치 못한 범위 이동 가능성을 관리하는 데 도움이 됩니다. 그러나 이것이 작동하려면 절차를 엄격하게 준수해야 합니다. 그렇지 않으면 이 프로세스가 쓸모 없게 됩니다. 또한 변경 요청에 대한 적절한 비용 및 시간 영향을 포함하여 클라이언트의 경솔한 요청을 억제하고 이윤을 유지하십시오.

요청이 이루어지면 이 절차를 설정하는 것은 매우 쉽습니다. 기본 절차 단계는 검토 , 승인 또는 거부 및 통합 입니다. 상황이 요구할 때 변경 요청을 거부하는 것을 두려워하지 마십시오. 다만, 특정 요청이 거절될 수 있는 이유를 명확히 설명하고 대안을 제시합니다.

3. 프로젝트 범위 프로세스에 이해관계자 참여

프로젝트의 범위를 만들 때 모든 이해 관계자와의 원활한 의사 소통이 필요합니다. 프로젝트 관리자로서 이해 관계자의 모든 요구 사항을 수집하고 이해했는지 확인하는 것이 중요합니다. 요구 사항 문서를 이해 관계자와 공유하면 나중에 발생할 수 있는 혼동을 제거할 수 있습니다. 따라서 가능한 한 프로젝트 범위를 검토하는 데 충분한 시간을 할애하십시오.

또한 다양한 이해 관계자가 프로젝트 범위 완료 후 기능 변경을 요청하는 절차와 의미를 이해하도록 합니다. 이해 관계자가 참여하지 않으면 이해 관계자가 프로젝트 개발 중에 주요 요청을 가져올 수 있으므로 프로젝트가 손상될 수 있습니다. 이해 관계자가 일반적으로 프로젝트 범위에 크게 기여할 수 없는 경우 프로젝트를 진행하면서 정기적으로 알림을 받는 것이 좋습니다.

4. 프로젝트 팀원을 함께 이동

이해 관계자를 루프에 유지하는 것이 중요한 만큼 팀 구성원도 루프에 유지되도록 하는 것도 똑같이 중요합니다. 팀 구성원은 변경 요청 절차와 이것이 자신에게 미치는 영향을 알고 있어야 합니다.

과도하게 전달하고 고객에게 깊은 인상을 주기 위해 팀 구성원이 범위를 확대하는 경향이 있습니다. 팀 구성원이 프로젝트 범위와 설명을 알고 있는지 확인하여 무리한 작업을 방지할 수 있습니다. 이렇게 하면 승인되지 않은 변경을 통해 합의된 프로젝트 설명에서 벗어나지 않습니다.

5. 적극적으로 행동하라

범위 크리프를 피하는 가장 좋은 방법 중 하나는 프로젝트에서 발생할 수 있는 영역을 예상하는 것입니다. 그런 다음 해당 범위 증가를 억제하는 방법을 배치합니다. 능동적으로 행동하면 가능한 변경 사항에 미리 대처할 수 있으며 고객의 막판 변경 사항에 당황하지 않습니다.

때로는 변경 요청이 합리적이고 예측 가능합니다. 사전 예방적 프로젝트 관리자로서 고객 및 이해 관계자의 확인을 위해 초기에 이러한 변경 사항을 제안할 수 있습니다. 클라이언트가 매우 불편할 수 있는 프로젝트의 훨씬 나중에 이러한 변경을 요청할 때까지 기다리지 마십시오.

예 1에서와 같이 클라이언트가 웹사이트 콘텐츠 제공을 지연할 것이 분명한 웹 개발자로서 사전 예방적으로 콘텐츠를 작성하고 확인을 위해 클라이언트에게 보내도록 할 수 있습니다. 프로젝트 일정을 연장하거나 나중에 비용이 훨씬 많이 드는 막바지 요청을 피하기 위해.

마무리

범위 크리프는 대부분의 프로젝트가 실패하거나 지연 및 비용 상승을 경험하는 주요 원인입니다. 프로젝트 관리자는 범위 이동의 영향을 이해하고 발생하기 전에 이를 식별하고 예방할 수 있다는 점을 이해하는 것이 중요합니다. 프로젝트 중 변경 사항이 본질적으로 나쁜 것은 아닙니다. 그러나 프로젝트가 목표에서 탈선하거나 지연되지 않도록 면밀히 조사하고 관리해야 합니다.

이 문서에서 공유된 범위 크리프의 원인과 예를 염두에 두십시오. 패턴이 나타날 때마다 패턴을 인식하는 데 도움이 됩니다. 그런 다음 다음 프로젝트에서 스코프 크립을 방지하는 5가지 가장 좋은 방법 중 하나를 적용할 수 있습니다.

보너스 콘텐츠 받기: 클라이언트로부터 웹사이트 콘텐츠를 얻는 방법
여기를 클릭하십시오