Project Scope Management
§
ensure the inclusion of all and only the work required to complete the project successfully
§
Product
Scope –
requirements needed to be fulfilled to create the product, assessed against the product requirements and WBS
§
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 PM plan
§
scope management to prevent scope creep (additional
requirements added without any proper control)
§
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
§
gold
plating –
additional requirements initiated by the team members to exceed expectation,
considered a subset of scope creep
§
Scope
Baseline: scope statement + WBS + WBS dictionary
§
WBS includes only the deliverables/outcomes/results (not actions)
Plan Scope Management
§
Scope Management
Plan: how the scope will be defined, validated and controlled
§
including how to prevent scope creep,
how to handle change requests, escalation
path for disagreement on scope elements between stakeholders, process 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,
§
including 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:
primary means to understand and manage stakeholder expectations
Collect Requirements
§
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
§
interviewing (expert interviewing)
§
focus
groups (with
SME and pre-qualified stakeholders)
§
facilitated workshops (QFD (Quality
Function Deployment) – capture VOC voice of customer, translate customer needs
into requirements; JAD (Joint Application Design) – facilitated workshop for IT
and knowledge workers)
§
questionnaires and surveys
§
observation (shadowing or Gemba)
§
prototypes
§
context
diagrams (diagrams
showing input/source and output, to show how people interact with the system)
§
document analysis
§
Group Creativity Techniques:
brainstorming, nominal
group technique (to
rank brainstormed ideas by voting anonymously), mind-mapping, affinity diagram (KJ method – group
ideas into larger categories based on their
similarity and give titles to each group), Delphi
technique (for
experts with widely varying opinions, all participants are anonymous,
evaluation of ideas funneled by a facilitator), Multi-criteria Decision
Analysis (with a decision matrix)
§
Group
Decisions-making Techniques: Analytic Hierarchy Process (AHP, for complex decisions, give
different weighs to factors to build an hierarchy), Voting (unanimous, majority
>50%, plurality, dictatorship)
§
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
§
project &
product scope, outlines what will be and what will NOT be included in the deliverables,
including details of risks, constraints and assumptions
§
vs
project charter which includes high-level descriptions
§
provides 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, and value analysis
§
value
engineering is
a part of the product analysis technique (Value Engineering (value
analysis, value management, value methodology) – finding alternatives to
constraints to improve product/reduce cost without sacrificing the scope)
§
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 progressively
elaborated
Create WBS
§
the
WBS must be created (if
take on a running project without WBS, stop the project 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)
§
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
§
WBS includes 100% of scope (100%
rule)
§
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
§
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
§
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)
§
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, is created by the project team
§
the work packages are broken down
enough to delegate to a staff, usu. 8 – 80 hours work
Validate Scope
§
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
§
work
performance data tells how the deliverables were created, work
performance data includes non-conformance and compliance data
§
change
requests may
be an output
§
if no formal sign off is received as
stipulated, follow the pre-defined process in PM plan, e.g. escalation to
management
§
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
§
assessing additional requirements by
the customer or proactively overlooking the
project scope
§
measure the work product against the
scope baseline to ensure the project stays on track proactively, may need
preventive, corrective actions or defect repair
§
to prevent unnecessary changes
(either internally or externally requested) to the project
§
a documented and enforced change
control process
§
the customer has the ultimate authority to change
scope while the senior management can make use of management reserves
§
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
§
work performance info – scope
variance, causes, recommended action
§
may update the inputs – requirements documentation &
requirement traceability matrix & lessons learnt in OPA
§
in general, disagreement should be resolved in favor of the customer
No comments:
Post a Comment