홈 " 블로그 " 효과적인 프로젝트 범위 관리를 위한 4단계

몇 달 전, 프로젝트 관리자를 위한 유명한 온라인 플랫폼인 Project-Management. com에서 다음과 같은 이야기를 발표했습니다. 프로젝트 실패의 상위 10가지 원인. 이 텍스트만 훑어보면 프로젝트 범위 관리에 대한 내용은 찾아볼 수 없습니다. 하지만 자세히 읽어보면 저자가 설명하는 요소들이 프로젝트의 범위를 정의하고 관리하는 것과 매우 밀접한 관련이 있다는 것을 알 수 있습니다.

이 글을 통해 무엇을 얻을 수 있을까요?

준비 부족 이 가장 큰 실패 원인으로 꼽혔고, 그다음으로 부적절한 문서화 및 추적. 목록은 다음과 같이 마감됩니다. 프로젝트 경고 신호를 무시합니다. 이 블로그 게시물은 프로젝트의 범위를 효과적으로 관리하여 이러한 위험을 줄이거나 제거하는 데 도움을 주기 위해 작성되었습니다.

범위 관리는 준비에서 시작되며 적절한 문서화 및 프로젝트 진행 상황 모니터링과 불가분의 관계에 있다는 것을 알아보세요. 프로젝트의 경고 신호는 무엇인가요? 가장 불길한 징후 중 하나는 범위가 커지는 것입니다. 다행히도 성공적인 범위 관리를 통해 이를 방지할 수 있습니다.

이 가이드에서 사용할 가장 중요한 용어를 정의하는 것부터 시작하겠습니다:

프로젝트 범위 관리란 무엇인가요?

범위는 어떻게 되나요?

철학자들이 말했듯이, 우리가 사용하는 용어에 대한 이해 없이는 전혀 이해할 수 없습니다. 그렇다면 '범위'는 무엇을 의미할까요?

프로젝트 관리 서클 외부의 기관인 옥스퍼드 사전에서 제공하는 정의부터 시작하겠습니다. 덕분에 우리는 두 가지 의미에 대해 읽을 수 있습니다. 범위 용어입니다. 첫째, 범위는 잠재력, 기회, 기회일 뿐입니다. 리소스 용량변화하고, 성취하고, 무언가를 할 수 있는 가능성을 의미합니다. 그러나 두 번째 의미는 프로젝트 관리 사회와 충분히 가까워서 인용할 가치가 있습니다. 범위입니다:

(...) 주제, 조직, 활동 등이 다루는 사물의 범위입니다.

(옥스퍼드 사전)

프로젝트 관리의 범위는 어떻게 되나요?

위의 정의를 다음과 같이 표현한 정의와 비교해 보면 프로젝트 관리자 사이에서 잘 알려진 기관에서 연결을 확인할 수 있습니다.

프로젝트 관리 협회 덕분에 우리는 '범위'가 결과, 성과, 혜택의 전체와 프로젝트를 제공하는 데 필요한 작업 전체를 의미한다는 것을 알게 되었습니다. 즉, 프로젝트의 모든 요구 사항(즉, 제품을 성공적으로 제공하기 위해)을 산출하는 데 필요한 작업 및/또는 적절히 숙련된 직원이라고 할 수 있습니다.

오해를 피하기 위해 언급할 가치가 있습니다. 이 의미는 비슷하게 들리는 것보다 약간 더 넓은 의미입니다. 제품 범위. 제품 범위는 일반적으로 제품 또는 서비스의 특징과 기능을 자세히 설명합니다. 동안:

프로젝트 범위는 제품의 범위(필요한 기능 및 특징)에 따라 제품을 제공하기 위해 수행해야 하는 작업입니다.

(Wrike.com)

프로젝트 범위 관리란 무엇인가요?

이를 염두에 두고 프로젝트 범위 관리란 무엇일까요? 프로젝트 관리 협회에서 정의합니다:

범위 관리는 산출물, 결과 및 혜택을 식별, 정의 및 통제하는 프로세스입니다. '범위'는 프로젝트 관리에서 사용되는 용어로 산출물, 결과 및 혜택의 총합과 이를 생성하는 데 필요한 작업을 나타냅니다.

(APM 지식 체계, 7판)

하지만 이전 버전에서는 PMBOK® 가이드, 6판 관점에서 프로젝트 범위 관리는 프로젝트에 다음이 포함되도록 하는 프로세스입니다. 필요한 모든 작업과 필요한 작업만 수행합니다.

간단히 말해, 7판의 프로젝트 범위 관리는 프로젝트의 모든 측면에 대한 지식을 습득하고 문서화하는 시간과 단계(프로세스)로 해석할 수 있습니다. 그리고 프로젝트 범위 관리 프로세스의 결과는 프로젝트 계획에 포함되어야 하는 모든 것(작업 및 하위 작업, 예산, 책임 등)의 목록입니다.

그러나 6판에서는 프로젝트에 필요한 작업(및/또는 적절한 숙련된 직원)을 강조합니다. 마지막 관점에서 프로젝트 관리자는 예상되는 요구 사항에 따라 예상되는 시간에 프로젝트를 제공할 수 있는 (기술과 경험 덕분에) 사람 또는 자원에 초점을 맞춰야 합니다.

이 장의 마지막 부분에서는 다음과 같은 인용문으로 요약해 보겠습니다. 프로젝트 관리 지식 체계 가이드

프로젝트 범위 관리는 주로 프로젝트에 포함되는 항목과 포함되지 않는 항목을 정의하고 제어하는 것과 관련이 있습니다.

(PMBOK® 가이드, 7판)

효과적인 프로젝트 범위 관리를 통해 어떤 이점을 얻을 수 있을까요?

경쟁사이자 잘 알려진 프로젝트 리소스 관리 소프트웨어 제공업체는 웹사이트를 통해 프로젝트 범위 관리 프로세스의 결과와 목표를 알려줍니다.

프로젝트 범위 관리는 모든 프로젝트 목표, 작업, 결과물, 마감일 및 예산(...)의 목록을 결정하고 문서화하는 데 도움이 되는 프로세스입니다.

(Kissflow.com)

보시다시피 프로젝트 계획에 포함되어야 하는 모든 항목의 인벤토리입니다. 그리고 프로젝트 범위 관리의 가장 큰 장점은 프로젝트를 성공적으로 완수하는 데 도움이 된다는 것입니다. 이 프로세스 덕분에 해야 할 일과 하지 말아야 할 일을 알 수 있으므로 더욱 자신 있게 팀을 관리할 수 있습니다.

이 프로세스의 다른 이점은 다음과 같습니다:

 

개발을 고려할 때 고려해야 할 계획 및 단계프로젝트 범위 관리 

아래 나열된 단계는 프로젝트 관리 지식 체계(PMBOK®)를 기반으로 합니다. 종합적인 범위 관리 계획을 찾고 있다면 해당 지침을 확인하세요. 아래에서 예정된 프로젝트에 적용할 수 있는 범위 관리 프로세스를 확인할 수 있습니다.

프로젝트 범위 관리 계획 만들기

계획 범위 관리는 미리 준비하는 것부터 시작해야 합니다. 요구 사항을 수집하고 프로젝트의 범위 초안을 작성하기 전에 어떻게 진행할지 계획하세요. 이 프로젝트의 범위에 대해 의견을 제시할 주요 이해관계자와 모든 사람을 파악하세요.

팀과 만나서 범위를 만드는 프로세스를 정하세요. 프로젝트 범위의 변경 가능성에 대해서도 생각해 보면 도움이 될 것입니다. 물론 이 시점에서는 무엇이 변경될 수 있는지 알 수 없지만, 변경이 발생하면 어떻게 될지 결정할 수 있습니다.

여기에서 내린 모든 결정을 범위 관리 계획에 정리하세요. 나머지 프로세스를 진행하기 위한 지침 문서가 될 것입니다.

요구 사항을 수집하고 프로젝트 범위 정의하기

이제 프로젝트 요구 사항, 즉 프로젝트 목표를 달성하기 위해 수행해야 하는 작업을 수집할 때입니다. 고객에게 가서 다음과 같이 물어보는 것만큼 간단하지 않습니다. 최종 제품의 모양과 동작을 어떻게 만들고 싶으신가요? 이해관계자가 제품에 어떤 특정 기능이 포함되어야 하는지 아직 알지 못할 수도 있기 때문에 요구사항을 수집하는 것은 발견 과정입니다(특히 소프트웨어 개발 관련 프로젝트를 관리하는 경우 더욱 그렇습니다). )

물론 고객이 최종 제품에 대한 정확한 비전을 가지고 있지 않을 수도 있지만, 이 프로젝트가 달성해야 하는 비즈니스 목표는 알고 있을 것입니다. 일련의 워크샵과 인터뷰를 통해 사용자의 요구 사항을 파악하고 그 결과 요구 사항을 수립할 수 있습니다.

데이터 기반 요구 사항을 수집하는 또 다른 방법은 프로토타입으로 일련의 테스트를 수행하여 대상 고객으로부터 가장 긍정적인 반응을 얻는 기능을 확인하는 것입니다.

벤치마킹을 통해 잠재적인 요구 사항을 업계의 모범 사례와 비교할 수도 있습니다.

다양한 요구 사항(특징 및 기능, 비즈니스 목표, 제품 제공에 필요한 프로세스, 승인 기준)의 목록이 완성되면 범위를 정의할 수 있습니다. 일반적으로 처음에 수집한 모든 요소가 최종 프로젝트 범위에 포함되는 것은 아니라는 점에 유의하세요.

프로젝트 범위를 정의한다는 것은 소위 범위 명세서 문서를 만드는 것을 의미합니다. 범위 명세서는 프로젝트의 구성 범위를 문서화하는 곳입니다:

팁: 범위 설명에 제외 사항도 문서화하는 것이 좋습니다(프로젝트 범위에 X와 Y를 포함하지 않습니다.). 나중에 기대치를 관리하고 범위 변경을 협상해야 할 때 유용하게 사용할 수 있습니다.

작업 분류 구조(WBS) 만들기

이 단계는 범위를 더 잘 시각화하고 더 작은 요소로 세분화하는 데 도움이 됩니다. 작업 분류 구조는 프로젝트의 결과물에 해당하는 결과물의 계층적 프레임워크입니다.

전통적으로 WBS는 다음과 같이 설명합니다. 무엇 아닌 어떻게따라서 활동 대신 결과물에 집중해야 합니다(예 결제 보다는 결제 경로 설계/개발/테스트). WBS는 "프로젝트 팀이 수행할 작업"이 아니라 "클라이언트가 받게 될 작업"을 설명하는 문서라고 생각할 수도 있습니다. 하지만 일부 프로젝트 관리자는 이를 작업과 하위 작업의 분류처럼 취급하기도 하는데, 이 역시 유용한 문서입니다.

애초에 WBS를 만들어야 하는 이유는 무엇인가요? 우선, 결과물을 더 작은 단위로 세분화하면 일정을 만들기가 더 쉬워집니다. 또한 신뢰할 수 있는 WBS가 있으면 작업을 더 편안하게 생성하고 할당할 수 있습니다. 

마지막으로, 이러한 계층적 구조는 특히 시각적 사고를 하는 사람이라면 프로젝트 범위를 더 빨리 파악할 수 있게 해줍니다. 자신이 이에 해당하는지 잘 모르시겠어요? 다음 가이드를 확인하세요. S프로젝트 관리자를 위한 케치노트 를 통해 프로젝트 관리에서 시각적 사고의 이점을 누릴 수 있는 방법을 알아보세요.

프로젝트 수명 주기 동안 프로젝트 범위를 검증하고 제어하세요.

프로젝트 범위 명세서와 WBS가 있으므로 프로젝트에 무엇이 포함되어야 하는지 알 수 있습니다. 이제 이해 관계자가 범위를 확인하고 서명해야 합니다. 모호한 부분이 없는지 검토하고 프로젝트 작업을 시작하기 전에 마무리하세요. 이렇게 하면 범위가 늘어날 가능성을 줄일 수 있습니다.

프로젝트가 진행 중일 때는 범위를 제어해야 합니다. 수행된 작업과 수행해야 할 작업을 모니터링해야 합니다. 이 과정에서 다음 도구가 유용할 수 있습니다:

 

비교 프로젝트 보고서 범위 및 프로젝트 관리 일정과 함께 타임라인, 작업량, 완료된 작업 등이 예상과 일치하는지 확인합니다.

프로젝트의 범위를 관리하는 과정은 특히 많은 준비 과정을 고려할 때 복잡해 보일 수 있습니다. 하지만 일단 시도해 보면 프로세스 초기에 작성하는 문서(범위 관리 계획 및 프로젝트 범위 명세서)가 나중에 팀이 작업 중인 제품이나 서비스를 제공하는 데 큰 도움이 된다는 것을 알게 될 것입니다.

[/vc_column_text][/vc_column][/vc_row]

프로젝트 범위 관리 프로세스를 쉽게 개선하고 싶으신가요?

관련 게시물