5.1 Create different types of requirements. 5.2 Identify ...€¦ · 4 4 Chapter 5 5.1 Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS 5.5 Validate

Slide # 1©3FOLD Education Centre . All rights reserved . [email protected] . www.3foldtraining.com . PMP® Exam Review Slide # 1

A Guide to the

PROJECT MANAGEMENT

BODY OF KNOWLEDGE

(PMBOK ® GUIDE ) – Sixth edition

Chapter 5 – Project Scope Management

PMBOK is a registered mark of the Project Management Institute, Inc


Chapter 5

5.1 Create different types of requirements.5.2 Identify critical components of the scope

statement5.3 Evaluate key benefits of the scope baseline5.4 Identify scope validation and control activities

Learning Objectives

Slide # 3© 3FOLD Education Centre . All rights reserved . [email protected] . www.3foldtraining.com . PMP® Exam Review Slide # 3

*Project Scope Management. Project Scope Management includes the processes required to ensure that the project includes all the work required, and only the work required, to complete the project successfully.


Chapter 5

5.1 Plan Scope Management

5.2 Collect Requirements

5.3 Define Scope

5.4 Create WBS

5.5 Validate Scope

5.6 Control Scope

Project Scope Management


Process 5.1 Topics covered in this process

5.1 Plan Scope Management

5.1.1 Plan Scope Management: Inputs

5.1.2 Plan Scope Management: Tools and Techniques

5.1.3 Plan Scope Management: Outputs


5.1 Plan Scope Management. *The process of creating a scope management plan that documents how the project and product scope will be defined, validated, and controlled.


5.1 Plan Scope Management (ITTO)

Project Management Institute, A Guide to the Project Management Body of Knowledge, (PMBOK® Guide) – Sixth Edition, Project Management Institute Inc., 2017, Fig. 5-2, Page 134.


Inputs

The project charter is used here as an input into the Plan Scope Management processes because it contains the description of the project scope that is known at that point.

Project Charter

5.1

Pla

n S

cop

e M

anag

em

en

t: In

pu

ts

Relevance

Keep in mind that early on in the project, the project management plan, and its subsidiary plans, will be relatively ill defined.

As the project progresses and more details are known about the project and the subsidiary elements of the project, the project management plan itself will become more fleshed out. This clearly demonstrates the highly iterative nature of planning how you will manage your projectand product scope.

Project Management

Plan

1

2



Inputs

The types of enterprise environmental factors that can play a role in how you manage scope can include things such as the culture of the organization and its attention to detail, risk, and quality, and any external marketplace conditions that the project is being initiated to take advantage of.

Enterprise Environmental

Factors

5.1

Pla

n S

cop

e M

anag

em

en

t: In

pu

ts

Relevance

Once again organizational process assets play an important role as an input into a planning process. The types of organizational process assets that will be most useful in this section are any blank templates, defined policies and procedures, any historical information, lessonslearned, and any project management methodology already in place.

Organizational Process Assets

3

4



T & T

In relation to the Plan Scope Management process, the experts that you will call upon include your own expert judgment, the expert judgment of team members, and any other experts that you want to consult to help you define your particular approach to scope management.

Expert Judgment

5.1

Pla

n S

cop

e M

anag

em

en

t: T

& T

What is it?

1

Detailed Earlier.Data Analysis

2

Detailed Earlier.Meetings

3



Outputs

* A component of the project or program management plan that describes how the scope will be defined, developed, monitored, controlled, and validated.

The scope management plan is one of the more important subsidiary plans contained in the project management plan.

It outlines your particular process for iteratively defining the detail of the project and product scope, the process of decomposition for the creation of your work breakdown structure (a process that uses the scope statement that has been developed to execute project work), and the process by which any requested changes will be considered and either approved or declined.

Scope Management

Plan

5.1

Pla

n S

cop

e M

anag

em

en

t: O

utp

uts

Description

1



Outputs

* A component of the project or program management plan that describes how requirements will be analyzed, documented, and managed.

The requirements management plan is a specific plan that addresses how the product requirements will be documented, defined, tracked, and reported against. It is also in the requirements management plan that detail of the configuration management activities will be defined.

The requirements management plan will also contain methods for prioritizing the requirements, and any defined metrics to define the product.

Requirements Management

Plan

5.1

Pla

n S

cop

e M

anag

em

en

t: O

utp

uts

Description

2




5.2 Collect Requirements

5.2.1 Collect Requirements: Inputs

5.2.2 Collect Requirements: Tools and Techniques

5.2.3 Collect Requirements: Outputs


5.2 Collect Requirements. *The process of determining, documenting, and managing stakeholder needs and requirements to meet project objectives.


5 important points to know about Collect Requirements

1 The Collect Requirements process involves talking to the people who are affected by your project to find out what they need.

2 They can include technical requirements or known constraints.

3

Not all requirements may be met.4

Assess detailed project requirements, constraints, and assumptions with stakeholders based on the project charter, lessons learned from previous projects, and the use of requirement-gathering techniques (e.g., planning sessions, brainstorming, focus groups), in order to establish the project deliverables.

5

Therefore, the process of collecting requirements will involve stakeholders and documentation of what they believe the project objectives are.


5.2 Collect Requirements (ITTO)



Inputs

The project charter authorizes the project and contains any high level information about the product and project deliverable that can be used to assist the process of collecting more detailed requirements.

Project Charter

5.2

Co

llect

Re

qu

ire

me

nts

: In

pu

ts

Relevance

Scope, requirements and stakeholder engagement plan are key components to prepare requirements documentation.Project

Management Plan

1

2

Documents such as assumption log, lessons learned register, and stakeholder register are some of the key inputs.Project

Documents

3



Inputs

Detailed EarlierBusiness

Documents

5.2

Co

llect

Re

qu

ire

me

nts

: In

pu

ts

Relevance

Agreement might include project and product requirements.Agreements

4

5

Detailed EarlierEEFs & OPAs

6 & 7



T & T

Detailed Earlier.Expert Judgment

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

1

* Techniques used to collect data and information from a variety of sources. 1. Brainstorming – (discussed earlier)2. Interviews – (discussed earlier)3. Focus Groups – (discussed earlier)4. Questionnaires and Surveys – Questionnaires and surveys present a very

effective means of gathering this information from identified stakeholders.5. Benchmarking - * Benchmarking is the comparison of actual or planned

products, processes, and practices to those of comparable organizations to identify best practices, generate ideas for improvement, and provide a basis for measuring performance.

Data Gathering

2



T & T

Document analysis will be performed as part of the data analysis. The following documents can be analyzed to gather requirements, but not limited to:

1. Agreements2. Business Plans3. Polices and Procedures4. Regulatory documentations5. Business Processes

Data Analysis

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

3



T & T

* Techniques used to select a course of action from different alternatives.

Decision making techniques:1. Voting

1. Unanimity - * Agreement by everyone in the group on a single course of action.

2. Majority – more than 50% agrees – advisable to have uneven number of member in the group to avoid a tie.

3. Plurality - * Decisions made by the largest block in a group, even if a majority is not achieved.

2. Autocratic – One individual makes the decision3. Multicriteria - * This technique utilizes a decision matrix to provide a

systematic analytical approach for establishing criteria, such as risk levels, uncertainty, and valuation, to evaluate and rank many ideas.

Decision Making

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

4



T & T

* Graphic representations or other methods used to convey data and information.

Data representation techniques:

1. Affinity Diagram - * A technique that allows large numbers of ideas to be classified into groups for review and analysis.

2. Mind Mapping - * A technique used to consolidate ideas created through individual brainstorming sessions into a single map to reflect commonality and differences in understanding and to generate new ideas.

Data Representation

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

5



T & T

* Skills used to effectively lead and interact with team members and other stakeholders.

Interpersonal and Team Skills:

1. Nominal Group Technique - * A technique that enhances brainstorming with a voting process used to rank the most useful ideas for further brainstorming or for prioritization.

2. Observation/Conversation - * Observations are a very accurate way of determining how a potential project or product scope will be implemented or used in real life. Observation is also known as “job shadowing.”

3. Facilitation - Facilitated workshops provide a forum to solicit information from various stakeholders in a controlled manner. They are focused and interactive by their nature and are often facilitated by an independent party. Examples of specific types of facilitated workshops include the joint application design/development sessions (JAD) and the quality function deployment (QFD) facilitated workshops used in new product development.

Interpersonal & Team Skills

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

6



T & T

* A visual depiction of the product scope showing a business system (process, equipment, computer system, etc.), and how people and other systems (actors) interact with it.

Context Diagram

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

7



T & T

* A method of obtaining early feedback on requirements by providing a working model of the expected product before actually building it.

A prototype is generally used to evaluate a new design to enhance precision by system analysts and users.

Prototyping serves to provide specifications for a real, working system rather than a theoretical one.

Prototypes

5.2

Co

llect

Re

qu

ire

me

nts

: T &

T

What is it?

8



Outputs

* A description of how individual requirements meet the business need for the project.

The requirements documentation itself is highly iterative; you may be able to fully define certain requirements and not yet define other requirements.

When requirements are fully defined and documented, they will include a description of how the requirement meets the identified business need, objectives, or stakeholder requirements.

They will also include a traceability matrix identifying which stakeholders requested each requirement, defining acceptance criteria, and providing a link back to the business objective that the requirement is intended to meet.

Requirements Documentation

5.2

Co

llect

Re

qu

ire

me

nts

: O

utp

uts

Description

1



Outputs

* A grid that links product requirements from their origin to the deliverables that satisfy them.

The requirements traceability matrix is a valuable tool for ensuring that the documented requirements are mapped directly back to business objectives.

A requirements traceability matrix is a table that links the origins of individual product requirements to the expected deliverable that meets those requirements so that you can track requirements throughout the project life cycle.

Requirements Traceability

Matrix

5.2

Co

llect

Re

qu

ire

me

nts

: Ou

tpu

ts

Description

2




5.3 Define Scope

4.3.1 Define Scope: Inputs

4.3.2 Define Scope: Tools and Techniques

4.3.3 Define Scope: Outputs


5.3 Define Scope. *The process of developing a detailed description of the project and product.


5 important things to know about Define Scope

1 Define scope is the process where the project's requirements are more thoroughly understood and documented.

2 The importance of this process is directly related to how important the requirements are.

3 A large, mission-critical project will perform this process very thoroughly, while a smaller project, will probably be less formal and detailed.

4 This process may be started as soon as the collect requirements process has been completed.

5 This process may be revisited many times throughout the life of the project.


5.3 Define Scope



Inputs

The project charter can be used as a key input into the Define Scope process because it contains the project approvals and any known description of the project and product scope.

Project Charter

5.3

Def

ine

Sco

pe

: In

pu

ts

Relevance

Components of project management plan such as scope management plan is a key input.Project

Management Plan

1

2

Assumptions Log, Requirements Documentations and Risk Register are some examples of key documents that are required for this process.Project

Documents

3



Inputs

Detailed EarlierEnterprise

Environmental Factors

5.3

Def

ine

Sco

pe

: In

pu

ts

Relevance

Detailed EarlierOrganizational Process Assets

4

5



T & T

Detailed EarlierExpert

Judgment

5.3

Def

ine

Sco

pe

: T &

T

What is it?

1

Detailed EarlierData Analysis

2

Detailed EarlierDecision Making

3

Detailed EarlierInterpersonal

and Team Skills

4



T & T

* For projects that have a product as a deliverable, it is a tool to define scope that generally means asking questions about a product and forming answers to describe the use, characteristics, and other relevant aspects of what is going to be manufactured.

Product analysis is best used when a project is delivering a product, instead of a service or result, as its major deliverable.

Breaking the product down into its component parts and ensuring that each part meets the requirements and technical specifications assists with documenting the product scope.

Product analysis can also include value engineering processes in which you try to use innovation to deliver the product as efficiently as possible.

Product Analysis

5.3

Def

ine

Sco

pe

: T &

T

What is it?

5



Outputs

* The description of the project scope, major deliverables, assumptions, and constraints.

The project scope statement defines all the work to be done on the project, and only the work to be done on the project. It includes a detailed description of the exclusions and the work that will not be done as part of the project. The project scope statement also includes a full description of the work to be done to deliver the scope of the product.

Scope statement should include:1. Product scope description2. Deliverables3. Acceptance criteria4. Project exclusion

Project Scope Statement

5.3

Def

ine

Sco

pe

: Ou

tpu

ts

Description

1



Outputs

5.3

Def

ine

Sco

pe

: Ou

tpu

ts

Description

Project Document

Updates

2The process of defining the scope will probably require project documents updates such as updates to assumption log, requirements documentation, requirement traceability matrix and stakeholder register.



5.4 Create WBS. * The process of subdividing project deliverables and project work into smaller, more manageable components.



5.4 Create WBS

5.4.1 Create WBS: Inputs

5.4.2 Create WBS: Tools and Techniques

5.4.3 Create WBS: Outputs


5 important points to know about Create WBS

1 One way to get a clear picture of all of the work that needs to be done on a project is to create a work breakdown structure.

2 The WBS doesn’t show the order of the work packages or any dependencies between them. Its only goal is to show the work involved in creating the product.

3A WBS can be structured any way it makes the most sense to you and your project team. The two most common ways of visualizing the work are by deliverable or by phase.

4 The output of create WBS process is scope baseline which includes WBS, WBS dictionary and scope statement.

5Scope baseline is one of the 3 baselines in the project in addition to schedule and cost.


5.4 Create WBS (ITTO)



Inputs

The scope management plan is a key input because in this plan you have detailed how you will approach the process of decomposing the project scope statement and creating the workbreakdown structure (WBS).

Project Management

Plan

5.4

Cre

ate

WB

S: In

pu

ts

Relevance

The following project documents are considered necessary to create WBS.

1. Project scope statement2. Requirements Documentation

Project Documents

1

2

Detailed Earlier.EEFs and OPAs

3 & 4



T & T

* Judgment provided based upon expertise in an application area, knowledge area, discipline, industry, etc., as appropriate for the activity being performed. Such expertise may be provided by any group or person with specialized education, knowledge, skill, experience, or training.

Expert Judgment

5.4

Cre

ate

WB

S: T

& T

What is it?

1



T & T

* A technique used for dividing and subdividing the project scope and project deliverables into smaller, more manageable parts.

The process of decomposition involves taking a high-level description of the work to be done for the project and product, and successively breaking it down into deliverables, sub deliverables, and finally down to the level of work packages.

Work Package. * The work defined at the lowest level of the work breakdown structure for which cost and duration are estimated and managed.

The WBS is a graphical representation of the total project scope and, therefore, work that is not included in the WBS is not part of the project.

Decomposition

5.4

Cre

ate

WB

S: T

& T

What is it?

2



T & T

The 100% Rule

The 100% rule is a core characteristic of the WBS. This rule states that the WBS includes 100% of the work defined by the project scope and captures ALL deliverables—internal, external, and interim—in terms of work to be completed, including project management.

The rule applies at all levels within the hierarchy: the sum of the work at the ‘‘child’’ level must equal 100% of the work represented by the ‘‘parent’’ and the WBS should not include any work that falls outside the actual scope of the project, that is, it cannot include more than 100% of the work.

Decomposition

5.4

Cre

ate

WB

S: T

& T

What is it?

2



Project Management Institute, Practice Standard for WBS – Second Edition, Project Management Institute Inc., 2006, Fig. 2-2, Page 9.

ANNOTED BICYCLE WBS


Outputs

* The approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary, that can be changed using formal change control procedures and is used as a basis for comparison to actual results.

The scope baseline is what you use to measure progress against in the project. Any baselines in project management can only be changed through the formal change control process.

After an approved change is integrated into a baseline, the baseline itself is changed, thus the easiest way to think of a baseline is that a baseline is what you originally started with plus any approved changes.

Scope Baseline

5.4

Cre

ate

WB

S: O

utp

uts

Description

1



Outputs

Control Account. *A management control point where scope, budget, actual cost, and schedule are integrated and compared to earned value for performance measurement.

Planning Package. *A work breakdown structure component below the control account with known work content but without detailed schedule activities.

WBS Dictionary. *A document that provides detailed deliverable, activity, and scheduling information about each component in the work breakdown structure.

Scope Baseline

5.4

Cre

ate

WB

S: O

utp

uts

Description

1



Outputs

Assumption log and requirement documentation might be updated at the end of this process.Project

Documents Updates

5.4

Cre

ate

WB

S: O

utp

uts

Description

2



5.5 Validate Scope. The process of formalizing acceptance of the completed project deliverables.



5.5 Validate Scope

5.5.1 Validate Scope: Inputs

5.5.2 Validate Scope: Tools and Techniques

5.5.3 Validate Scope: Outputs


5 important points to know about Validate Scope

1 Validate scope is the process of ensuring that the product, service, or result of the project matches the documented scope.

2 Validate scope is often performed after perform quality control.

3 Validate scope is primarily concerned with completeness, while quality control is primarily concerned with correctness.

4 Validate scope is about acceptance of the product by the project manager, the sponsor, the customers.

5It is primarily an internal process that the delivering organization performs prior to submitting the product, service, or result for validation, which involves the customer as well.


5.5 Validate Scope



Inputs

All components of project management plans are considered relevant to this process especially scope management plan, requirements management plan and scope baseline.

Project Management

Plan

5.5

Val

idat

e S

cop

e:

Inp

uts

Relevance

The following project documents are considered necessary to validate scope.1. Lessons learned register2. Quality reports3. Requirements documentation4. Requirements traceability matrix

Project Documents

1

2



Inputs

Detailed Earlier

Work Performance

Data

5.5

Val

idat

e S

cop

e:

Inp

uts

Relevance

4

* Completed project deliverables that have been checked and confirmed for correctness through the Control Quality process. Verified

Deliverables

3



T & T

* Examination of a work product to determine whether it conforms to documented standards.

Done by the customer or sponsor.

It is also known as product review, walkthroughs, to name few.

Inspection

5.5

Val

idat

e S

cop

e:

T &

T

What is it?

1

Detailed EarlierData Analysis

2



Outputs

* Products, results, or capabilities produced by a project and validated by the project customer or sponsors as meeting their specified acceptance criteria.

Accepted deliverables meet the acceptance criteria and are signed off and accepted by either the customer or the project sponsor.

Accepted deliverables are used as the key input into the Close Project or Phase process.

Accepted Deliverables

5.5

Val

idat

e S

cop

e:

Ou

tpu

ts

Description

1

Detailed Earlier

Work Performance Information

2



Outputs

The types of project documents that may be updated include requirements documentation, lessons learned register, and requirements traceability matrix.Project

Document Updates

5.5

Val

idat

e S

cop

e:

Ou

tpu

ts

Description

4

If a deliverable is not accepted due to some areas of non-compliance or non-correctness, a change request for defect repair may be generated. Change requests are a key input into the Perform Integrated Change Control process.

Change Requests

3



5.6 Control Scope. * The process of monitoring the status of the project and product scope and managing changes to the scope baseline.



5.6 Control Scope

5.6.1 Control Scope: Inputs

5.6.2 Control Scope: Tools and Techniques

5.6.3 Control Scope: Outputs


5 important points to know about Control Scope

1 Scope Creep. * The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources.

2 Scope creep is different from gold platting, the later voluntarily add additional scope to please the customer.

3 It is important not only to manage scope change requests, but also prevent unnecessary ones.

4 Control scope is an ongoing process that begins as soon as the scope baseline is created.

5Anytime the work results are known to differ from the document scope, this process should be performed, whether or not the scope change was requested.


5.6 Control Scope



Inputs

Scope, requirement change, and configuration management plan are key inputs in addition to scope baseline and performance measurement baseline.

Project Management

Plan

5.6

Co

ntr

ol S

cop

e:

Inp

uts

Relevance

The following project documents are considered necessary to control scope but not limited to:

1. Lessons learned register2. Requirements documentation3. Requirements traceability matrix

Project Documents

1

2



Inputs

Key organizational process assets that can be useful as inputs into the Control Scope process include any change control–related or scope control–related guidelines, policies, or templates, and any documented monitoring and reporting methods.

Organizational Process Assets

5.6

Co

ntr

ol S

cop

e:

Inp

uts

Relevance

4

Work performance data in this instance refers to information about change requests received or the number and type of deliverables completed.

Work Performance

Data

3



T & T

Techniques used to organize, assess, and evaluate data and information.

1. Variance Analysis - * A technique for determining the cause and degree of difference between the baseline and actual performance.

2. Trend Analysis - *An analytical technique that uses mathematical models to forecast future outcomes based on historical results.

Data Analysis

5.6

Co

ntr

ol S

cop

e:

T &

T

What is it?

1



Outputs

Work performance information as an output from this process will include information relating to the type and category of change requests received and how they may potentially affect other areas of the project.

Work Performance Information

5.6

Co

ntr

ol S

cop

e:

Ou

tpu

ts

Description

1

Change Requests

2Change requests are a result of variances detected. All change requests must be processed according to the predefined change management process.



Outputs

Elements of the project management plan that may be updated as a result of the work done during the Control Scope process include the scope management plan, scope baseline, schedule baseline, cost baseline, and performance measurement baseline.

Project Management Plan Updates

5.6

Co

ntr

ol S

cop

e:

Ou

tpu

ts

Description

2

Project Document

Updates

3As a result of performing the Control Scope process you may choose to update the lessons learned register, requirements documentation, and requirements traceability matrix to reflect new or changed information.



END OF CHAPTER 5

Next: Chapter 6 – Project Schedule Management