Scope Management

Define and discuss SCOPE in the context of
Planning. What has already happened at the Planning
stage? What has been produced before we get into
the detailed stuff!

Here we need to establish the plurality of Project Management. Talk about the SCOPE of the PRODUCT and the SCOPE of the PROJECT.

Also need to talk about the need to ensure good Scope Management procedures to guard against SCOPE CREEP

Definition

The requirements of the project - what is it producing

Inputs

Project Charter

Made need to refer to an exemplar or template, look at simple charter created in assessment 1 activity 3 PM401

Stakeholder Register

We've seen this in PM401 and know what it is. From here we determine who will have the expertise/experience/authority to help with requirements gathering. This will have been developed in assessment 1 activity PM401

Tools and
Techniques

Interviews
Focus Groups
Workshops
Questionnaires
Prototyping
Observation

Method selection may depend on
project complexity
time/cost constraints
company culture (congruence)
results criteria

detail them all and get the students to
select the 'best' method relevant to the scenario

Outputs

Requirements Documentation

Matches requirement to business objective
lots of information on this. Need to edit ourselves to ensure
effectiveness

Requirements Management Plan

Follows on from the initial documentation and sets out
how requirements are managed and throughout the project

We can first mention CHANGE CONTROL here

Requirements Traceability Matrix

Links requirements to origins and traces activity throughout project. Helps to ensure that what was requested is what is delivered.

Develop the idea of CHANGE CONTROL and how

Definition

Essentially what is IN scope and what is OUT of scope

Once we have the authority to proceed via the charter then....During the PLANNING stage (project management process 5 phases) we understand more about the project and define the detail

We can first talk about understanding and analysis of
RISKS, CONSTRAINTS here

Inputs

Project Charter

Seen before in 1.0

Requirements Documentation

Seen before 1.0 as an output now becomes an input of 2.0

Now we can introduce the concept of FLOW in project planning. How the output of one process feeds into another.

Organisational Process Assets

Company policy and procedure

'Lessons learned' from previous projects

Other project assets - e.g. templates etc

Tools and
Techniques

Expert Judgement
Product Analysis
Identifying Alternatives
Workshops

Develop the idea of assumptions, constraints, risks, analysis
as part of this process

Outputs

Scope Statement

A scope statement is used to develop and confirm a common understanding of the project scope. It should include
a project justification
a brief description of the project’s products
a summary of all project deliverables
a statement of what determines project success
the exclusions, constraints and assumptions

Students are to produce a SCOPE STATEMENT as an LO

Definition

WBS is a deliverable-oriented grouping of the work involved in a project. It defines the total scope of the project and provides the basis for planning and managing project schedules, costs, and changes.

Work Packages

Inputs

Scope Statement

Produced as an outcome of 2.0
Reinforce project flow

Requirements Documentation

Seen before

Organisational Process Assets

Seen before

Tools and
Techniques

Decomposition

This is a BIG topic might need group discussion to decide what to include. Summaries, key points, detail v overview etc

Using organisation guidelines (company PMO)
The analogy approach
The top-down approach
The bottom-up approach - smallest bit and roll them up
Mind-mapping approach

Outputs

WBS

The deliverable oriented decomposed work to be done
Progressively more detail per level

Students are to produce a WBS as an LO

WBS dictionary

Describes the components of the WBS in more detail

Scope Baseline

Self explanatory

Scope statement
WBS
WBS Dictionary

Updates to 'other' Project documents

for e.g. creating the WBS may generate the need for CHANGES. If approved they may necessitate updating of project documents - requirements documentation, scope statement, etc.

Definition

The process of monitoring status of the project and product
and managing changes to the SCOPE BASELINE

Inputs

Project Management Plan (PMP
Seen before in PM401

Specific components of the PMP such as:
Scope Baseline
Scope Management Plan
Change Management Plan
Configuration Management Plan
Requirements Management Plan

Work Performance Information

Current project progress, what's underway, what's completed, how the project is tracking, what performance is being achieved (performance indicators)

Requirements Documentation

Seen before

Requirements Traceability Matrix

Seen before

Organisational Process Assets

Seen before but in this context existing control procedures, montioring and reporting methods. May be part of a PMO depending on the maturity of the organisation.
PMO seen before in PM401

Tools and
Techniques

Variance Analysis

Performance Measurements used to determine variance form Scope Baseline. Determine cause and severity and whether corrective action is required.

Outputs

Performance Measurements

Organisational Process Assets Updates

'lessons learned' other important information for future project or operational work

Change Requests

Self explanatory. Requests go through the Integrated Change Request process seen before at PM401

PMP updates

Updates to specific components of the PMP depending on nature of Scope Control activities carried out e.g. change to Scope Baseline

Updates to 'other' Project documents

as before for CHANGES
e.g. Requirements Documentation

Definition

Formalised acceptance of the deliverables.
Review with customer/sponsor to ensure
satisfaction

Inputs

Scope Baseline

Seen before as an output of 3.0

Requirements Documentation

Seen before

Requirements Traceability Matrix

Now we see how, as mentioned at 1.0, this document helps to ensure that what was requested is what is delivered.

Validated deliverables

Those deliverables having passed through the Project Quality Control process and are now ready for 'sign-off'.

Tools and
Techniques

Inspection

Measuring
Examining
Verification
against requirements and
acceptance criteria

Outputs

Accepted deliverables

Formal acceptance/'sign-off' from the customer/sponsor

Change Requests

Those deliverables not accepted and the reasons why. May result in change to requirements or change to production process.

Updates to 'other' Project documents

as before for CHANGES
also accepted deliverables will necessitate updates to the plan, risk register etc as well as status or update reports