범위 변동의 7가지 주요 원인 및 방지책

프로젝트 결과물을 완성하기 위해 프로젝트를 열심히 수행하고 있다고 가정해 보겠습니다. 갑자기 다른 부서의 이해관계자가 결과물을 추가했습니다. 계획한 것은 아니지만, 충분히 쉽게 할 수 있어 이를 수락합니다. 그리고 며칠 뒤 또 다른 이메일이 옵니다. 프로젝트가 계획대로 진행되는 대신 갑자기 지연되는 바람에 수포로 돌아가고 말았습니다.

이를 바로 범위 변동이라고 합니다. 범위 변동은 누구에게나 일어날 수 있습니다. 이 기사에서는 범위 변동이 발생하는 원인과 이를 방지하는 방법을 살펴보겠습니다.

프로젝트 관리에서 범위 변동이란?

프로젝트 관리에서 프로젝트 범위란 프로젝트의 요구 사항과 결과물에 대한 개요입니다. 프로젝트 범위는 일반적으로 프로젝트 계획 프로세스가 시작될 때 정의되며, 프로젝트 계획, 로드맵 또는 브리프에 명시되어야 합니다. 범위 변동 은 요구 사항과 결과물이 사전에 설정한 프로젝트 범위를 넘어설 때 발생합니다.

프로젝트 범위를 설정하는 것이 중요한 이유

프로젝트 매니저는 범위 관리 계획을 수립할 때 모든 프로젝트 이해관계자와 공통적으로 이해할 사항을 조율하게 됩니다. 프로젝트 범위를 설정하지 않으면 보조를 맞출 수 없고 오해가 발생할 수 있습니다. 프로젝트 범위를 정의하지 않으면 프로젝트 결과물에 무엇을 포함해야 하며 무엇을 포함하지 않을지 명확하게 파악할 수 없으며, 사전에 이러한 범위를 승인받아 제어할 수 없습니다.

때로는 범위 변동이 발생해도 문제가 없는 경우가 있습니다. 번거롭기는 하지만 추가적으로 한두 개의 결과물을 완성해야 하는 것처럼 프로젝트에 중대한 영향을 미치지 않을 수 있습니다. 그러나 중대한 범위 변동이 발생하면 프로젝트 목표에서 주의를 분산시켜 프로젝트의 성공을 저해할 수 있습니다. 추가적인 요청과 결과물에 허비한 시간은 프로젝트의 실제 목표를 달성하는 데 사용되지 않은 시간이며, 번아웃과 과로로 이어질 수 있습니다.

프로젝트 범위를 파악하는 방법

범위 변동을 방지하려면 우선 명확하게 정의된 프로젝트 범위가 필요합니다. 다행히 프로젝트의 범위를 정하는 일은 생각보다 어렵지 않습니다. 프로젝트 범위는 대부분 프로젝트 브리프와 같이 초기에 다른 프로젝트 문서에서 작성한 내용을 바탕으로 몇 가지 항목을 기록하는 것입니다.

프로젝트 범위를 파악하고 설정하려면 다음 5가지 단계를 따르세요.

1. '왜'에서 시작합니다. 왜 해당 프로젝트에 참여하고 있나요? 어떤 것을 성취하고 싶은가요? 성취하고자 하는 것의 규모와 범위를 알면 프로젝트 범위를 정의하는 데 도움이 됩니다.

2. 프로젝트 목표를 포함합니다. 프로젝트 목표와 프로젝트 범위는 긴밀하게 연결되어있습니다. 프로젝트 목표는 프로젝트의 목적을 정의하고 결국 프로젝트 범위에 맞아야 합니다.

3. 프로젝트 범위를 작성합니다. 길게 쓸 필요는 없습니다. 프로젝트 범위는 단지 프로젝트 결과물과 이러한 결과물이 프로젝트 목표와 어떻게 관련되는지 명확하게 설명하는 것입니다. 글머리 기호도 자유롭게 사용하세요.

4. 프로젝트 범위를 검토합니다.  이해관계자로부터 승인을 받고 모두가 프로젝트 결과물, 목표, 범위에 관해 동일하게 이해하고 있는지 확인하세요.

5. 필요에 따라 조정합니다. 4번째 단계에서 조율되지 않았다면 프로젝트 범위를 다시 작성하는 시간을 가지세요. 확정하기 전에 이해관계자에게 문서를 전달하여 승인을 받으세요.

범위 변동의 일반적인 원인 7가지

누구도 프로젝트가 실패하거나 본래의 목표를 놓치길 원하지 않습니다. 범위 변동의 가장 일반적인 원인과 이를 방지하는 방법은 다음과 같습니다.

1. 프로젝트 범위가 없는 경우

지극히 당연하게 들릴지도 모르지만, 매우 중요합니다. 프로젝트 범위가 없으면 관련된 모든 사람과 프로젝트 범위를 조율하고 소통할 수 있는 명확한 방법이 없습니다. 더욱이, 외부 팀이나 에이전시와 작업한다면 이해관계자가 프로젝트에 새로운 요소를 추가하려고 할 때 관련 문서나 작업 명세서(Statement of Work, SOW)를 제시할 수 없습니다.

프로젝트를 시작할 때 프로젝트의 범위를 생성하고 정의해야 합니다. 프로젝트 계획이나 초기에 작성하는 기타 문서에 프로젝트 범위를 추가해도 좋습니다. 이렇게 하면 초기에 작성한 모든 프로젝트 문서에 프로젝트 범위에 대한 기준선을 포함할 수 있습니다.

2. 의사소통의 부재

프로젝트 범위를 갖추면 이를 공유해야 합니다. 프로젝트의 초기에 문서를 효과적으로 배포하지 않으면 이해관계자는 정보를 계속해서 공유받지 못하게 됩니다. 많은 시간을 투자하여 프로젝트 범위를 작성했더라도 모두가 프로젝트 범위를 인식하지 못하면 보조를 맞추지 못하거나 프로젝트가 실패할 수 있습니다.

프로젝트 계획이나 프로젝트 브리프와 같이 초기에 작성하는 프로젝트 문서에 프로젝트 범위를 반드시 포함하세요. 이렇게 하면 모두가 프로젝트 범위 기술서를 확인하여 프로젝트에 착수하기 전에 공통된 이해를 바탕으로 업무에 임할 수 있습니다.

3. 불분명한 프로젝트 목표

궁극적으로 특정한 성과물을 전달하려는 목적을 가지고 프로젝트를 수행할 것입니다. 이러한 성과와 자산이 프로젝트의 목표입니다.

프로젝트 목표가 명확하면 프로젝트 팀은 프로젝트에서 최종적으로 성공을 거두는 데 기여하는 작업이 무엇이며 그렇지 않은 작업이 무엇인지 쉽게 파악할 수 있습니다. 이렇게 하면 생산적이고 우선순위가 높은 작업에 노력과 에너지를 집중할 수 있습니다. 반면에, 프로젝트 목표가 명확하지 않으면 팀원은 어떤 작업을 우선적으로 처리해야 할 지 알지 못한 채 프로젝트의 목표 달성에 기여하지 않는 작업을 수행할 수도 있습니다.

불분명한 프로젝트 목표의 예시: 회사 블로그를 개선하여 독자들이 좋아하는 이야기를 싣기.

분명한 프로젝트 목표의 예시: 1분기에 고객 스토리, 팁, 신제품 기능, 팀 스포트라이트, 사고 리더십 등 최소 5가지 유형의 블로그 게시물 작성하기. 새로운 블로그 게시물에 대한 참여도를 면밀히 모니터링하여 향후 분기에 집중적으로 다룰 상위 3개 카테고리를 결정하기.

4. 비현실적인 프로젝트 목표

프로젝트 목표가 분명할 수도 있습니다. 하지만, 팀이 주어진 시간과 프로젝트 범위 내에서 그러한 목표를 현실적으로 달성할 수 없다면 프로젝트는 필연적으로 실패하거나 범위 변동을 겪게 될 것입니다.

팀이 보유한 리소스로 기한 내에 목표를 달성할 수 있는지 확인하세요. 최종적으로 프로젝트를 성공적으로 끝마칠 수 있도록 프로젝트 목표 대비 범위와 프로젝트 일정을 확인하세요. 프로젝트 목표와 프로젝트 범위가 프로젝트의 시작 단계에서 일치하지 않으면 범위 변동을 관리하기가 거의 불가능해집니다.

5. 너무 많은 이해관계자

사공이 많으면 배가 산으로 간다는 말이 있습니다. 프로젝트에 명확한 프로젝트 소유자, 즉 프로젝트 매니저가 없으면 업무는 불분명해지고 범위도 흐려질 수 있습니다.

프로젝트에는 다양한 이해관계자와 협업 참여자가 있지만, 모든 팀에는 작업 진행을 직접적으로 책임지는 프로젝트 리더가 있어야 합니다. 추가적인 프로젝트 역할을 만들려면 RACI 매트릭스를 작성해보세요. RACI는 프로젝트 관리의 4가지 주된 역할을 나타냅니다.

• Responsible(실무 담당자): 프로젝트를 진행하는 사람입니다. 실무 담당자는 실무와 관련된 대부분의 결정을 내립니다.

• Approver(승인자): 때때로 이해관계자나 이해관계자 그룹으로부터 승인이 필요할 수도 있습니다. 승인자는 몇 가지 예를 들자면 예산, 목표, 논조 등을 정할 수 있습니다.

• Consulted(업무 수행 조언자): 의견, 통찰력, 지침 등을 확인해 줄 수 있는 사람들입니다. 실무 담당자와 승인자가 최종 결정권을 갖지만, 업무 수행 조언자는 일반적으로 해당 분야의 전문가입니다.

• Informed(결과 통보 대상자): 프로젝트에 관해 알아야 할 모든 사람입니다. 결과 통보 대상자에는 프로젝트 팀, 여러 부문의 이해관계자 또는 임원이 포함될 수 있습니다.

6. 비효과적인 변경 관리 프로세스

역할이 명확하게 정의되더라도 효과적인 변경 관리 프로세스가 필요합니다. 변경 관리란 프로젝트 범위를 포함하여 프로젝트에서 중요하거나 기본적인 요소를 변경하는 프로세스입니다. 이해관계자가 단순히 프로젝트를 변경하게 하는 대신 프로젝트 변경에 관해 일련의 규칙과 제약을 적용하는 것입니다. 일반적으로, 변경 관리 프로세스는 팀원이나 이해관계자가 변경 요청을 제출하는 프로세스, 프로젝트 매니저와 기타 중요한 프로젝트 이해관계자가 해당 요청을 검토하는 단계, 그런 다음 해당 변경을 수락할지, 거부할지 또는 연기할지 여부를 판단하는 시스템이 포함됩니다.

변경 관리 프로세스는 꼭 필요한 경우에 새로운 요청을 추가할 수 있는 유연성을 갖추면서도 프로젝트를 다시 통제할 수 있어 중요합니다. 변경 관리 프로세스를 갖추면 프로젝트의 세부 사항이 변경되더라도 타당한 이유로 인해 변경되었다는 것을 확신할 수 있습니다.

7. 막바지에 받는 고객 피드백

고객 피드백은 새로운 제품이나 마케팅 캠페인과 같이 고객을 대하는 업무에서 핵심입니다. 그러나 피드백을 적극적으로 수집하지 않으면 프로젝트의 의도, 범위, 타임라인, 목표를 완전히 바꿔버리는 고객 피드백을 뒤늦게 받을지도 모릅니다. 이러한 피드백으로 인해 이미 수행 중인 일을 변경하거나 새로운 기능과 새로운 요구 사항을 처음부터 다시 시작하게 될 수 있습니다.

사람이 하는 일인지라 막바지에 변경될 수 있습니다. 그러나 이에 대해서 크게 할 수 있는 일이 없습니다. 때때로 프로젝트에서 중요한 요소를 변경해야 하지만 이를 막기 위해 할 수 있는 일이 없었을 수도 있습니다.

이러한 일이 발생할 가능성을 줄이는 가장 좋은 방법은 고객 피드백을 초기에 많이 받는 것입니다. 사용자 피드백을 정기적으로 수집하고 고객 피드백을 적극적으로 확보하세요. 무료 사용자 리서치 템플릿을 활용할 수 있습니다.

범위 변동을 관리하고 방지하는 방법

프로젝트를 이미 시작했고 범위 변동이 걱정된다면, 앞으로 무엇을 하면 될까요?

범위 변동이 발생할 것 같다고 느끼면 다음 몇 가지를 수행할 수 있습니다.

1. 프로젝트 범위를 표면화하세요. 프로젝트 이해관계자가 새로운 결과물을 요구한다면 프로젝트 범위와 프로젝트 범위에 포함된 부분과 아닌 부분을 상기시켜주세요. 전체 프로젝트 팀이 프로젝트의 요구사항을 인식하는 데 도움이 될 것입니다.

2. 그래도 효과가 없다면, 변경 관리 프로세스를 시도해 보세요. 설정해둔 변경 관리 프로세스를 통해 요청자가 변경 요청을 제출한 뒤 프로젝트 이해관계자와 해당 요청을 검토하고 프로젝트 범위를 변경할 만한 가치가 있는지 결정하세요.

3. 범위 변경이 승인되면 다른 결과물의 우선순위를 낮추는 것을 고려하세요. 새로운 작업을 수행하기 위해 일정을 뒤로 미루거나 생략할 수 있는 부분이 있는지 확인해 보세요.

4. 현재 계획된 작업의 우선순위를 낮출 방법이 없다면, 프로젝트 리소스를 확인하세요. 리소스 관리 계획을 활용하여 프로젝트 목표를 달성하는 데 도움이 되는 리소스가 있는지 확인하세요.

프로젝트 범위, 목표, 계획 모두를 명확하게 하고 이를 유지하려면 Asana와 같은 업무 관리 툴을 사용하세요. Asana를 사용하면 전체 업무 흐름을 관리하고 프로젝트 팀과 공유하여 모두가 동일한 이해를 바탕으로 업무를 수행할 수 있습니다.

범위 변동에서 벗어나세요

어떤 이들은 범위 변동이란 발생하기 마련이라고 말할 수도 있습니다. 하지만 꼭 그렇지는 않습니다. 명확한 프로젝트 범위와 가시적인 프로젝트 계획, 손쉽게 사용 가능한 업무 관리 솔루션을 사용하면 프로젝트 범위를 벗어나지 않고 프로젝트 목표를 달성할 수 있습니다.

업무 관리를 시작할 준비가 되었나요? Asana에 대해 자세히 알아보세요.