더 큰 프로젝트의 경우 요구 사항 추적 성 매트릭스를 만드는 것이 좋습니다. 자세히 알아보기 :

프로젝트 관리의 요구 사항 추적 성 매트릭스 (예제 + 템플릿)

프로세스 # 2 : 요구 사항을 단속하고 범위를 정의하는 방법

요구 사항은 다음과 같습니다. :

“pmbasics101.com 웹 사이트에는 이메일을 수집하고 PDF 문서를 보낼 수있는 기능이 있어야합니다.”

이 요구 사항을 충족하려면 어떻게해야합니까?

1. 메일 링 서비스 제공 업체를 선택합니다.
2. 계정을 만듭니다.
3. 이메일을 수집 할 양식을 디자인합니다.
4. 디자인 된 양식을 구현합니다.
5. 메일 링 서비스 제공 업체에서 플러그인을 설치합니다.
6. PDF 문서를 업로드합니다.
7. 양식을 활성화합니다.
8. 양식을 테스트합니다.

필요한 작업 목록 일뿐입니다. 결과물 및 작업 패키지로 올바르게 입력하면 다음과 같이됩니다.

1. 이메일 선택 -in Form
   1.1 우편 서비스 제공 업체에 대한 보고서
   1.2 승인 된 양식 디자인
   1.3 테스트 환경에 대한 옵트 인 양식
   1.4 테스트 보고서

그래서, 어떻게 한 문장 요구 사항에서 실제 업무 범위에 도달합니까?

A) 관련 경험이나 지식이있는 사람을 찾을 수 있습니다.

주주, 고객 또는 외부가 될 수 있습니다. 컨설턴트, 주제별 전문가 또는 기타 당사자.

따라서 목표는 프로젝트 팀에서 이들을 확보하거나 연락하여 의사 소통하는 것입니다. 이미 해결책이있을 수 있습니다.

그렇지 않으면 지침이나 조언을받을 수 있습니다. 광범위하게 적용 할 기본 기법입니다.

B) 제품 분석 수행

서비스 나 결과가 아닌 제품을 만들어야 할 때 적용 할 수 있습니다.

B) p>

이 기술은 제품 가치를 분해하는 데 중점을 둡니다. WBS가 스코프를 사용하는 것처럼

더 나아가 인체 공학적 및 기능적 관점에서 제품을 분석해야합니다. 그런 다음 성능 요구 사항을 준수 할 재료 또는 프로세스에 대한 결정을 내립니다.

25 제품 분석의 예

전체적으로, 목표는 실질적인 결과물을 정의하는 것입니다.

C) 대안 생성 기법 사용

이 기법은 프로젝트의 특성에 대한 전문 지식이있을 때 효과적입니다.

따라서 가장 적합한 솔루션을 찾아야합니다. 요구 조건을 충족하다. 대부분의 경우 브레인 스토밍을 사용하여 대안을 얻습니다.

목표는 무엇입니까?

프로젝트 범위에 포함되는 것과 그렇지 않은 것을 명확히 정의해야합니다.

프로세스 # 3 : PM 소프트웨어로 프로젝트 범위 관리

확실히 사용 가능한 모든 앱에서 프로젝트 범위를 추적 할 수 있습니다. 예를 들어 Google Drive, Evernote 또는 MS Word가 가능합니다.

그러나 통합 프로젝트 관리 소프트웨어를 사용하여 모든 것을 한곳에 보관하면 심각한 이점이 있습니다.

이상적으로는 귀하가 요구 사항을 프로젝트 결과물에 연결할 수 있어야합니다.

그런 다음 결과물에서 견적, 관련 위험 및 결함이있는 특정 작업으로 이동합니다.

예를 들어 Paymo를 추천 할 수 있습니다. 개인용 및 소규모 프로젝트를위한 최고의 앱 중 하나입니다. 또한 시간 추적 및 송장 발행 기능이 뛰어납니다.

프로세스 # 4 : 프로젝트 범위 제어 방법

처음에 프로젝트 범위의 100 %를 식별하는 것만으로는 충분하지 않습니다. . 그 100 %는 프로젝트 수명 동안 변경됩니다.

따라서 범위를 모니터링, 제어 및 변경할 수있는 방법이 필요합니다.

치료법은 잘 알려져 있습니다. 작업 분류 구조입니다.

음, 또한 작업량이 변경 될 때마다 프로젝트의 모든 영역에 변경 사항을 적용 할 수있는 명확한 워크 플로가 필요합니다.

그러나 이는 통합 변경 관리 프로세스의 문제입니다.

그렇다면 문제는 무엇입니까?

고품질 WBS가 필요합니다. 또한 프로젝트 범위를 설명하는 비정상적인 방법이 필요합니다. 따라서 프로젝트 범위 설명도 필요합니다. 아래에서 설명하겠습니다.

애자일 프로젝트를 진행중인 경우 명확하게 정의 된 증분 또는 반복 범위가 훨씬 더 중요합니다. 애자일이 수행해야 할 작업을 철저히 문서화하지 않아도된다고 생각하지 마십시오. Sprint 백 로그와 사용자 스토리를 깔끔하게 유지하세요. 간단한 규칙을 적용합니다. “초보자는 사용자 스토리 설명에서 수행해야하는 작업을 이해해야합니다.”

범위 유효성 검사 방법

가끔 공식적인 결과물이 이해 관계자의 기대를 충족한다는 승인을받습니다.

프로젝트 전반에 걸쳐이를 지속적으로 수행하는 것이 중요합니다.계획 중심의 프로젝트를 이끌더라도 검토를 위해 제품 증분을 제공하는 것을 막을 수는 없습니다.

왜 이것이 필요한가요?

모든 것을 얻고 싶지는 않습니다. 결국 변경 요청, 모든 결함 및 “프로젝트에 대한 사소한 변경”.

변경 사항을 프로젝트에 실제로 통합 할 기회를 잃게됩니다.

프로젝트 종료에 가까워 질수록 시간과 리소스가 더 적게 남게됩니다. 또한 이해 관계자는 범위, 일정 또는 예산에 대한 변경 협상을 덜 받게됩니다. 또한 팀에 더 많은 압력을 가하게됩니다. 필요한 것을 얻을 수 있습니다.

명백한 내용 만 명시 :

처음부터 명확하게 설명되고 승인 된 프로젝트 범위를 갖는 것이 매우 중요합니다.

결과물이 기대에 미치지 못하는 경우 수정이있을 것입니다.

수정이 변경 요청인지, 따라서 적절하게 통합되어야하는지 증명하는 것은 귀하의 책임입니다. 그렇지 않으면 결함이며, 수정해야합니다. 때로는 자신의 비용으로.

고객과 실제로 범위를 어떻게 검증합니까?

모든 프로젝트에서 Scrum과 유사한 데모 회의를 사용할 수 있습니다.

그냥 결과물에 대한 간단한 데모를 준비합니다. 현재 프로젝트 상태와 진행 상황을 설명하십시오. 그런 다음 알려진 결함과 진행중인 부품을 지적합니다.

또한 고객으로부터 피드백을 수집합니다. 나중에 정책에 필요한 지원 문서 및 보고서를 제공 할 수 있습니다.

요점 :

지속적으로 이해 관계자의 피드백을 수집합니다. 새 변경 요청 도입 조건을 협상합니다. 프로젝트 범위 기준을 최신 상태로 유지하세요.

내 프로젝트 범위 관리 템플릿 가져 오기

바퀴를 만들지 마세요! 비용이 많이들 수 있습니다.

아래 버튼을 클릭하여 빈칸 채우기 템플릿을 받으십시오. 범위 관리에 대해 알아야 할 모든 것에 대한 리소스 가이드가 함께 제공됩니다.

전체 범위가 필요한 이유 기준이 귀하의 프로젝트에 중요합니까?

일반적으로 프로젝트가 시작되고 요구 사항이 다양한 형식으로 수신됩니다.

예 : 이메일, PDF, 회의, 목업, 버그 보고서 등 .

물론 우리는 프로젝트 헌장이나 이와 유사한 것을 준비하지 않습니다. 나쁜 습관!

대부분의 경우 프로젝트에 대한 비즈니스 사례를 논의하지 않습니다.

일반적으로 작업 분류 구조를 만듭니다.

그러나 내부적으로 만 사용되며 고객에게 전달되지 않습니다. 그런 다음 작업을 활동으로 분해하고 프로젝트를 추정합니다. 상향식 추정 기법을 사용합니다.

이제 첫 번째 기대치 확인이 이루어집니다.

프로젝트에 대한 추정치를 제시합니다.

보시다시피 여기에 투명성이 부족합니다. 고객은 우리가 실제로 어떤 작업을 예상했는지 알지 못합니다.

예상치가 고객의 기대치에 가까우면 세부 사항을 파헤 치지 않을 것입니다. 이미 그 정도의 돈과 시간을 쓸 준비가되어 있기 때문입니다. 그는 소중한 시간을 낭비하고 싶지 않습니다.

진실은 다음과 같습니다.

많은 조직과 프로젝트 관리자가 비 효율성을 숨 깁니다. 이러한 침묵의 합의 뒤에 있습니다.

별도의 게시물에 대한 주제이지만 많은 문제의 근본 원인입니다.

다음에는 어떻게 되나요?

프로젝트 실행을 시작합니다! 조만간 고객이 다른 작업을 추가해달라고 요청할 것입니다.

그 후에는 확인되지 않은 작업의 일부를 찾을 수 있습니다. 나중에 품질 문제가 나타납니다. 그들은 많은 시간을 낭비 할 것입니다.

대체로, 우리는 우리가 뭔가 잘못한 것을 알아 내기 위해 배달을 맡깁니다.

그때 고객이 우리에게 자신이 잊은 것이 있고 최대한 빨리 추가해야합니다.

믿으세요. 한 번 이상 경험해보세요.

범위 기준선 정의

”범위 기준선은 승인 된 버전입니다. 공식적인 변경 제어 절차를 통해서만 변경할 수 있으며 비교 기준으로 사용되는 범위 설명, 작업 분류 구조 (WBS) 및 관련 WBS 사전에 대해 설명합니다. ” -PMBOK® 가이드

프로젝트 범위 선언문이란 무엇입니까?

프로젝트 범위 설명의 정의

프로젝트 범위 설명은 제품 및 프로젝트 범위에 대한 설명입니다.

프로젝트가 무엇을 어떻게 생산할 것인지에 대한 서면 확인으로 사용됩니다.

귀중한 프로젝트 범위 설명의 핵심은 무엇입니까?

모든 이해 관계자가 이해하는 용어와 언어를 사용해야한다고 생각합니다. 이 프로젝트 범위 기준은 주로 고객을위한 것입니다.

좋습니다. 무엇을 포함해야합니까?

프로젝트의 정당화

다음에 대한 간단한 설명입니다. 비즈니스의 요구. 때로는 한 문장이면 충분합니다. 나머지는 프로젝트 헌장에 있어야합니다.

제품 범위

생산할 제품 또는 서비스의 특성, 특성 및 기능에 대한 설명입니다.

여러 이해 관계자로부터 요구 사항을 수집했습니다. 따라서 그들 모두가 각 요구 사항을 추적한다고 가정하지 마십시오. 또한 요구 사항을 제공하는 데 얼마나 많은 작업이 필요한지 항상 명확하지 않습니다.

주요 이해 관계자의 기대치를 조정하는 주요 장소입니다.

양과 복잡성을 보여 주어야합니다. 다른 요구 사항을 충족하는 데 필요한 작업의. 따라서이 섹션에 최대한 노력하십시오.

승인 기준

프로젝트 결과물을 승인하기 전에 충족해야하는 조건입니다.

다음을 포함 할 수 있습니다. 허용 수준 및 결함 수도 여기에 표시됩니다.

결과물

프로젝트에서 생성 할 모든 결과물에 대한 설명입니다.

제품 또는 서비스, 프로젝트 문서, 제품 설명서, 제품에 대한 교육 자료 등.

프로젝트 제외

여기에서 프로젝트 범위를 벗어나는 항목을 지정해야합니다.

아주 자주 이해 관계자 중 일부는 특정한 것을 원합니다. 이해 관계자 나 고객의 다른 부분은이를 지원하지 않습니다.

따라서 충돌 상황입니다. 충돌이 해결되고 프로젝트 범위에서 항목을 제거하기로 결정되면 여기에 넣으십시오.

그에 대해 구체적이고 명확하게 설명하십시오. 향후 시간을 절약 할 수 있습니다.

첫째, 이러한 프로젝트 제외 항목을 다시 검토 할 필요가 없습니다. 이해 관계자는 나중에 프로젝트 실행 중에이를 포함하려고 할 수 있습니다.

그러나 무언가가 크게 변경되지 않는 한 제외 항목을 검토하는 데 시간을 낭비해서는 안됩니다.

둘째, 명확하게 명시되지 않는 한 누군가가 여전히 당신이 그것을 전달할 것이라고 기대합니다. 잘못된 기대치를 제공하지 마십시오. 마지막에 프로젝트를 전달하는 것이 더 쉬울 것입니다.

제약 조건

제품을 효율적으로 제공하는 데 제약이되는 모든 사항은 여기에 명시해야합니다.

가정

현재로서는 명확히 할 수없는 불확실성입니다.

계획 중에 일부를 받아 들여야합니다. 가정이 유효하지 않은 것으로 판명되는 경우 귀하는 프로젝트 계획을 수정할 권리가 있습니다.

고객은 프로젝트 범위 설명을 승인해야합니다. 사실, 이는 공식적이고 상호 합의한 것입니다.

또한 명확한 가정과 명확한 제약하에 설명 된 결과를 제공하기 위해 최선을 다하고 있음을 나타냅니다. 반면 고객은 지정된 결과를 수락하는 데 동의합니다.

프로젝트 범위를 변경할 수 없다는 의미는 아닙니다. 아니요. 변경하려면 계약을 수정해야합니다.

WBS로 프로젝트 범위 구성

WBS 모든 프로젝트에 대한 범위 기준선의 필수 부분입니다. 크든 작든. 민첩성 또는 계획 기반.

PM 기본 사항에 대한 작업 분류 구조에 대한 완전한 가이드가 이미 있습니다. 여기서 반복하지 않겠습니다.

중요하고 싶은 점은 단 하나입니다.

프로젝트 범위 설명에 설명 된 결과물은 그대로 WBS에 포함되어야합니다. 프로젝트 전체에서 결과물을 일관되게 유지하십시오.

WBS 사전에 아는 모든 것을 넣으십시오.

WBS 사전은 각 작업 패키지에 대해 수행해야하는 작업을 설명하는 문서입니다.

현대 PM으로서 작업 추적 시스템의 일부가되어야한다고 생각합니다. 대부분의 프로젝트 관리 소프트웨어는이 정보를 한 곳에 보관할 수있는 기능을 제공합니다.

따라서 별도의 문서를 작성하지 않는 것이 좋습니다. WBS 사전을 유지하는 것은 많은 작업입니다. 통합 솔루션을 찾으십시오.

WBS에 구성 요소를 지정하는 모든 정보를 포함 할 수 있습니다. 예를 들어 WBS 사전에는 다음이 포함될 수 있습니다.

• 작업 설명
• 가정 및 제약
• 책임있는 사람 또는 조직
• 이정표
• 관련 활동
• 필요한 리소스
• 예상 비용 또는 예산
• 승인 기준
• 다른 문서 참조

어떤 것이 든 귀하의 필요에 맞고 WBS를 다른 프로세스에 통합하는 데 도움이됩니다.

결론

“항구가 어디에 있는지 모르는 선원에게 적합한 바람은 없습니다.”

무엇을해야하는지 모른 채 프로젝트를 성공적인 결과로 이끌 수 없습니다.

다시 한 번 그 점을 강조하고 싶습니다.

Agile 환경에 있고 전체 프로젝트에 대해 범위가 명확하게 정의되어 있지 않지만 프로젝트 범위를 정의, 관리, 추적 및 변경하는 방법을 계획해야합니다.

둘 다 반복 수준에 대해 및 최종 프로젝트 결과입니다.

또한 다음을 읽어 보시기 바랍니다.

• 특집 기사 : 경험없이 IT 프로젝트 관리자가되는 방법
• 시리즈 : 강력한 작업 분류 구조를 만드는 방법에 대한 궁극적 인 가이드
• 이 시리즈의 이전 : 프로젝트 관리의 요구 사항 추적 성 매트릭스 (예 : 앰플 + 템플릿)