프로젝트 범위 관리 : 우리는 무엇을 만들고 있습니까?

처음에 목표 (범위)를 명확하게 정의하여 프로젝트 성공을위한 준비를하십시오.

Pixabay로부터 입수 된 David Mark 님의 이미지입니다.

프로젝트 재해 방지

이 기사는 매우 큰 주제 인 프로젝트 범위 관리에 대한 개요입니다. 실제로 범위 관리에 대한 책 전체가 작성되었습니다. 이 개요는 프로젝트 성공에 중요한 범위 관리에 대한 추가 연구 방향을 제시 할 수 있습니다.

범위 관리는 프로젝트 성공에 매우 중요합니다.

대부분의 프로젝트는 여러 가지 이유로 실패합니다. 하지만 정말 비참한 프로젝트 실패는 범위 관리의 실패입니다. 범위는 프로젝트의 목적과 목표에 대한 정의입니다. 따라서 그것이 잘못 정의 된 경우, 우리는 아무것도 얻지 못하거나 (목표가 전달되지 않음) 원하는 것을 수행하지 않는 결과를 얻거나, 함께 작동하지 않는 두 부분을 얻습니다. 프로젝트 팀은 하나의 아이디어를 갖고 나머지 절반은 다른 아이디어를 가지고있었습니다. 당나귀의 앞부분과 말의 뒷부분을 전달하여 마치 말의 뒷부분처럼 보입니다.

스코프 크리프 방지

제품과 그 목적이 처음에 잘 정의되어 있더라도 고객은 새로운 아이디어를 얻고 점점 더 많은 것을 기대하는 악명 높은 습관을 가지고 있습니다. 우리가 그들을 무시하면 그들은 꿈을 꾸기 시작하고 우리가 그들의 꿈을 이루기를 기대합니다. 우리가 약속 한 것을-그들이 꿈꾸던 것보다 훨씬 적게--그들은 만족하지 않을 것입니다. 그들이 요청한 것을 정확히 제공해도 상관 없습니다. 사람들은 그들이 기대 하는 것을 얻지 못하면 화가납니다 . 더 나쁜 것은 우리가 그들의 말을 듣게되면 그들이 요청하는 기능을 계속 추가한다는 것입니다. 그러나 그것은 원래의 일정보다 훨씬 더 오래 걸리고 원래 예산보다 훨씬 더 많은 돈이 걸립니다.

그 결과 프로젝트가 끝날 때 제공 할 것이 없습니다. 고객은 시간과 돈이 부족하며 모든 작업에 대해 보여줄 유용한 정보가 없습니다. 우리는 이것을 몬스터 스코프 크립 이라고 부릅니다. 즉, 처음에 범위를 정의했지만 점점 더 많은 기능, 점점 더 많은 종소리가 범위에 들어 와서 자체 무게에서 무너질 때까지 프로젝트 계획에 추가되었습니다.

Project Management Institute에 따르면 모든 프로젝트의 64 %가 원래 일정과 예산에 만족하지 못합니다. 그리고 이러한 실패의 가장 큰 원인은 잘못된 범위 정의입니다. 또는 처음에 범위를 잘 정의한 경우 범위가 확장됩니다.

좋은 소식은 범위를 명확하게 정의하고 범위 크립을 관리하면 성공으로가는 길입니다!

저는 4,000 명 이상의 프로젝트 관리자를 교육하고 수십 개의 프로젝트를 이끌었습니다. 프로젝트가 압도 당하기 전에 범위를 정의하고 범위 크립을 관리하는 방법을 보여 드리겠습니다!

추가 종소리와 휘파람에 대한 요청이 설탕 큐브의 개미처럼 프로젝트를 압도합니까? 범위 크리프를 관리하는 방법을 알아 보려면 계속 읽으십시오.

stevendepolo Steven Depolo (CC BY), Flickr 경유

다음 주 화요일은 언제입니까?

범위 정의와 의사 소통의 명확성에 대해 수업을 가르 칠 때마다이 질문에 대한 실습을 요청합니다. 목요일에 가르친다 고 해. "다음 주 화요일이 지금부터 5 일 후라고 생각하시면 손 들어보세요." 방에있는 사람들의 약 절반이 손을 들었습니다. 그런 다음 "다음 화요일이 지금부터 12 일 후라고 생각하면 손을 들어보세요." 방에있는 나머지 절반은 손을 들었다.

이것은 평범한 영어가 정확한 언어가 아님을 보여줍니다. 어떤 사람들에게는 "다음 화요일"이 5 일 뒤에 오는 것입니다. 다른 사람들의 경우 "다음 화요일"은 "이번 화요일"이후이므로 12 일 남았습니다.

학생들이 어떤 방식으로 생각하든 교실에있는 사람들의 절반이 다르게 생각하는 것을 보면 명확하고 정확한 서면 정의의 가치를 깨닫기 시작합니다. 이러한 정의는 값 비싼 오해를 제거하고 고객을 실망시키는 실수를 방지하는 데 큰 도움이됩니다.

프로젝트 범위에 동의

고객, 팀 및 모든 이해 관계자와 협력하여 프로젝트의 결과물과 기능 및 목적에 동의하는 것은 쉽지 않습니다. 예를 들어 회사 웹 사이트는 다음과 같습니다.

고위 경영진에 따르면 기업 이미지의 표현
기업 고문에 따르면 법적 책임에 대한 노출 원
마케팅 부서에 따르면 새로운 수익을 창출하는 도구
재무에 따르면 유지해야 할 또 다른 비용 항목
인적 자원에 따르면 일부 채용 문제를 해결하고 좋은 유망 직원을 확보 할 수있는 기회
IT 부서에 따르면 유지 보수 작업
웹 개발 팀에 따르면 완료 할 프로젝트

여기서 핵심은 모든 사람이 옳다 는 것입니다. 성공적인 범위 관리는 모든 사람의 관점을 이해하고, 그들이 필요로하는 것과 그들이 제공해야하는 것을 확인하고, 모든 것을 하나의 계획과 하나의 정의에 집어 넣을 수 있어야합니다.

같은 페이지에

프로젝트의 영향을받는 모든 사람은 자신의 관점과 자신의 언어를 가지고 있습니다. 경영진의 "기업 이미지"가 마케팅의 "효과적인 랜딩 페이지"와 IT 부서의 "no 404 Page Not Found"메시지로 어떻게 변환됩니까? 아키텍처는 여러보기, 여러 관점 및 여러 언어로 한 가지를 볼 수있는 기능입니다. 프로젝트 관리자로서 우리는 모든 관점에서 프로젝트를보고 모든 문제를 해결할 수있는 건축가 여야합니다.

프로젝트의 초기 정의 인 범위 설명을 종합 할 때 모든 사람이 목적과 목표를 이해하도록해야합니다. 그들은 같은 것에 대해 다른 용어를 가질 수 있습니다. 괜찮아요. 하지만 두 사람이 완전히 다른 사진을 가지고 있다면 문제가 있습니다. 그리고 우리는 그것에 대해 모호 할 수 없습니다. 우리는 "우리는 회색 포유류를 만들고있다"고 선언 할 수 없으며, 기업 팀이 코끼리를 기대하도록 할 수는 없지만 최고 재무 책임자는 마우스 비용 만 지불하기로 동의했습니다.

범위에 동의

일단 우리가 같은 페이지에 들어가면 우리는 각 이해 관계자와 협력하여 우리가 무엇을, 왜 만들고 있는지 정의합니다. 우리는 여전히 여기에서 높은 수준에서 활동하고 있습니다. 그러나 우리는 우리가 만들고있는 것을 명확히하고, 정의하고, 더 좋고 더 나은 그림을 얻고 있습니다.

가정을 명확히하기

위에서 말했듯이 고객은 기대하는 것을 얻지 못할 때 만족하지 않습니다. 그들의 기대를 이해하고 관리하기 위해 프로젝트 범위 설명을 모호하고 평이한 영어 용어로 남겨 둘 수 없습니다. 엔지니어링 정밀도로 정의되어야하며 일반 언어로도 설명되어야합니다. 또한 다이어그램을 사용하고 가능한 경우 모형과 프로토 타입을 개발하여 고객과 이해 관계자가 실제로 얻을 수있는 내용을 보거나 사진을 볼 수 있도록 도와줍니다. 정확한 언어의 중요성에 대해서는 다음 주 화요일이 언제입니까? 사이드 바를 참조하십시오 .

범위 관리의 단계

프로젝트 관리 연구소는 범위 관리를 구성하는 네 가지 프로세스를 정의합니다.

범위 계획 은이 특정 프로젝트에 대한 범위 관리 계획을 세우고 있습니다. 프로젝트가 서로 상당히 유사하다면 모든 프로젝트에 대해 한 번만 수행되며 표준 방법론을 따릅니다.
범위 정의 는 본 프로젝트의 성격, 기능 및 목적을 포함하여 우리가이 프로젝트에서 만들고있는 내용에 대한 첫 번째 진술을 작성하는 프로세스입니다. 결과 범위 정의 선언문은 전체 프로젝트를 계획하는 핵심 개념입니다.
WBS (Work Breakdown Structuring)는 우리가 만들고있는 모든 세부 사항을 정의하고 프로젝트 범위에 대한 완전하고 정확한 정의를 만드는 프로세스입니다.

PMI는 높은 수준의 범위 정의를 먼저 만들고 나중에 자세한 WBS를 만들기위한 멋진 이름을 제공합니다. 그들은 그것을 점진적 정교화라고 부릅니다.

프로젝트의 나머지 부분을 정의하는 질문

명확한 범위 정의는 프로젝트의 다른 모든 측면을 계획하고 정의하는 데 필수적입니다. 프로젝트 관리의 다른 8 개 영역에 대한 적절한 정의는 견고하고 명확한 범위 정의에 달려 있습니다. 프로젝트 관리의 9 가지 영역에 대해 명확하지 않은 경우 프로젝트 관리의 9 가지 영역과 중요한 이유를 읽어보십시오.

포함 및 제외

범위를 정의하고 범위 이동을 방지하기위한 훌륭한 도구는 우리가 만들고있는 것의 정의, 즉 포함 목록과 우리가 만들고 있지 않은 것을 사람들이 요청한 목록, 즉 목록을 모두 포함하는 것입니다. 의 제외. 이렇게하는 데는 두 가지 이유가 있습니다.

우선, 사람들은 "아니오"라고 말하더라도 원하는 것을 얻을 수 있다는 것을 기억하는 경향이 있습니다. 우리는 우리가 동의 한 것을 적어 그들에게 보여주고 서명하게함으로써 인간의 자연스러운 경향을 관리 할 수 있습니다. 그런 다음 프로젝트 후반에 그들이 요청한 것을 기억하고 얻을 것이라고 생각할 때, 우리는 그들에게 보여줄 수 있습니다. 미안합니다. 아니오, 우리가 만드는 것에 대한 동의는 항상 범위에서 제외되었습니다.

예를 들어, 제가 플로리다 남부에있는 회사의 웹 사이트를 구축하고 있다고 가정 해 보겠습니다. 여기에는 영어, 스페인어, 아이티 크리올 어의 세 가지 인기 언어가 있습니다. 초기 범위 정의 과정에서 사이트가 영어와 스페인어로 제공된다는 데 동의하지만, 현재 아이티 크리올 어로 번역하는 것은 비용 효율적이지 않습니다. 우리는 "이 웹 사이트는 올해 아이티 크리올 어로 번역되지 않을 것입니다. 크리올 커뮤니티의 수요가 증가하면 내년에이 비용이 저렴할 수 있습니다."라고 적습니다.

그런 다음 사이트를 테스트 할 때 관리자가 와서 "크리올 사이트를 읽을 수 없습니다. 어떻게 되었습니까?"라고 말합니다. 범위 설명을 가져 와서 현재 Creole이 제외되었음을 보여줍니다.

두 번째 이유는 단순히 명확성을위한 것입니다. 제외를 정의하면 우리가하는 일에 대한 명확성이 높아지고 프로젝트 후반에 범위 크립을 관리 할 수있는 도구가 제공됩니다. 예를 들어, 범위 설명에서 웹 사이트의 목적 중 하나가 "고객 지원 향상"이라고 가정합니다. 그 일환으로 누군가가 온라인 채팅을 제안했지만 우리는하지 않기로 결정했습니다. 제외 목록에 "온라인 채팅"을 적지 않으면 나중에 누군가 다시 제안 할 수 있습니다. 하지만 적어두면 모든 사람이 분명합니다. 우리는 온라인 채팅을 구현하지 않습니다. 이렇게하면 동일한 토론을 반복하는 데 많은 시간을 절약 할 수 있습니다.

작업 분류 구조 (WBS) 생성

작업 분류 구조화는 모든 이해 관계자가 범위 설명을 승인 할 때 시작됩니다. 모든 프로젝트 구성 요소의 매우 신중하고 상세한 계층 적 목록을 만드는 프로세스입니다.

예를 들어, 우리가 비행기를 만들고 있다고 가정 해 봅시다. 초기 설명은 다음과 같습니다.

하나의 동체
조종석 1 개
한 오두막
두 날개
하나의 테일 어셈블리
비행 제어
탐색 및 기타 목적을위한 전자 장치

각 주요 구성 요소는 더 작은 구성 요소 목록의 제목이됩니다. 날개에는 다음이 포함됩니다.

날개 몸
연료 탱크
연료 라인
플랩

궁극적으로 이것은 전체 부품 목록에 자세히 설명되어 있습니다. 상업용 제트기의 경우 100 만 개 이상의 부품이 될 수 있습니다!

나머지 프로젝트 계획 작성

WBS가 있으면 나머지 세부 프로젝트 계획을 만들 수 있습니다. 정확한 시간과 비용을 추정 할 수 있습니다. 프로젝트 관리의 다른 6 개 영역 인 품질, 위험, 인적 자원, 커뮤니케이션, 조달 및 통합을 관리하기위한 계획을 완료 할 수 있습니다.

예를 들어, WBS는 목록입니다 무엇을 우리가하고 있습니다. 그로부터 우리는 각 구성 요소를 어떻게 만들 것인지 묻습니다. 그러면 시간 추정의 핵심 구성 요소 인 활동 목록이 생성됩니다. 또한 우리가 무엇을 만들고 있는지 알 때 "무엇이 잘못 될 수 있습니까?"라고 물을 수 있습니다. 이것이 위험 계획의 시작점입니다. 그리고 "무엇이 좋을까요?"라고 묻습니다. 품질 계획의 시작입니다.

프로젝트 중 범위 관리

WBS가 승인되면 나머지 프로젝트 계획을 완료합니다. 전체 계획이 승인되면 작업을 시작합니다. 이제 우리의 임무는 프로젝트를 완료하는 것입니다. 또는 프로젝트 관리 측면에서 어떤 일이 발생하더라도 예산 내에서 적절한 품질로 지정된 범위를 제공 할 것입니다.

이렇게하려면 실행 이라고하는 작업이 필요합니다 . 그러나 필요한 경우 해당 작업을 추적하고 과정을 수정해야합니다. 이를 추적 및 제어라고합니다. 고속도로를 운전하는 것과 같습니다. 운전 만하면 출구를 놓치고 늦게됩니다. 아니면 너무 느려서 늦거나 속도를 내고 티켓을받을 수 있습니다. 잘 운전하려면 우리가 어디에 있는지, 얼마나 빨리 가고 있는지, 주유소가 부족한지, 다른 운전자들이 도로에서 무엇을하고 있는지 관찰해야합니다. 프로젝트에서도 마찬가지입니다. 획득 가치 분석, 범위 크립 관리, 프로젝트의 9 개 영역 모두를 관리하여이를 달성합니다.

획득 가치 분석

획득 가치 분석 (EVA)은 범위, 시간 및 비용 추적으로 시작됩니다. 평이한 영어: 우리는 무엇을 완료했고, 얼마나 많은 시간이 걸렸으며, 얼마나 많은 돈을 썼습니까? 그 수치를 얻은 후에는 몇 가지 방정식을 사용합니다. 방정식은 비례 적입니다. 그들은 소비 한 시간과 소비 한 돈과 관련하여 우리가 완료 한 범위를 묻습니다. 이러한 결과는 다음과 같은 질문에 답합니다.이 속도로 계속 진행하면 시간과 돈이 다 떨어지기 전에 끝낼까요? 그렇다면 모두 좋습니다. 그렇지 않다면 왜 우리가 느리게 달리고 있거나 너무 많은 돈을 지출하는지 파악하고 문제를 해결해야합니다.

스코프 크리프 관리

획득 가치 분석은 지정된 범위 인 약속 된 목표의 진행 상황을 측정합니다. 하지만 고객이 좋은 아이디어를 얻고 프로젝트에 추가하기를 원하면 어떻게해야할까요? 어떤 엔지니어가 더 나은 기능의 생각, 그리고 만약 그가 이 추가 원한다? 일부 고위 경영진이 그만두고 새로운 상사로 교체되어 완전히 다른 것을 원하면 어떨까요?

이러한 문제는 항상 발생합니다. 위에서 말했듯이 범위 크립은 인간의 본성에서 발생합니다. 우리가해야 할 일은이를인지하고 프로젝트에 제안 된 변경 사항이 가정, 기능 또는 요구가되기 전에 해결하는 것입니다.

요컨대, 누구도 골대를 움직이지 못하게하십시오. 누군가 범위를 변경하려는 경우 프로젝트 변경 비용과 소요되는 추가 시간을 계산합니다. 우리는 변경을 선호하지 않지만 프로젝트가 마감 및 추가 자금의 확장을 받으면 우리는 우리가 제공 할 수 있도록 범위를 변경합니다: 그럼 우리가 협상 새 , 증가 보다 지정된보다 범위를, 그리고 따라서 예산이 책정되거나 일정에 명시된 것보다 더 많습니다.

평이한 영어: 더 많은 것을 원하면 더 오래 걸리고 더 많은 비용이들 것입니다. 이를 범위, 시간 및 비용의 철 삼각형이라고합니다.

9 개 영역 모두 관리

프로젝트 결과를 제공하고 고객을 만족시키기 위해 할 수있는 일이 한 가지 더 있습니다. 위에서 말한 내용에 주목하여 "어떤 일이 발생하더라도 허용 가능한 품질로"결과를 제공하십시오. 이것은 우리가 범위, 시간, 비용 이상의 것을 관리해야한다는 사실을 지적합니다. 프로젝트 전반에 걸쳐 프로젝트 관리의 9 개 영역을 처음부터 끝까지 모두 관리하는 것이 중요합니다. 프로젝트 품질 관리는 수용 가능하거나 우수한 결과를 보장합니다. 프로젝트 위험 관리는 어떤 일이 발생하더라도 성공을 보장합니다. 9 개 영역 모두에 대한 설명과 그 중요성에 대해서는 프로젝트 관리의 9 개 영역과 중요한 이유를 참조하십시오.

약속 한 것을 전달

범위 명세서에서 정의한 제품, 서비스 또는 결과를 구축하기위한 프로젝트를 계속 진행한다면, 돈과 시간이 다 떨어지기 하루 전날 우리가 제공 할 준비가 되었으면합니다.

또는 배송 할 준비가되었다고 생각합니다. 그러나 우리는 정말로 확신합니까? 그리고 고객은 어떻게 생각합니까? 고객에게 올바른 제품을 제공하고 잘 마무리 할 수 있도록 우리가 따르는 단계를 살펴 보겠습니다.

확인 및 검증

검증은 프로젝트 내부 프로세스로, 범위 설명, WBS 및 기타 관련 문서에 대해 생성 한 내용을 확인합니다. 우리는 최선을 다해 우리가 한 일이 모든 고객 요구 사항을 충족하거나 능가하도록 보장합니다. 또한 프로젝트 범위 변경을 승인 한 경우 결과물에도 해당 변경 사항이 포함됩니다. 간단히 말해서, 우리는 계획에 전달할 내용을 비교하고 모든 것이 잘 진행되는지 확인합니다. 단지 아니라는 것을 중요 것은 우리가 제공하고 있습니다. 우리가 제공하는 것이 무엇이든 고객을 위해 작동 해야합니다. 즉, 물리적 요구 사항뿐 아니라 기능적 요구 사항도 충족 해야합니다. 따라서 배송하기 전에 "여기 있습니다. 작동합니다!"라고 말할 수 있기를 원합니다.

하지만 고객이 동의할까요? 이 질문에 대한 답변은 유효성 검사 프로세스를 통해 이루어집니다. 우리는 스스로 검증을 할 수 없습니다. 일반적으로 고객이 프로젝트 결과를 확인하고 전달을 승인 할 때 수행합니다. 그러나 다른 두 가지 가능성이 있습니다.

크거나 복잡하거나 까다로운 요구 사항을 충족해야하는 제품을 제공하는 경우 배송 날짜 이전에 유효성 검사를 준비하는 것이 좋습니다. 이를 통해 프로젝트 팀은 고객 요구 사항을 충족하지 않는 항목을 조정하거나 수정할 수 있습니다.
프로젝트가 고객이 등록한 결과를 제공하는지 여부에 대해 분쟁이있는 경우, 외부 계약자가 들어 와서 우리가 제공하는 것과 고객 사이의 차이를 정의하는 독립 검증 및 검증 (IV & V)을 요청할 수 있습니다. 원하고 해결책을 추천합니다.

배달

그러나 일반적으로 IV & V는 필요하지 않습니다. 프로젝트 범위 설명에 포함되었는지 여부에 따라 설치, 설정 및 교육이 포함될 수있는 프로젝트 결과를 제공합니다. 고객은 말하자면 타이어를 차고 만족하거나 약간의 변경을 요청합니다. 그리고 프로젝트가 거의 완료되었습니다.

고객 기쁨

우리의 마지막 단계에는 모든 사람이 급여를 받고 계약서에 서명하는 것이 포함됩니다. 또한 고객 서비스를위한 회의도 포함되어야합니다. 프로젝트의 끝은 고객과의 길고 건전한 관계의 시작이 될 수 있습니다.