March 15, 2016

Project Scope Management


Edureka! upload

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)

Scope Planning or 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)
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

Scope Definition

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

Scope Verification

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

Scope Control

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

No comments:

Post a Comment