프로젝트 범위를 정의하는 간단한 8단계 가이드

프로젝트를 관리할 때 프로젝트 규모가 너무 크거나 작기보다는 적절해야합니다. 즉, 모든 프로젝트 결과물을 파악할 수 있을 만큼 크지만 목표를 달성할 수 있을 만큼 작은 적절한 규모가 좋습니다.

이렇게 하는 방법은 프로젝트 범위를 정의하는 것입니다. 프로젝트 범위를 정의하면 팀에 과도한 업무를 부여하지 않으면서도 프로젝트 결과물을 기한 내에 예산에 맞춰 달성하는 데 도움이 됩니다. 이 기사에서는 프로젝트 범위를 정의하고 관리하기 위해 필요한 모든 것을 소개합니다.

프로젝트 범위란?

프로젝트 범위는 프로젝트의 경계선을 명확히하고 목표, 마감일, 프로젝트 결과물을 정확히 정의하는 수단입니다. 프로젝트 범위를 명확히하면 업무가 지연되거나 과도하게 일하지 않고도 프로젝트 목표와 목적을 달성할 수 있습니다.

프로젝트 범위를 정의하는 것은 한 사람만의 일이 아닙니다. 오히려 주요 프로젝트 이해관계자들과 협력하여 모두가 동일하게 이해하고 있는지 확인해야 합니다. 예를 들어, 제품 출시 마케팅을 준비한다면 제품팀, 디자인팀, 콘텐츠팀과 같은 회사 유관 팀의 이해관계자들과 협력해야 합니다. 프로젝트가 얼마나 복잡한지에 따라 변경 관리 프로세스를 정의할 수도 있습니다. 변경 관리 프로세스를 수행하는 방법은 나중에 다시 설명하겠습니다.

프로젝트 범위 기술서란?

프로젝트 범위 기술서는 단순히 프로젝트 범위를 작성한 문서입니다. 프로젝트의 복잡성에 따라 범위 기술서는 프로젝트 계획의 섹션이나 독립적인 문서가 될 수 있습니다. 또한 외부 팀이나 에이전시와 협력한다면 프로젝트 범위 기술서를 작업 명세서(Statement of Work, SOW)로 사용하여 공급업체와 협의한 내용을 공고히 할 수 있습니다.

범위 변동이란?

범위 변동은 프로젝트 결과물이 프로젝트의 범위를 초과할 때 발생합니다. 예를 들어, 제품 출시를 준비하고 있지만 프로젝트 범위 기술서를 작성하지 않았다고 가정해보겠습니다. 프로젝트 진행 중간에 이해관계자가 프로젝트 결과물에 언론 보도를 추가합니다. 며칠 후 다른 이해관계자가 신제품에 관한 블로그 게시물을 추가합니다. 이렇게 되면 프로젝트 팀이 예상하거나 준비하지 못한 작업이 추가되어 불필요한 스트레스를 받거나 프로젝트의 원래 결과물이 지연될 수 있습니다.

프로젝트에 범위 변동이 발생하여 어려움이 생기면 처음 프로젝트를 시작할 때는 예상하지 못했던 작업을 수행하게 됩니다. 이로 인해 프로젝트가 지연되고, 업무가 너무 많아지거나 결과물의 품질이 낮아질 수 있습니다.

범위 변동을 방지하는 가장 좋은 방법은 확실한 프로젝트 범위 기술서를 작성하고 프로세스 초기에 최대한 빨리 관련 이해관계자들과 공유하는 것입니다. 이렇게 하면 모든 사람이 프로젝트에서 수행하는 작업과 그렇지 않은 작업을 정확하게 파악할 수 있습니다.

프로젝트 범위를 미리 정의하면 좋은 점

프로젝트 범위를 정의하는 것은 프로젝트 계획의 핵심 요소입니다. 명확한 범위 기술서가 없으면 프로젝트가 팀이 완료할 수 있는 범위를 넘어서 왜곡되고 커져 계획이 지연되거나 번아웃을 초래할 수 있습니다. 프로젝트 범위는 프로젝트의 전체 주기를 구상하고 최종 목표를 달성할 수 있는지를 확인하는 데 도움이 됩니다. 특히 프로젝트 범위를 정의하면 다음을 할 수 있습니다.

• 모든 이해관계자가 프로젝트의 경계선을 명확하게 이해합니다

• 이해관계자의 기대치를 관리하고 동의를 얻습니다

• 프로젝트 위험을 줄입니다

• 적절하게 예산을 배정하고 리소스 계획을 수립합니다

• 프로젝트를 주요 목적에 맞춥니다

• 범위 변동을 예방합니다

• 변경 요청 프로세스를 수립합니다(복잡한 프로젝트의 경우)

프로젝트 범위를 정의하는 8단계

1. 먼저 프로젝트 목적을 설명합니다

프로젝트 범위를 정의하기 전에 먼저 프로젝트 목적의 개요를 설명해야 합니다. 프로젝트 목적은 프로젝트가 끝나면 산출되는 자산입니다. 궁극적으로 프로젝트 범위는 목표를 달성하는 데 도움이 되지만, 먼저 그 '목표'가 무엇인지 알아야 합니다.

2. 리소스 계획이 없다면 작성합니다

프로젝트 목적 외에도 사용할 수 있는 리소스를 알아야 합니다. 프로젝트 관리에서 리소스는 프로젝트 예산부터 팀의 실행 가능한 업무량까지 무엇이든 될 수 있습니다. 리소스 관리 계획은 해당 프로젝트에 사용할 수 있는 리소스와 사용 방법을 요약하여 설명합니다.

리소스 관리 계획을 정의한 후 프로젝트 범위를 작성하도록 계획하세요. 이렇게 하면 프로젝트 범위 기술서를 작성할 때 사용할 수 있는 리소스가 무엇인지 정확히 알 수 있으며, 사용 가능한지 여부에 따라 프로젝트 범위를 조정할 수 있습니다.

3. 기타 요건을 수집하여 정리합니다

초기 프로젝트 계획에는 다른 중요한 요소가 있습니다. 그러나 이 단계에서는 프로젝트 범위에 영향을 미칠 수 있는 다른 요소를 중점적으로 살펴보아야 합니다. 프로젝트 범위는 프로젝트의 경계선과 주요 목적, 예산, 리소스, 결과물을 문서화하는 수단이라는 점을 기억해야 합니다. 예를 들어, 프로젝트 타임라인과 같이 이러한 요소에 영향을 미칠 수 있는 다른 것이 있다면 이 단계에서 모아 정리하세요.

4. 프로젝트 범위 기술서의 초안을 작성합니다

이제 수집한 모든 자료를 프로젝트 범위 기술서에 정리할 때입니다. 프로젝트 범위 기술서에는 수행하는 것, 수행하지 않는 것, 이유를 설명해야 합니다.

프로젝트의 복잡성에 따라 프로젝트 범위 기술서는 글머리 기호 목록, 긴 단락 또는 완전한 SOW가 될 수 있습니다. 길이와 관계없이 프로젝트 범위 기술서는 프로젝트 목적이 무엇이며 프로젝트에서 실행할 사항과 실행하지 않을 사항을 설명해야 합니다.

범위를 정의하는 데 도움이 필요하다면 다음과 같은 질문에 답해 보세요.

• 이 프로젝트를 진행하는 이유는 무엇인가요? 궁극적인 목표와 결과물은 무엇인가요?

• 어떤 제한이 있나요? 사용 가능한 예산, 인원, 리소스는 얼마나 되나요? 어떤 팀원들이 참여하나요?

• 결과물의 마감일은 언제인가요? 어떤 타임라인에 맞춰야 하나요?

• 범위에 포함되지 않는 것은 무엇인가요?

프로젝트 범위 기술서 예시

회사 웹사이트를 다시 구축한다고 가정해 보겠습니다. 프로젝트 범위는 다음과 같습니다.

프로젝트 목적: 페이지 속도와 유연성을 개선하기 위해 웹사이트 백엔드를 CMS 플랫폼으로 이전합니다.

리소스:

• 웹팀(3명), 6주 동안 주 30시간 근무

• 엔지니어링 매니저(1인), 6주 동안 주 10시간 근무

• IT 및 법무팀 검토(팀 2개), 주 5시간 단발성 근무

• CMS 예산 $7,000

결과물:

• 2021년 5월 말에 모든 콘텐츠 작성자 교육

• 2021년 6월까지 새 CMS에 전체 웹사이트 이전

프로젝트 로드맵 및 타임라인:

• 4월 26일: CMS 범위 지정 시작

• 5월 10일: IT 및 법무팀 검토

• 5월 17일~6월 3일: 웹 팀 이전

• 5월 31일: 콘텐츠 작성자 교육

• 6월 4일: CMS 실제 운영

범위 외:

• 새로운 DAM 시스템

• 새 CMS에서 사용자 지정 가능한 웹 페이지

5. 주요 이해관계자로부터 동의와 승인을 받습니다

프로젝트 범위 기술서를 승인하기 전에 프로젝트 이해관계자로부터 동의를 받으세요. 내용을 변경하고, 프로젝트의 목적을 재고하고, 프로젝트 범위에 포함되는 것과 그렇지 않은 것을 판단할 기회입니다. 프로젝트를 시작하고 나면 프로젝트 범위 기술서의 요소를 변경하기가 더 어려워지므로 중요한 이해관계자들에게 범위를 잘 전달하세요.

6. 필요에 따라 변경 관리 프로세스를 확립합니다

이해관계자가 많거나 복잡한 이니셔티브를 관리한다면 변경 관리 프로세스를 설정하는 것이 도움이 될 수 있습니다. 규모가 크거나 복잡한 프로젝트라면 변경이 불가피합니다. 타임라인을 지나치게 이상적으로 수립했거나 새로운 고객 피드백을 반영하여 중요한 결과물 몇 가지를 변경해야 할 수 있습니다. 프로젝트가 절대로 변경되지 못하게 하는 것도 좋지 않지만, 범위 변동이 발생할 수 있기 때문에 아무나 변경할 수 있게 만드는 것도 좋지 않습니다.

변경 프로세스는 이해관계자가 변경한 내용이 승인되기 전에 거쳐야 하는 일련의 확립된 프로세스입니다. 변경 관리 프로세스를 수립하려면 프로젝트 팀과 이해관계자가 변경 요청을 제출할 방법을 마련하세요(예: 한 곳에서 수신 양식을 사용하여 제출). 그런 다음, 미리 선정된 중요한 이해관계자가 변경 내용을 검토하고, 변경 요청이 추가할 가치가 있을 만큼 중요한지 확인해야 합니다. 가치가 있다면 범위 변동을 피하기 위해 계획했던 일부 업무의 우선순위를 낮출 수 있는지 확인하세요.

7. 프로젝트 범위 기술서를 팀과 공유합니다

이해관계자가 프로젝트 범위를 확인하고 승인한 뒤 이를 프로젝트 팀에 공유합니다. 업무 관리 툴과 같이 팀이 한 곳에서 모든 업무에 액세스할 수 있는 툴을 사용하세요.

8. 프로젝트를 수행하면서 프로젝트 범위 기술서를 참조합니다

프로젝트 범위 기술서를 자주 참조하여 프로젝트가 계획대로 진행되고 있고 범위 변동의 위험이 없는지 확인하는 것이 좋습니다. 변경 관리 프로세스를 거치지 않고 새로운 요소를 프로젝트에 도입하는 사람이 있다면 프로젝트 범위 기술서를 참조하여 아이디어를 요청이나 빠른 후속 조치 형식으로 제출하도록 권장하세요.

프로젝트 범위로 합리적인 경계선 설정

프로젝트 범위 기술서는 프로젝트를 계획대로 순조롭게 진행하여 성공을 거두는 데 도움이 되는 훌륭한 수단입니다. 또한, 프로젝트 팀을 지원하고 번아웃을 방지하는 좋은 방법이기도 합니다. 그러나 프로젝트 범위는 효과적으로 전달된 경우에만 유용합니다. 프로젝트 초기에 프로젝트 범위 기술서를 공유한 뒤 프로젝트 수행 중에 자주 참조해야 합니다.