Key Concepts
1.
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).
2.
Product Scope:
a.
Features & functions that characterize a
product, service or result
b.
Assessed against the product requirements and
WBS
3.
Project Scope
a.
Work to be completed or Work performed to
deliver product, service or result with specified features & functions
4.
Scope Baseline: scope statement + WBS + WBS
dictionary
5.
WBS includes only the
deliverables/outcomes/results (not actions)
6.
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
7.
In Predictive Life Cycle – Project deliverables
are defined at the beginning of project & any changes to scope are
progressively managed (Change resistant)
8.
In Adaptive or agile approach, deliverables are
developed over multiple iterations where a detailed scope is define &
approved for each iteration when it begins (Expect Changes)
9.
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).
10.
Completion of project scope is measured against
Project Management plan.
11.
Completion of product scope is measured against
product requirements.
Tailoring Considerations
1.
Knowledge & Requirement Management: Formal /
Informal, Guidelines to establish to be reused in future
2.
Validation & Control: Formal / Informal
Validation & control related org. policies, procedures & guidelines
3.
Use of agile approach: Development approach
Iterative or incremental or predictive, hybrid
4.
Governance: Formal or informal Audit &
governance policies, procedures & guidelines
5.1 Plan Scope Management
1.
It is the Process of creating Scope Management
Plan that documents how the project & product scope will be defined,
validated & controlled. Process is performed once or predefined points in
project. It includes:
a.
how to prevent scope creep,
b.
how to handle change requests,
c.
escalation path for disagreement on scope
elements between stakeholders,
d.
processes for creating scope statement, WBS,
processing CR,
e.
how the deliverables will be accepted
2.
Key benefit is that it provides guidance &
direction on how scope will be managed throughout the project.
3.
Requirements Management Plan: how the
requirements will be managed, documented and analyzed. It includes:
a.
how to process requirements,
b.
address missed requirements,
c.
configuration management, prioritize
requirements,
d.
metrics (and rationale) for defining the
product,
e.
define the traceability structure (in RTM),
f.
authorization level for approving new
requirements
4.
[important]
the requirement management plan is the primary means to understand and
manage stakeholder expectations.
5.2 Collect Requirements
1.
It is the process of determining, documenting
& managing stakeholder needs & requirements to meet objectives.
2.
Key benefit – it provides the basis for defining
the product scope & project scope.
3.
Process is performed once or predefined points
in project.
4.
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. Categories of Requirements:
a.
Business
requirements – support business objectives of the company
b.
Stakeholder requirements
c.
Solution
requirements – functional (product behavior) and nonfunctional requirements
(reliability, security, performance, safety, etc.)
d.
Transitional
requirements : temporary capability including data
conversion/tracking/training
e.
Project
requirements : actions/processes/conditions the project needs to met
f.
Quality
requirements : quality criteria defined by stakeholders
5.
Requirements Collection Tools
a.
Data Gathering
i.
Brainstorming:
Generate & collect multiple ideas related to project / product requirements
ii.
Interviews:
Interviewing Stakeholders – one to one, one to many, many to many
iii.
Focus
groups: Moderated event, 6-12 people group, and Neutral moderator, participant
composition is important.
iv.
Questionnaires
and surveys: Large group, paper-based/ web-based, geographically dispersed
v.
Benchmarking:
comparing 2 or more system, businesses, approaches. Set an external basis
for performance. Comparing organizations for requirements.
b.
Data Analysis
i.
Document
analysis: Project plans, brochures, blueprints, specifications etc.
c.
Data Representation
i.
Affinity
Diagram: for identifying a large number of ideas by grouping similar ideas
together. Decomposition & organization of ideas & requirements.
ii.
Mind
Mapping: to generate ideas with the process of backtracking, brainstorming,
consolidate. Helps to generate new ideas
d.
Decision Making
i.
Voting: Unanimity/ Majority/ Plurality
ii.
Autocratic decision making
iii.
Multicriteria
decision making: Systematic approach of determining, ranking &
eliminating criterion – Performance metrics, Risks, Requirements. E.g. Decision
Matrix Table
e.
Interpersonal & Team Skills:
i.
Nominal Group Technique: Generates ideas &
ranking, consensus on high scoring ideas
ii.
Observation/conversation
iii.
Facilitation: Joint Application Design (JAD),
SME & dev team meet to gather rqmnt, Quality Function Rqmnt- voice of
customer. Workshop to identify prioritized characteristics for new product
development.
f.
Context Diagram – Scope model, Business system
working components (e.g. Servers, Workstations, Databases, Workflow, People)
g.
Prototypes – Throwaway, Functional,
Storyboarding
6.
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). RTMs track:
a.
Name
b.
Link to business & project objectives
c.
Project Scope & WBS entry
d.
Relevant data, coding, cost or schedule
e.
Status as active/cancelled/deferred/added/approved/assigned/completed
f.
Testing activities
g.
Comments/notes
7.
Requirement documentation needs to be
unambiguous, traceable, compete, consistent and acceptable to key stakeholders
and is approved by the customer and other stakeholders
5.3 Define Project Scope
1.
It is the process of developing a detailed
description of the project & product. Key benefit: it describes the
product, service or result boundaries & acceptance criteria. Process is
performed once or predefined points in project. The needs of project determine
which components of PMP and which project documents are necessary.
2.
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
3.
May provide alternatives if the budget and
schedule could not meet management’s expectations
4.
Product analysis includes techniques such as:
a.
Product breakdown
b.
Systems analysis
c.
Requirements analysis
d.
Systems engineering
e.
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)
f.
Value analysis
5.
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.
a.
The scope statement is usually progressively
elaborated throughout the project
5.4 Create WBS
1.
Deliverable oriented hierarchy that breaks down
(decomposition) the work to be done, created by the organization/stakeholders,
can be in an organization chart or table form, based on the project deliverables
(not tasks needed).
2.
WBS is broken down from the top. The lowest
level in the WBS is a work package (this is broken down further into schedule
activities during activity definition – Activity List)
3.
WBS is deliverables oriented, not activities
list.
4.
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)
a.
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
b.
Work packages are charges to control accounts
for cost management; are broken down enough to delegate to a staff, usually 8 –
80 hours work and different work packages can be at different levels of
decompositions
c.
WBS does not show dependencies between work
packages, but a WBS dictionary does (WBS dictionary clarifies WBS by adding
additional information)
d.
WBS includes 100% of scope (100% rule)
e.
can be a template in OPA
5.
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.
A work package can have only ONE control account
6.
Code of accounts: a numbering system to identify
WBS components
7.
Chart of accounts: a list of all account names
and numbers
a.
1.1 for the 2nd level, 1.1.1 for the 3rd level
8.
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
9.
Scope
Baseline, an output from Create WBS, includes:
a.
WBS (Work Breakdown Structure)
b.
WBS Dictionary: Includes:
i.
Code of Account identifier
ii.
Description of work
iii.
Assumptions / constraints
iv.
Responsible organization
v.
List of Schedule activities
vi.
Resources required
vii.
Cost estimates
viii.
Quality requirements
ix.
Acceptance criteria
x.
Technical references
xi.
Contract informations
c.
Scope Statement
d.
Scope Management Plan
10.
Scope Baseline is to be created by the project
team
Appreciate your response Kavi Priya, thanks!
ReplyDelete