Project Scope Management
§
The
project manager would need to ensure the inclusion of all
and only the work required to complete the project successfully
(to achieve project objectives to deliver business values).
§
The
primary aim of scope management to define the exact scope of work and to
prevent scope creep (additional requirements added without
any proper control) or gold-plating (added
by the project team with a view to impressing stakeholders).
§
Product
Scope –
requirements needed to be fulfilled to create the product, assessed against
the product requirements and WBS
§
Scope
Baseline: scope
statement + WBS + WBS dictionary
§
WBS
includes only the deliverables/outcomes/results (not
actions)
§
Project
Scope –
activities and processes needed to be
performed to deliver the product scope, assessed against the scope baseline
(scope statement, WBS and WBS dictionary), e.g. including testing & quality
assurance, assessed against the Project Management Plan
§
The
completion of project scope is measured against the project management plan
whereas the completion of product scope is measured against the product
requirements/WBS
Plan Scope Management
§
Inputs: Project Charter, Project
Management Plan, EEF, OPA
§
Tools
& Techniques: Expert Judgement, Data Analysis, Meetings
§
Outputs: Scope Management Plan, Requirements
Management Plan
§
Scope Management
Plan (will form part of the Project Management Plan): how the
scope will be defined, validated and controlled
§
includes
how to prevent scope creep, how to handle change requests,
escalation path for disagreement on scope elements between stakeholders, processes
for creating scope statement, WBS, processing CR, how the deliverables will be
accepted
§
Requirements Management
Plan: how the requirements will be managed, documented and
analyzed
§
includes
how to process requirements, address missed requirements, configuration
management, prioritize requirements,
metrics (and rationale) for defining the product, define the traceability
structure (in RTM), authorization level for approving new requirements
§
[important] the requirement management
plan is the primary means to understand and manage stakeholder expectations
Collect Requirements
§
Inputs: Project Charter, Project
Management Plan, Project Documents, Business Documents, Agreements, EEF, OPA
§
Tools
& Techniques: Expert Judgement, Data Gathering, Data Analysis, Decision Making, Data
Representation, Interpersonal and Team Skills, Content Diagram, Prototypes
§
Outputs: Requirements Documentation,
Requirements Traceability Matrix
§
Requirement: a condition/capability that must
be met /possessed by a deliverable to satisfy a contract/standard/etc.,
including quantified/documented needs, wants, expectation of the
sponsor/stakeholder/customer
§
Business
requirements – support business objectives of the company
§
Stakeholder
requirements
§
Solution
requirements – functional (product behavior) and nonfunctional requirements (reliability, security,
performance, safety, etc.)
§
Transitional
requirements : temporary capability including
data conversion/tracking/training
§
Project
requirements : actions/processes/conditions the project needs to met
§
Quality
requirements : quality criteria defined by stakeholders
§
Requirements
Collection Tools
§
Data
Gathering
§
Brainstorming
§
Interviews
§
Focus
groups
§
Questionnaires
and surveys
§
Benchmarking
§
Data
Analysis
§
Document
analysis
§
Data
Representation
§
Affinity
Diagram: for
identifying a large number of ideas by grouping similar ideas together
§
Mind
Mapping: to
generate ideas with the process of backtracking
§
Requirements
Traceability Matrix tracks requirements from origins to deliverables,
including source of requirements and completion status, effective to prevent
gold plating (also work with work authorization system)
§
Requirement
documentation needs
to be unambiguous, traceable, compete, consistent and acceptable to key
stakeholders and is approved by the customer and other stakeholders
Define Scope
§
Inputs: Project Charter, Project
Management Plan, Project Documents, EEF, OPA
§
Tools
& Techniques: Expert Judgement, Data Analysis, Decision Making, Interpersonal and Team
Skills, Product Analysis
§
Outputs: Project Scope Statement, Project Documents Updates
§
to define
both the project & product scope in details, outlines
what WILL and what WILL NOT be included
in the deliverables, including details of constraints and assumptions
§
vs
project charter which
includes only high-level descriptions
§
may
provide alternatives if the budget and schedule could not meet management’s
expectations
§
Product
analysis includes techniques such as:
§
product
breakdown
§
systems
analysis
§
requirements
analysis
§
systems
engineering
§
value
engineering – a part of product analysis technique (Value
Engineering (value analysis, value management, value methodology) with a
view to finding alternatives to constraints to improve product/reduce cost
without sacrificing the scope)
§
value
analysis
§
Project
Scope Statement includes
objectives, (project and product) scope, requirements, boundaries,
deliverables, acceptance criteria, constraints, assumptions,
milestones, cost estimation, specifications, configuration management
requirements, approval requirements, etc.
§
the scope
statement is usually progressively elaborated throughout the project
Create WBS
§
Inputs: Project Management Plan,
Project Documents, EEF, OPA
§
Tools
& Techniques: Expert Judgement, Decomposition
§
Outputs: Scope Baseline, Project Documents Updates
§
the WBS
must be created for every project (if you take on a running project without
WBS, you must stop the project immediately and prepare the WBS first)
§
WBS is a
structured hierarchy created by the organization/stakeholders, can be in an
organization chart or table form, based on the project
deliverables (not tasks needed)
§
WBS is a
decomposition tool to break down work into lowest level manageable (time and
cost can be estimated, work package can be assigned to a team member) work
packages, e.g. by phase or major deliverables
§
the work
packages are broken down enough to delegate to a staff, usu. 8 – 80 hours work
and different work packages can be at different levels of decompositions
§
WBS does
not show dependencies between work packages, but a WBS dictionary does (WBS dictionary clarifies WBS
by adding additional information)
§
WBS
includes 100% of scope (100% rule)
§
can be a template in OPA
§
a higher
level above a work package is ‘control account‘
(control point where scope, cost and schedule are compared to earn value for
performance measurement)
§
a work
package can have only ONE control
account
§
code
of accounts: a
numbering system to identify WBS components
§
chart
of accounts: a list
of all account names and numbers
§
1.1 for
the 2nd level, 1.1.1 for the 3rd level
§
the major
deliverables should always be defined in terms of how the project will actually
be organized, for a project with phases, the
decomposition should begin with the phase first
§
Scope
Baseline, an
output from Create WBS, includes:
§
WBS (Work
Breakdown Structure)
§
WBS
Dictionary
§
Scope
Statement
§
Scope
Management Plan
§
Scope
Baseline is to be created by the project team
Validate Scope
§
Inputs: Project Management Plan,
Project Documents, Verified Deliverables,
Work Performance Data
§
Tools
& Techniques: Inspection, Decision Making
§
Outputs: Accepted Deliverables, Work Performance Information,
Change Requests, Project Documents Updates
§
the
purpose of this process is to gain formal acceptance of
deliverables from customer/stakeholders (e.g. obtain customer sign off,
requirements validations, etc.) near the end of project/phase/each
deliverable, e.g. user acceptance test
§
change
requests may
be an output as stakeholders may request changes to the deliverables
§
if no
formal sign off is received as stipulated, the Project Manager needs to follow
the pre-defined process in PM plan, e.g. escalation to management
§
work
performance data tells
how the deliverables were created, work performance data includes
non-conformance and compliance data
§
Validate
Scope is often preceded by Control Quality Process to
give the verified deliverable as input to this process, verified deliverables is fed from the control quality process
§
vs Control Quality: the process of
monitoring/recording results of executing quality activities
to assess performance and recommend necessary changes, e.g. unit testing ->
high quality vs low quality
§
need
to perform even in case of early termination/cancellation of
the project to save any usable deliverables for other projects
Control Scope
§
Inputs: Project Management Plan,
Project Documents, Work Performance Data, OPA
§
Tools
& Techniques: Data Analysis
§
Outputs: Work Performance Information,
Change Requests, Project Management Plan Updates, Project Documents Updates
§
Control
Scope is performed when assessing additional requirements by the customer or
the project manager proactively overlooking the
project scope
§
to prevent unnecessary changes (either internally or externally
requested) to the project
§
measure
the work product against the scope baseline to ensure the project stays on
track proactively, may need preventive, corrective actions or defect repair
§
a well
documented and enforced change control process is required
§
the customer has the ultimate authority to change
scope while the senior management can make use of management reserves
§
i.e. in
general, disagreement should be resolved in favour of the customer
§
Data
Analysis includes:
§
variance
analysis –
method to compare planned (baseline) and actual work and determine the
causes/actions e.g. update baseline (keep the variance) or
preventive/corrective actions, both need CR
§
trend
analysis
§
work
performance info – scope variance, causes, recommended action
§
may end
up updating some of the inputs –
requirements documentation & requirement traceability matrix & lessons
learnt in OPA
No comments:
Post a Comment