스코프 크립이란 무엇이며 어떻게 피할 수 있습니까?

프로젝트에서 범위 이동을 피하는 방법을 설명하기 전에 프로젝트 범위와 범위 이동이 무엇인지 이해해야 합니다.

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

간단히 말해서 프로젝트 범위는 프로젝트를 완료하는 데 필요한 모든 작업을 의미합니다. 작업 분석 구조(WBS)를 사용하여 프로젝트의 모든 개별 작업, 활동 및 결과물을 식별할 수 있습니다. 그런 다음 프로젝트의 범위를 정의하는 프로젝트 계획 문서인 범위 설명이 필요합니다.

프로젝트 관리에서 스코프 크리프란?

범위 크립은 변경 요청과 같은 제어 절차 없이 프로젝트 범위가 변경될 때 발생합니다. 이러한 변경 사항은 프로젝트 일정, 예산, 비용, 리소스 할당에도 영향을 미치며 이정표와 목표의 완료를 저해할 수 있습니다. 범위 크리프는 가장 일반적인 프로젝트 관리 위험 중 하나입니다.

일반적으로 범위 크리프는 프로젝트 실행이 시작된 후 프로젝트 클라이언트 또는 기타 이해 관계자가 새 프로젝트 요구 사항을 추가할 때 발생합니다. 종종 이러한 변경 사항은 제대로 검토되지 않습니다. 따라서 프로젝트 팀은 원래 범위와 동일한 리소스와 시간에 더 많은 작업, 결과물 및 이정표를 완료해야 합니다.

반면에 완료되었다고 생각할 때마다 새 제품 기능과 같은 새로운 프로젝트 요구 사항이 받은 편지함에 도착하고 더 많은 변경을 수행합니다.

프로젝트 범위를 제어하고 범위 이동을 방지하려면 범위, 변경 및 위험 관리 계획이 필요합니다.

범위 관리 계획

범위 관리 계획은 프로젝트 범위를 설정하고 제어하는 ​​방법을 설명하는 프로젝트 계획의 구성 요소입니다. 이 문서에는 작업 분석 구조, 범위 설명 및 이해 관계자가 프로젝트의 기준선으로 범위를 승인하는 프로세스가 포함됩니다.

범위 관리 계획은 프로젝트 관리자가 이해 관계자가 프로젝트 범위 기준선과 변경 사항이 전체 프로젝트 관리 계획에 미치는 영향을 이해하도록 돕습니다.

변경 관리 계획

물론 프로젝트에는 항상 변경 사항이 발생하지만 이러한 변경 사항을 제어할 수 있도록 변경 관리 계획을 마련하는 것이 중요합니다. 프로젝트가 프로젝트 계획에 정의된 대로 정확하게 진행되는 경우는 매우 드뭅니다. 대부분의 경우 프로젝트 관리자는 일정, 예산 및 범위를 조정해야 합니다. 그러나 변경 관리 프로세스에 대한 통제가 없으면 프로젝트 관리자가 작업을 파악하고 프로젝트를 효과적으로 관리할 수 있는 기회가 거의 없습니다.

리스크 관리 계획

이해 관계자, 클라이언트 또는 팀 구성원이 범위 및 변경 관리 절차를 따르지 않아 범위 크리프가 발생하는 경우 위험 관리 계획을 참조해야 합니다. 프로젝트의 위험 관리 계획은 위험 관리를 위한 전략, 역할, 책임 및 자금 조달을 설정하는 문서입니다. 간단히 말해서 범위 이동과 같은 위험을 예방하고 완화하는 데 필요한 모든 정보가 포함된 계획입니다.

스코프 크리프 예

3개월 동안 프로젝트 관리자는 새로운 소프트웨어를 제공하는 임무를 받았습니다. 계획 단계에서 몇 주 후에 프로젝트의 후원자는 제품에 새로운 기능을 추가했습니다. 프로젝트 관리자가 프로젝트 범위에 새로운 요구 사항을 포함시킨 후 스폰서는 프로젝트 클라이언트의 요청에 따라 훨씬 더 많은 변경을 수행했습니다.

물론 프로젝트 관리자는 변경 요청이 제출되고 범위에 추가된 추가 작업을 실행하기 위해 더 많은 리소스가 제공된다면 새로운 제품 기능이 문제가 되지 않을 것이라고 응답했습니다. 3개월 기한이 가까워지자 후원자는 화가 나서 프로젝트가 일정보다 늦어지고 고객이 결과물을 기대하고 있다고 불평했습니다. 프로젝트 관리자는 기본 프로젝트 계획이 너무 야심적이어서 추가 작업이 예정대로 진행되지 않는다고 설명했습니다.

다음에 무슨 일이 일어났는지 짐작할 수 있습니까? 네. 프로젝트 관리자는 스폰서에 의해 "너무 느리다"고 비난받아 프로젝트에서 해고되었습니다. 이것은 스코프 크립의 전형적인 예입니다. 변경 요청을 통해 새로운 제품 기능이 추가되었고 추가 작업을 실행할 수 있는 충분한 리소스가 있었지만 시간 제약이 변경되지 않았기 때문에 프로젝트 관리자는 계획된 프로젝트 일정 기준선 내에서 제공하지 못했습니다.

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

스코프 크리퍼가 프로젝트를 방해하지 않도록 하십시오. 다음은 프로젝트 범위를 제어하는 ​​5가지 방법입니다.

1. 프로젝트 요구 사항 문서화

범위 이동을 피하기 위해 가장 중요한 것은 프로젝트 요구 사항을 문서화하는 것입니다. 프로젝트 요구 사항을 명확하게 정의하면 프로젝트 범위를 정의할 수 있습니다. 모든 프로젝트 이해 관계자 및 사용자와 대화하여 프로젝트에서 원하는 것이 무엇인지 정확히 알아내십시오. 받아 적어. 충돌을 관리합니다. 한 이해 관계자가 새 웹 사이트를 파란색으로 만들고 클라이언트가 웹 사이트를 녹색으로 만들고 중재할 사람을 찾고 최종 결정을 내리기를 원한다고 가정해 보겠습니다. 요구 사항을 모두 수행하는 것이 불가능할 수 있으므로 요구 사항의 우선 순위를 지정합니다.

이해 관계자가 말하는 모든 내용을 기록하는 데 시간이 많이 걸릴 수 있지만 기록하고 나면 문서에 모든 요구 사항을 캡처합니다. 이 문서는 요구사항 관리 계획으로 알려져 있으며, 추적 방법 및 변경 프로세스와 같은 프로젝트 요구사항을 관리하는 데 필요한 모든 정보를 포함해야 합니다. 모든 사람이 쉽게 볼 수 있도록 해당 문서를 온라인으로 공유하십시오.

2. 변경 제어 프로세스 설정

요구 사항 문서는 시작점일 뿐입니다. 누군가가 무언가를 바꾸고 싶어하면 어떻게 됩니까?

아무것도 변하지 않을 것이라고 생각하는 것은 비현실적입니다. 범위 이동을 방지하기 위해 필요한 것은 프로젝트에서 관리되고 제어된 변경 사항입니다. 이를 위해서는 프로젝트 계획을 변경해야 할 때 따라야 하는 변경 제어 프로세스의 절차를 정의하는 변경 관리 계획이 필요합니다. 또한 범위 이동과 같은 위험을 추적할 수 있도록 프로젝트의 전체 상태를 모니터링하는 빈도를 설정하는 위험 관리 계획을 갖는 것이 중요합니다.

변경 제어 프로세스는 매우 간단합니다. 기본적으로 누군가가 변경 요청을 통해 변경을 제안하면 검토, 승인 또는 거부되고 승인되면 프로젝트 계획에 통합됩니다. 프로젝트 관리 소프트웨어에 변경 관리 기능이 있는 경우 이를 사용하십시오.

프로젝트에 대한 변경 관리 프로세스를 설정한다는 것은 누가 변경 사항을 검토하고 승인할지 생각하는 것을 의미합니다. 프로젝트 후원자와 또는 팀 회의에서 논의할 수 있습니다.

프로세스가 없으면 변화는 단지… 발생합니다.

3. 명확한 프로젝트 일정 만들기

이해 관계자의 요구 사항을 사용하여 프로젝트 범위를 결정합니다. 그런 다음 WBS(작업 분석 구조)를 사용하여 자세한 작업 목록을 만들 수 있습니다. 프로젝트 일정은 프로젝트가 제공할 내용을 파악한 결과입니다. 작업, 활동 및 이정표의 형태로 모든 요구 사항과 달성 방법을 보여주어야 합니다. 이것은 일반적으로 Gantt 차트에서 만들어집니다.

프로젝트 일정을 요구 사항 관리 계획 문서와 상호 참조하여 잊어버린 항목이 없는지 확인할 수 있습니다.

일정을 요약한 후에는 만일의 사태에 대비하여 계획을 세웠는지 확인하십시오. 위에서 언급했듯이 변경이 발생합니다. 프로젝트 범위 크리프는 변경 관리 계획에 정의된 대로 변경이 처리되지 않은 경우에만 발생합니다.

4. 이해관계자와 프로젝트 범위 확인

이해 관계자 요구 사항을 올바르게 이해했는지 확인하는 것이 중요합니다. 프로젝트 후원자가 프로젝트 결과물에 대해 의미한다고 생각하는 것은 그가 의미한 것과 다를 수 있습니다. 종종 사람들은 자신도 모르는 사이에 교차 목적으로 이야기합니다. 시간을 내어 고객, 투자자 또는 프로젝트 후원자와 같은 이해 관계자에게 돌아가 요구 사항 문서를 공유하십시오. 또한 프로젝트 일정을 보여주고 그들이 볼 것으로 예상한 모든 요소가 작업 목록에 표시되도록 할 수도 있습니다.

제품 기능이나 배송 시간과 같은 사항에 대해 마음이 바뀌었다는 것을 알 수 있습니다. 프로젝트가 시작된 후 나중에 알아내는 것보다 범위 크리프의 위험을 완화하기 위해 계획 프로세스 초기에 프로젝트 계획을 조정하는 것이 중요합니다.

또한 이러한 토론을 통해 스폰서 및 이해 관계자와 변경 제어 프로세스에 대해 이야기할 수 있습니다. 프로젝트 계획의 변경 사항을 관리하는 방법과 진행하기 위해 필요한 승인을 설명하십시오. 이것은 그들이 원하는 것은 무엇이든 가질 수 있다는 것을 상기시키는 유용한 순간입니다. 비용을 지불할 준비가 되어 있다면, 그리고 새로운 요구 사항이 포함된다면 프로젝트가 더 오래 걸릴 것입니다!

이해 관계자가 "너무 바빠서" 이 단계에서 일정을 자세히 설명하고 싶지 않다면 현재 단계를 부드럽게 상기시키십시오. 때로는 의사 소통이 원활하지 않아 주요 이해 관계자가 요구 사항 수집 프로세스가 실제로 종료된 내용을 알지 못했다는 의미입니다!

5. 프로젝트 팀원 참여

프로젝트 이해 관계자가 행복하면 프로젝트 팀 구성원도 행복해야 합니다. 그들은 변경 통제 프로세스와 그것이 그들에게 어떤 영향을 미칠지 알아야 합니다. 그들은 변화의 주체가 아니라 프로젝트 범위의 수호자, 보호자가 되어야 합니다.

때때로 프로젝트 팀 구성원은 도움이 되기를 원하고 공식적인 변경 관리 프로세스를 적용하지 않고 무언가를 변경하는 데 동의합니다. 변경 사항이 승인되지 않고 변경 사항에 대해 예라고 말할 수는 없다고 설명합니다. 변경 사항은 프로젝트 계획에 영향을 미치고 범위가 확대될 수 있기 때문입니다. 이해 관계자를 돕고 싶다면 가장 좋은 방법은 변경 제어 프로세스를 설명하고 변경 내용을 문서화하는 데 도움을 제공하는 것입니다.

범위 크리프는 특히 프로젝트 관리자, 팀 및 이해 관계자가 변경 사항이 리소스, 예산 및 일정에 미칠 수 있는 영향을 이해하지 못할 때 프로젝트에서 실질적인 문제입니다. 다행스럽게도 초기 프로젝트 범위에 대해 명확하고 프로젝트 수명 주기 동안 프로젝트 계획의 변경 사항을 신중하게 관리한다면 큰 문제가 될 필요는 없습니다.

범위 이동을 피하고 프로젝트의 지속적으로 변화하는 요구 사항을 관리하려면 새 변경 사항을 추가하고 실시간으로 검토할 수 있는 변경 관리 기능을 제공하는 작업에 적합한 온라인 프로젝트 관리 소프트웨어가 필요합니다. ProjectManager.com을 사용하면 프로젝트 관리자가 이러한 변경 사항의 우선 순위를 지정하고 작업을 팀 구성원에게 할당할 수 있으며, 변경 사항이 승인되면 다른 사람이 즉시 작업에 착수할 수 있습니다.

PMP가 설명하는 프로젝트 관리의 범위 변화

프로젝트 관리자는 항상 프로젝트의 범위가 커지는 것을 감시하지만 문제는 계속됩니다. 이 비디오는 프로젝트가 탈선하기 전에 이러한 위험을 완화하는 7가지 방법을 제공합니다.

검토 중: 프로젝트 관리 범위 확대

PMP의 Jennifer Bridges는 프로젝트에서 범위 이동을 방지하는 방법에 대한 이 짧은 자습서를 제공합니다. 그녀는 프로젝트를 계획대로 관리하고 변경 사항을 관리하는 데 적용할 수 있는 계획 기술을 제공합니다. 그녀는 범위 이동을 방지하고 처리하는 7가지 방법을 설명합니다.

• 범위 정의
• 변경 사항 기록
• 기준선 재설정
• 추가 자금 및/또는 리소스 요청
• 징후를 조심하십시오
• 우선 순위 설정
• 함정을 피하십시오

때때로 범위 이동의 원인이 리소스라는 점에 유의하는 것이 중요합니다(이 문서는 팀이 통제 불능 상태일 때를 확인하는 데 도움이 될 것입니다). 누가 당신의 프로젝트에서 스코프 크립을 일으키는 문제를 만들고 있습니까? 그들은 팀 구성원에서 이해 관계자에 이르기까지 다양할 수 있습니다. 위에서 설명한 것과 동일한 계획 기술을 사용하여 관리할 수 있습니다.

전문가 팁 : 자신도 잘 살펴보세요! 프로젝트 관리자는 추가 기능과 요구 사항을 추가하여 범위를 확장하는 사람이 아님을 확인하고 싶습니다. 프로젝트에 대한 영향을 자유롭게 토론하고 공유할 수 있는 협업 팀을 개발하는 것이 프로젝트를 지원하는 가장 좋은 방법입니다.

비디오는 이러한 모든 사항에 대해 더 자세히 설명합니다. 프로젝트를 성공적으로 완료하는 데 있어 중요한 장애물을 해결하는 좋은 입문서입니다.

ProjectManager.com이 범위 이동을 억제하는 방법

범위 크리프 관리는 프로젝트 관리와 약간 비슷합니다. 퍼즐처럼 많은 조각을 제어하고 결합해야 합니다. ProjectManager.com은 수상 경력에 빛나는 프로젝트 관리 소프트웨어로 프로젝트와 팀을 구성하여 일정을 유지합니다.

이해 관계자가 변경 사항을 제안하면 이를 캡처해야 합니다. 당사 소프트웨어는 파일 저장 공간이 무제한이므로 상세한 기록을 한 곳에 저장할 수 있습니다. 요구 사항이 있으면 공유해야 하며, 이는 당사 소프트웨어를 사용하여 클릭 한 번이면 됩니다.

변경 사항이 발생하면 컨트롤을 추가하는 것이 범위 이동이 발생하지 않도록 하는 가장 좋은 방법입니다. 이를 위해 워크플로를 시각화하는 칸반 보드가 있습니다. 열은 완전히 사용자 지정할 수 있으므로 제목이 Doing, Testing 및 Done인 열을 만들 수 있습니다. 이제 각 요청을 추적하고 더 큰 프로젝트에 부정적인 영향을 미치지 않는지 확인할 수 있습니다.

변경 사항이 완료 열에 도달하면 프로젝트 일정을 생성하여 해당 변경 사항을 프로젝트 타임라인에 구현해야 합니다. 프로젝트 계획에서와 마찬가지로 온라인 Gantt 차트 중 하나에서 작업을 예약하려고 합니다. 이 시점에서 작업을 설정하고 종속성을 연결하고 작업을 수행할 팀 구성원을 할당할 수 있습니다.

해당 프로젝트 계획을 실행하기 전에 이해 관계자가 이를 보고 승인해야 합니다. 운 좋게도 이해 관계자와 Gantt 차트를 공유하여 엄지손가락을 치켜드는 것은 간단합니다. 그런 다음 계획을 팀과 공유하고 리소스가 용량과 일치하도록 작업의 우선 순위를 지정할 수 있습니다. ProjectManager.com으로 스코프 크리프를 막으십시오!

시청 해주셔서 감사합니다.

전사

안녕하세요. 저는 ProjectManager.com의 이사인 Jennifer Whitt입니다. ProjectManager.com 팬을 환영합니다. 오늘 이 화이트보드 세션이 마음에 드실 거라 생각합니다. 스코프 크리프 방지에 참여해 주셔서 감사합니다.

누가 당신의 프로젝트에서 스코프 크립을 일으키는가?

글쎄, 나는 내 무의식이 스코프 크립 방지를 썼기 때문에 가끔 내 자신을 화나게 하고, 우리 모두가 전에 스코프 크립을 경험했다는 것을 알고 있지만, 스코프 크립을 인식하는 것이 더 좋습니다. 우리 프로젝트의 리소스나 이해 관계자, 또는 범위 확대를 일으키는 문제를 주입하는 사람들인 고객일 수도 있습니다.

따라서 스코프 크리프를 관리하는 기술을 배치하는 것뿐만 아니라 스코프 크리프도 관리하는 것이 중요하다고 생각합니다. 그들은 같은 중요시하는 점은 무엇입니까?
글쎄, 때때로 우리는 스코프가 무섭게 생겼다고 생각하는데, 우리 프로젝트에 스코프를 끼어 넣는 사람들이 무섭게 생겼습니다. 어쩌면 그들은 비열합니다. 그러나 우리가 배운 것은 그들이 당신이 가장 좋아하는 사람들일 가능성이 더 높다는 것입니다.

그들은 당신에게 도넛을 가져다주고 당신을 점심에 데려가는 사람들입니다. 그들은 당신의 가장 친한 친구입니다. 당신은 그들을 위해 모든 것을하고 싶어합니다. 그래서 그들은 항상 작은 추가 사항을 요구하는 사람들입니다. 그것이 우리가 오늘 이야기할 내용입니다. 다음은 이를 관리하는 데 도움이 되는 몇 가지 기술입니다.

스코프 크리프를 피하기 위한 7가지 팁

이것이 내가 궤도를 유지하는 방법에 대해 배운 7가지 팁입니다. 첫 번째로 범위를 정의하십시오. 나는 내가 작업하는 프로젝트의 수에 끊임없이 놀랍니다. 그리고 그들은 실제로 범위를 식별하지 못했습니다. 또는 그들은 그것이 무엇인지에 대한 아이디어를 가지고 있을 수 있지만, 프로젝트가 시작된 후에가 아니라 프로젝트가 시작되기 전에 범위를 미리 알고 정의하는 것이 중요합니다. 당신도 그것을 보았기 때문에 당신이 웃고 있다는 것을 압니다.

1. 사전에 프로젝트 범위 정의

따라서 이를 미리 정의하고 변경 관리 위원회, 이해 관계자, 클라이언트 및 기준선과 동의하는 것이 중요합니다. 프로젝트를 시작하기 전에 범위의 기준을 설정하는 것이 중요합니다.

2. 문서 범위 변경

그런 다음 변경 사항을 기록합니다. 여기 또 하나가 있습니다. 프로젝트 또는 범위의 변경 사항이 문서화되지 않은 곳에서 완전히 충격을 받았습니다. 따라서 변경 사항을 문서화하고, 변경 사항, 변경 사항 또는 프로젝트에 어떤 영향을 미칠지 평가하고 승인하는 것이 좋습니다.

당신이 그것으로 무엇을 할 것인지 알아요. 보류해 볼까요? 우리는 그것을 승인하고, 그 변경을 시행할 것입니까? 우리는 그것으로 무엇을 할 것입니까? 프로젝트의 변경 제어 위원회가 호출을 하는 것이 중요합니다. 당신, 프로젝트 관리자가 아닌, 그렇지 않으면 결국 프로젝트 가방을 들고 남게 될 것입니다.

3. 프로젝트 일정 또는 프로젝트 계획의 기준을 다시 설정하십시오.

세 번째는 기준선을 다시 설정하는 것이므로 이러한 변경 사항이 승인되거나 프로젝트에 통합될 때 일정이나 프로젝트 계획의 기준선을 설정하는 것이 중요합니다. 그것은 할 수 있는 하나의 간단한 일입니다. 그래서 저는 여러분이 보고 있는 통계를 모릅니다. Gartner를 비롯한 여러 조직 및 기타 여러 조직에서 지속적으로 실패한 프로젝트의 수를 확인하는 것으로 알고 있습니다.

따라서 소스를 고려하십시오. 한 소식통은 프로젝트의 75%가 실패한다고 말합니다. 글쎄, 그 대부분은 사람들이 변화를 통제하지 못하는 이 영역에 있습니다. 이해 관계자와 변경 관리 위원회에서 변경 사항에 동의하고 해당 그룹에서 승인한 다음 다시 기준을 설정하면 프로젝트가 실패하지 않을 수 있습니다. 그것은 당신이 실패한 프로젝트의 75%에 속하는지 성공한 프로젝트의 25%에 속하는지의 차이입니다.

따라서 단순히 숫자로만 본다면 방에 10명의 프로젝트 관리자가 있으면 7.5이고 반올림하면 8명은 실패한 프로젝트를 관리하고 2명은 성공한 프로젝트입니다. 약간의 차이는 범위 변경을 관리하고 계획을 다시 설정하는지 여부만큼 작을 수 있습니다.

4. 추가 자금 또는 리소스 요청

네 번째, 추가 자금이나 자원을 요청하십시오. 이제 변경 사항이 승인되었습니다. 기준선을 다시 설정했습니다. 그러나 때때로 어떤 사람들에게는 돌아가서 추가 리소스를 요청하는 것이 어렵습니다. 이러한 변경을 수행하는 데 필요한 자금입니다. 이에 동의하지만 다시 돌아가서 이러한 변경을 수행하는 데 필요한 인력, 자금, 자원을 요청하지 않으면 다시 여기 통계로 돌아갑니다.

5. 프로젝트 팀과 의사 소통하고 진행 상황 추적

다섯 번째, 신호를 주시하십시오. 따라서 프로젝트 관리자는 항상 팀과 팀의 행동을 주시해야 합니다. 사람들이 일하고 있지만 팀으로부터 아무런 신호나 피드백을 받지 못하는 상황이 너무 조용해지면 징후가 나타나는 것 같습니다. 또는 프로젝트 팀이나 팀 구성원에게 "상황이 어떻게 되가고 있습니까?"라고 물을 때 항상 문제가 없습니다. 모든 것이 순조롭게 진행되고 있습니다. 글쎄요, 그것들은 무언가가 옳지 않을 수 있다는 신호입니다.

따라서 항상 돌아가서 팀 구성원, 프로젝트를 확인하고 실제로 완료되는 항목을 보고 "정말 제대로 가고 있습니까?"를 확인하고 평가하는 것이 좋습니다. 쿠키, 브라우니, 도넛을 스코프에서 가져와서 변경 사항을 구현하고 조용히 수행하고 있습니까? 프로젝트가 끝날 때만 당신의 스코프가 어디에서 기어들어갔는지 그리고 당신이 그것에 대해 몰랐는지 알아내기 위한 것입니다.

6. 우선순위 설정

여섯째, 우선순위를 정하라. 다시 말하지만, 이는 이전 단계로 돌아가서 변경 제어 위원회가 변경 사항을 평가하고 우선 순위를 지정하도록 합니다. 이것은 우리가 일반적으로 여러 그룹을 볼 때 발생합니다. 때로는 프로젝트와 함께 변경 사항을 가져오는 비즈니스 단위와 같은 다양한 이해 관계자가 있을 때 다툼이 발생합니다. 변경 제어 위원회가 승인해야 할 변경 사항을 결정하도록 합니다. 변경 제어 보드가 그렇게 하도록 하십시오. 그렇지 않으면 원하지 않는 나쁜 위치에 있게 될 것입니다.

7. 스코프 크립 트랩 피하기

일곱 번째, 함정을 피하십시오. "당신이 거기 있는 동안… 또는 "당신이 해야만 하는 모든 것은..." 그들은 전에 한 번도 해본 적이 없지만 간단한 해결책을 가지고 있습니다. 또는 내가 가장 사랑하는 사람, "이봐, 그렇게 오래 걸리지 않을 거야."

글쎄, 무엇을 기반으로? 누구의 평가에 근거한 것인가? 한 번도 해보지 않은 사람들을 기반으로 합니까? 변경 또는 평가가 없는 경우를 기준으로 합니까? 따라서 이것은 75% 이상의 실패한 프로젝트에 빠지게 된다는 점에서 우리가 발견하는 작은 함정입니다.

그래서 인정해야 합니다. 제가 고객일 때 쿠키와 도넛과 피자를 먹는 사람이기 때문에 사실 스코프 크리프입니다. 원하다. 따라서 이 팁 중 일부는 내 프로젝트에서뿐만 아니라 내가 범위가 크리프인 다른 프로젝트의 고객인 나 자신에게서 배웠습니다.

따라서 스코프 크리프를 관리하기 위한 팁, 도구 또는 기술이 필요하거나 더 나은 방법으로 스코프 크리프를 식별하려면 ProjectManager.com을 방문하십시오.