2.requirements management
-
Upload
panos-fitsilis -
Category
Business
-
view
42 -
download
0
description
Transcript of 2.requirements management
Definition
• Scope is the sum of the
– Products
– Services and
– Results
• to be provided as a project
Requirements management
The requirements problem
• The goal of project development is to develop quality products —on time and on budget—that meets customers real needs.
• Project success depends on good requirements management.
• Requirements errors are the most common type of systems development error and the most costly to fix.
• A few key skills can significantly reduce requirements errors and thus improve quality.
What is requirement?
• A requirement is a capability that the system must
deliver.
– A capability needed by the user to solve a problem to
achieve an objective
– A capability that must be met or possessed by a system
or system component to satisfy a contract, standard,
specification, or other formally imposed documentation
– A documented representation of a condition or
capability as in (1) or (2).
What is requirements management?
• Requirements management is a process of
systematically eliciting, organizing, and
documenting requirements for a complex
system.
• Our problem is to understand users‘ problems in
their culture and their language and to build
products that meet their needs.
Why we need to manage
requirements? • How many requirements has a small product?
Why we need to manage
requirements?
Common questions
• Boeing 777 has to satisfy 300,000 requirements
• The questions are: – Which project team members are responsible for the wind speed
requirement (#278), and which ones are allowed to modify it or delete it?
– If requirement #278 is modified, what other requirements will be affected?
– How can we be sure that someone has written the code in a software system to fulfill requirement #278, and which test cases in the overall test suite are intended to verify that the requirements have indeed been fulfilled?
The Life of a Requirement
Concept Phase
Business
Requirements
Need, Problem or
Opportunity
Justification
Project Charter
Funding:
Business
Requirements
Solution
Requirements
Describes the characteristics
that meet the business
and stakeholder requirements:
- Functional
- Non-Functional
- Implementation
Stakeholder
Requirements:
Needs of a
stakeholder and
their
interaction with the
system
How WHAT WHY
Requirements Phase
Problems of requirements
management
12
• Stakeholders don’t know what they really want
• Stakeholders express requirements in their own terms
• Different stakeholders may have conflicting requirements
• Organizational and political factors may influence the system requirements
• The requirements change during the analysis process. New stakeholders may emerge and the business environment change
The logical gap customer
End user contactor
Requirements processes
• Enterprise Analysis
• Requirements Planning and Management
• Requirements Elicitation
• Requirements Analysis and Documentation
• Requirements Communication
• Solution Assessment and Validation
Guide to IIB Body of Knowledge, International
Institute of Business Analysis
http://www.theiiba.org/
Requirements processes
Enterprise Analysis
• Creating and maintaining the business architecture
• Conducting feasibility studies
• Identifying new business opportunities
• Scoping and defining new business opportunities
• Preparing the business case for new business opportunities
• Conducting the initial risk assessment for new business opportunities.
17
Enterprise analysis Project
authorisation
• Projects are typically authorized as a result of one or more of the following:
– A market demand
– A business need
– A customer request
– A technological advance
– A legal requirement
– A social need
A market demand (e.g., a car company authorizes a project to build more fuel efficient cars in response to gasoline shortages).
A business need (e.g., a training company authorizes a project to create a new course to increase its revenues).
A customer request (e.g., an electric utility authorizes a project to build a new substation to serve a new industrial park).
A technological advance (e.g., an electronics firm authorizes a new project to develop a video game player after advances in computer memory).
A legal requirement (e.g., a paint manufacturer authorizes a project to establish guidelines for the handling of toxic materials).
A social need (e.g., a nongovernmental organization in a developing country authorizes a project to provide potable water systems, latrines, and sanitation education to low-income communities suffering from high rates of cholera).
18
Project authorisation examples
05 20
CONCEPTION
FEASIBILITY
IMPLEMENTATION
OPERATION
TERMINATION
Define the Project
Design the Project Process
Deliver the Project
05 21
Evaluation of
the Brief
Development
of a range of
options
Definition of
the product or
service
Broad brush
analysis filters
numbers of
options
Project Teams Actions
Simplistic Feasibility studies to
determine range of possibilities
Organisations
mission
Organisations
strategy
Organisations
goals &
objectives
Organisations
need to grow
or survive
Concept of a
new product
or service
Product or
new service
brief
Organisations Actions
Revision
05 22
Evaluation of
the Brief
Development
of a range of
options
Definition of
the product or
service
Broad brush
analysis filters
numbers of
options
Project Teams Actions
Simplistic Feasibility studies
to determine range of
possibilities
Organisations
mission
Organisations
strategy
Organisations
goals &
objectives
Organisations
need to grow
or survive
Concept of a
new product
or service
Product or
new service
brief
Organisations Actions
Revision
Project Authorisation
gateway
05 23
Reminder
• The PM role is to convert or break down the sponsors project brief into a form that everyone understands. OR - From concept into realism.
• Then to allocate resources (teams) to determine if it is possible produce what is needed, if it is feasible and if reality can be achieved within the projects budget costs at the desired level of quality.
Generating Scenarios for Feasibility Evaluation
24
A project scenario is a brief description of a proposal, process or a set of procedures that should meet the identified objectives shown in the brief.
For every objective there are a number of possible strategies: e.g. the objective of eating can be met by the preparation of food, BUT, there are a number ways to do this, each is an option.
Developing scenarios can be a brainstorming activity, then each idea generated undergoes critical examination & modification. Then, selected or reject.
25
Feasibility Analysis
Options can be evaluated and scored by using
STEEP factors.
S =
T =
E =
E =
P =
Social
Technological
Ecological
Economic
Political
26
Feasibility Analysis
1. Technical Feasibility;
2. Financial Feasibility;
3. Risk & Uncertainty Feasibility.
4. Environmental feasibility
The most frequently used evaluates these three
key areas, BUT others might well be used!
27
Process
Project Brief Generate Scenarios
Undertake Feasibility Studies for Each Scenario
Technical Feasibility Study
Financial Feasibility Study
Risk & Uncertainty Feasibility Study
Collate Results
and Select Best
Scenario by
Weighted Analysis
Comprising of:
28
Project Brief
Generate Scenarios
Feasibility Study
Technical Feasibility
Financial Feasibility
Risk & Uncertainty
Feasibility
Feasibility Study Feasibility Study
Technical Feasibility Technical Feasibility
Financial Feasibility Financial Feasibility
Risk & Uncertainty
Feasibility
Risk & Uncertainty
Feasibility
Select Best Option by Weighted Analysis
Project Brief
Generate Scenarios
Feasibility Study
Technical Feasibility
Financial Feasibility
Risk & Uncertainty
Feasibility
Feasibility Study Feasibility Study
Technical Feasibility Technical Feasibility
Financial Feasibility Financial Feasibility
Risk & Uncertainty
Feasibility
Risk & Uncertainty
Feasibility
Select Best Option by Weighted Analysis
29
Technical Feasibility
• A Technical feasibility study can only be based upon current
information concerning the product, material, or services life.
Information availability stages are:
– Fully mature – considerable data is available for evaluation of new
proposal.
– Semi-mature – limited data available to be used in feasibility study.
– New Technology – at prototype stage, limited information available.
30
2. Financial Feasibility
• Questions asked:
– Will the investment of resources in a particular
project be worthwhile, then:
– How worth-while?
• Where there is a range of several alternative
opportunities for investing resources:
– which one gives the best rewards?
31
Two Sets Finance!
• PM team have to consider:
• Development - The cost of the project to produce the product, some options will consume more resources than others, this reflects onto recovery time and product cost.
• Production -The cost to produce the project after hand-over to the sponsor (post-project).
32
3. Risk & Uncertainty Feasibility.
Risk is an inherent and characteristic of all projects, some even claim that Project Management is really Risk Management.
Essentially there are two aspects of project risk control:
Risk
Risk Management Risk Identification &
Analysis
Requirements Planning and
Management • This is necessary to ensure:
– the set of requirements activities undertaken are the most appropriate,
given the unique circumstances of the project,
– the requirements work effort is coordinated with the other work being
done for the project,
– the whole requirements team on a project has a common understanding
of what activities they are undertaking,
– business analysts are able to monitor and react to requirements challenges
and slippage,
– the tools, resources and requirements contributors are available as needed
for the requirements activities,
– and, changes are captured correctly and consistently.
Requirements Gathering
Requirements Analysis and
Documentation • Analyze functional requirements
• Analyze non functional requirements
• Process/flow models – Workflow models
– Flow charts
• Usage models – Storyboards,
– Use cases
• Requirements attributes
• Requirements traceability
Requirements quality
• Lightweight
• Availability <99%
• High quality
• Success ration 0.98
• Range >500 mL
• 100 reliable
Which of the following are valid
requirements ?
Enduring and volatile requirements
40
• Enduring requirements. Stable requirements
derived from the core activity of the customer
organization. E.g. a hospital will always have
doctors, nurses, etc.
• Volatile requirements. Requirements which
change during project or when the product is in
use. In a hospital, requirements derived from
health-care policy
Classification of Volatile
requirements
• Mutable requirements, requirements that change
due to the changing of system’s environment
• Emergent requirements, requirements that
emerge as understanding of the system develops
during the system development.
Statement
of Needs
Functional
Requirements and
Statement of Services
Detailed requirements for the
system’s functionality and constraints
as required as a basis for individual component
development/acquisition
Requirements Explosion
Declaration of
required miracle
Operational View
formulation
Detailed
requirements
10
Requirements
100
Requirements
1000 Requirements
Level of detail
Α.Cockburn, Writing Effective Use Cases
43
Requirements Communication
• Determine the appropriate requirements format
• Create a requirements package
• Conduct requirements presentation
• Conduct a formal requirements review
• Obtain consensus and signoff on the
requirements
Requirements validation
45
• Concerned with demonstrating that the requirements define the system that the customer really wants
• Requirements error costs are high so validation is very important
– Fixing a requirements error after delivery may cost up to 100 times the cost of fixing an implementation error
– Change requirement error means change system design and implementation
Requirements checking (types of checks
should be carried out on requirements)
46
• Validity. Does the system provide the functions which best support the customer’s needs?
• Consistency. Are there any requirements conflicts?
• Completeness. Are all functions required by the customer included?
• Realism. Can the requirements be implemented given available budget and technology
• Verifiability. Can the requirements be checked? In order to reduce potential dispute نزاع between customers.
Purpose of review
• The purpose of the review should be clearly stated and may encompass any of the following: – completeness of requirements (all requirements have been
captured)
– removal of superfluous requirements
– clarity of requirements (removal of ambiguity)
– correctness of requirements (the requirement reflects the business need or business rule)
– scope (the requirement fits within the stated scope of the project)
– conformance to project/organisational quality standards
– feasibility of requirements
– prioritization of requirements
Roles in review
Requirements Implementation
• Develop alternate solutions
• Evaluate technology options
• Facilitate the selection of a solution
• Ensure the usability of the solution
• Support the Quality Assurance process
• Support the implementation of the solution
• Communicate the solution impacts
Effective requirements practice
• A clear understanding of the needs of users, customers and stakeholders
• A collaborative relationship between the users, customers and stakeholders
and the technical team
• A strong commitment of the requirements development team members to
project objectives
• Use of a repeatable requirements process that is continuously improved
• A system architecture that supports the users, customers and stakeholders
current and planned needs
• The ability to accommodate changes in requirements as they are
progressively elaborated
• System development cost savings, accurate schedules, customer satisfaction
A small Example
The Project Brief
• Your only child is turning three on Saturday and
is having a big party.
• Caters are arranged but we need a clown to
entertain the guests.
• It has been suggested you have contacts in this
area.
• Arrange a clown.
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow coloured pompom.
His shoes must be large with curly green ends
and he needs a red nose, big red glasses and
brown belt with a large gold buckle and if he can
talk he must tell jokes otherwise he must be able
to juggle balls or hoops.
The Clown Requirement
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow coloured pompom.
His shoes must be large with curly green ends
and he needs a red nose, big red TRICKY
glasses and brown belt with a large gold buckle
and if he can talk he must tell jokes otherwise he
must be able to juggle balls or hoops.
The Clown Requirement
Verification
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow colored pompom. His
shoes must be large with curly green ends and
he needs a red nose, big red OPTICAL glasses
and brown belt with a large gold buckle and if he
can talk he must tell jokes otherwise he must be
able to juggle balls or hoops.
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
REQUIREMENT DOWNSTREAM DELIVERABLES
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow colored pompom. His
shoes must be large with curly green ends and
he needs a red nose, big red TRICKY glasses
and brown belt with a large gold buckle and if he
can talk he must tell jokes otherwise he must be
able to juggle balls or hoops.
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
TRACEABILITY
CHANGE IN LEGISLATION
Green ACT
All Clowns must have GREEN Noses
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow colored pompom. His
shoes must be large with curly green ends and
he needs a GREEN nose, big red TRICKY
glasses and brown belt with a large gold buckle
and if he can talk he must tell jokes otherwise he
must be able to juggle balls or hoops.
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
TRACEABILITY
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow colored pompom. His
shoes must be large with curly green ends and
he needs a GREEN nose, big red TRICKY
glasses and brown belt with a large gold buckle
and if he can talk he must tell jokes otherwise he
must be able to juggle balls or hoops.
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
TRACEABILITY
A Clown
A clown must:
Wear a bright red and white checked costume:
The clown costume must have big yellow buttons.
The clown must wear a hat:
The clowns hat must be pointy;
The end of the clowns hat must have a rainbow colored pompom.
The clowns must have shoes:
The clowns shoes must be large;
The end of the clowns shoes must be green;
The end of the clowns shoes must be curly.
The clown must have a red nose.
The clown must have big red TRICKY glasses.
The clown must have a brown belt:
The clowns belt must have a large gold buckle.
If a clown can talk the clown must tell jokes.
If a clown cannot talk the clown must be able to juggle balls or hoops.
A Clown
A clown must:
Wear a bright red and white checked costume.
The clown costume must have big yellow buttons.
The clown must wear a hat:
The clowns hat must be pointy.
The end of the clowns hat must have a rainbow colored pompom.
The clowns must have shoes:
The clowns shoes must be large;
The end of the clowns shoes must be green;
The end of the clowns shoes must be curly.
The clown must have a red nose.
The clown must have big red TRICKY glasses.
The clown must have a brown belt;
The clowns belt must have a large gold buckle.
If a clown can talk the clown must tell jokes
If a clown cannot talk the clown must be able o juggle balls or hoops
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
TRACEABILITY
A Clown
A clown must:
Wear a bright red and white checked costume.
The clown costume must have big yellow buttons.
The clown must wear a hat:
The clowns hat must be pointy.
The end of the clowns hat must have a rainbow colored pompom.
The clowns must have shoes:
The clowns shoes must be large;
The end of the clowns shoes must be green;
The end of the clowns shoes must be curly.
The clown must have a GREEN nose.
The clown must have big red TRICKY glasses.
The clown must have a brown belt;
The clowns belt must have a large gold buckle.
If a clown can talk the clown must tell jokes
If a clown cannot talk the clown must be able o juggle balls or hoops
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
TRACEABILITY
A clown must wear a bright red and white
checked costume with big yellow buttons, a
pointed hat with a rainbow colored pompom. His
shoes must be large with curly green ends and
he needs a red nose, big red TRICKY glasses
and brown belt with a large gold buckle and if he
can talk he must tell jokes otherwise he must be
able to juggle balls or hoops.
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
ORPHAN REQUIREMENT
A Clown
A clown must:
Wear a bright red and white checked costume.
The clown costume must have big yellow buttons.
The clown must wear a hat:
The clowns hat must be pointy.
The end of the clowns hat must have a rainbow colored pompom.
The clowns must have shoes:
The clowns shoes must be large;
The end of the clowns shoes must be green;
The end of the clowns shoes must be curly.
The clown must have a GREEN nose.
The clown must have big red TRICKY glasses.
The clown must have a brown belt;
The clowns belt must have a large gold buckle.
If a clown can talk the clown must tell jokes
If a clown cannot talk the clown must be able o juggle balls or hoops
Pants and
Jacket
Noses
Belts
Shoes
Hats
Bookings Transport Training
Business
Rules
pompom
TRACEABILITY
Automatic
Traceability in
DOORS
66
Requirements Prioritization
The need
• When having tens, hundreds or even thousands of
requirements alternatives, decision-making becomes
much more difficult
• One of the keys to making the right decision is to
prioritize between different alternatives. It is often not
obvious which choice is better, because several aspects
must be taken into consideration
Requirements Prioritization
• Ensures the functionality with the most value is
implemented when timelines become short
• Helps to manage competing demands
• Helps PM to manage time, cost and resources and move
lower-priority requirements to later phases, releases
TIP: “Avoid ‘decibel prioritization’, in which the loudest
voice heard get top priority, and ‘threat prioritization’, in
which stakeholders holding the most political power
always get what they demand.”
69
Approaches to Prioritization
• Ask questions: – Is there some other way to satisfy the need that this requirement
addresses?
– What would happen if this requirement isn’t implemented right away?
– How would the deferral of the requirement affect the user community?
• Use Priority Scales – High – Must be in the first release
– Medium – The business needs the functionality however can wait if necessary – can be implemented in the next release
– Low – The user can live without the functionality and it can be implemented in later releases
70
Prioritization – Value, Cost, Risk You can use a prioritization matrix.
Relative Weights: 1 1 1 1
Feature or Function (don't mix
them use either feature or
function or use case)
Relative
Benefit
Relative
Penalty
Total
Value
Value
%
Relative
Cost
Cost
%
Relati
ve
Risk
Risk
% Priority
<List each feature, requirement, or use
case to be prioritized 1 2 3 15.8 50 37.0 1 14.3 0.308
in these cells, one item per cell. Copy and
insert additional 3 1 4 21.1 22 16.3 3 42.9 0.356
rows as needed; the formulas will adjust
automatically.> 4 1 5 26.3 7 5.2 2 28.6 0.780
6 1 7 36.8 56 41.5 1 14.3 0.661
Totals 14 5 19 100.0 135 100.0 7 100.0 2.104
Source: http://www.processimpact.com/goodies.shtml
71
Prioritization on Basis of Value • Have the business estimate the benefits that each requirement provides
them (e.g. rate 1-9)
• Working with the business and I.T. estimate the penalty if the requirement
isn’t included. Assess based on quality issues, legal, compliance, function
loss that would affect productivity, harder to add capability later, other
issues such as marketing, corporate communications
• Ask the business/I.T. to weight the requirements
• Ask, is the cost a factor?
• Calculate using spreadsheet
Value%
(cost% * cost weight) + (risk % * risk weight) Priority =
Or other techniques
• Group voting
• 100 dollar method
– What you can buy with 100 dollar
– One should only perform the prioritization once on the same set of
requirements, since the stakeholders might bias their evaluation the
second time around if they do not get one of their favorite requirements
as a top priority
• Top-Ten Requirements
– In this approach, the stakeholders pick their top-ten requirements (from a
larger set) without assigning an internal order between the requirements
73
Or You Could Use …
Change management
Change management
• Any stakeholder of <project> can submit the following types of issues to the change control system:
– requests for requirements changes (additions, deletions, modifications, deferrals) in software currently under development
– reports of problems in current production
– requests for enhancements in current production systems
– requests for new development projects
Change
management
process
Submitted
Evaluated Rejected
Approved
Change Made
Verified
Closed
Verifier has confirmed the change
Modifier has installed modified work products
verification failed
Modifier has made the change and requested verification
no verification required; Modifier has installed modified work products
CCB decided to make the change
CCB decided not to make the change
Evaluator performed impact analysis
Originator submitted an issue
Canceled
change was canceled;
back out of modifications
change was canceled;
back out of modifications
change was canceled;
back out of modifications
• The CCB decided to implement the request and allocated it to a specific future product release. The CCB Chair assigns Modifier. Approved
• The Originator or someone else decided to cancel an approved change. Canceled
• The Modifier has completed implementing the requested change. Change Made
• The change made has been verified (if required), the modified work products have been installed, and the request is now completed. Closed
• The Evaluator has performed an impact analysis of the request. Evaluated
• The CCB decided not to implement the requested change. Rejected
• The Originator has submitted a new issue to the change control system. Submitted
• The Verifier has confirmed that the modifications in affected work products were made correctly. Verified
Change status severities
• Minor – Cosmetic problem, usability improvement, customer can live with
the problem (default)
• Major – Problem adversely affects product functioning, but a workaround
is available; customer will be annoyed; serious usability impairment;
• Critical – Product does not function at all; the wrong results are generated;
• Emergency – Anything that requires a change to be made immediately,
bypassing the change control process temporarily
Project charter
Project Charter
• Agreement between the organization providing
the product or service, and the customer
organization requesting and receiving the
project deliverable.
• Tool to obtain commitment from all affected
groups and individuals within a specific project.
• Does not change throughout the project life
cycle.
Project Charter Structure
• The project typically consists of four primary
sections:
– Project identification and scope
– Authority and resource need definition
– Project roles and responsibilities
– Project structure and schedule
Project Charter - Example
PROJECT SCOPE
• Project name/title: Membership Recruitment Task Force
• Background/Introduction/Purpose:
In the past two years, membership has decreased 5%. This team is being called together to develop a strategy to increase member retention and to add 100 new members in the next two years.
• Scope Statement (Expected results/desired outcomes):
The membership committee will develop a strategy and action plan to increase member retention and add at least 100 new members by June 2005.
Project Charter – Example Contd.
AUTHORITY AND RESOURCES
• Who has the authority to make decisions and allocate funds?
The committee has the authority to spend up to $5,000 for this project. The committee is empowered to do what it takes to get the task done.
• What personnel resources are needed?
A consultant who is a specialist on membership retention and recruitment
One pro-active member from each of the regional chapters (8 people)
A marketing specialist from our membership (1 person)
Team leader (1 person)
• What is the budget?
Consultant ($2500), Marketing materials ($1500), Meetings ($1000)
• What is the time needed?
Six months
Project Charter – Example Contd.
ROLES AND RESPONSIBILITIES
• Research and select a consultant to work with committee (Tom, Mary and Bill—by Jan 1st)
• Develop membership calling campaign in each region (8 regional committee persons responsible) Membership phone campaign in June
• Develop marketing material (Tom—by April 1st)
• Mail out marketing materials to all present and past members in May
PROJECT SCHEDULE
• January 15th – Consultant retained
• February 10th Survey completed for approval
• March 1st – Survey mailed out
• April 1st – Marketing material completed
• May 1st – Mail out marketing materials
• June – Conduct phone campaign
Summary – Project Charter
Work break down structure
87
WBS Definition
•A deliverable-oriented grouping of project elements that
organizes and defines the total scope of the project work.
•Work not in the WBS is not in scope of the project.
•Each descending level represents an increasingly
detailed description of the project elements.
•Often used to develop or confirm a common
understanding of project scope.
88
Where the WBS Fits
Initiate
Plan
Execute
Control
Close Strategic
Tactical
Physical
Approaches to Developing WBSs
89
• Using guidelines: some organizations, like the DOD, provide guidelines for
preparing WBSs
• The analogy approach: review WBSs of similar projects and tailor to your
project
• The top-down approach: start with the largest items of the project and break
them down
• The bottom-up approach: start with the specific tasks and roll them up
• Mind-mapping approach: mind mapping is a technique that uses branches
radiating out from a core idea to structure thoughts and ideas
Making Brownies 1. Prepreparation 1.1 Read recipe
1.2 Check ingredients at home
1.3 Make shopping list
1.4 Go on shopping trip 2. Preparation
2.1 Gather tools
2.2 Gather ingredients
2.3 Mix ingredients
2.3.1 Melt butter and chocolate
in microwave
2.3.2 Mix other ingredients in
bowl
WBS Examples
2.4 Grease pan
2.5 Preheat oven
2.6 Pour batter in pan 3. Baking Process
3.1 Bake in oven
3.2 Test with toothpick
3.3 Remove from oven
3.4 Turn off oven 4. Cleanup Process
4.1 Wash dishes
4.2 Cool brownies
Making Brownies 1. Prepreparation 1.1 Read recipe
1.2 Check ingredients at home
1.3 Make shopping list
1.4 Go on shopping trip 2. Preparation
2.1 Gather tools
2.2 Gather ingredients
2.3 Mix ingredients
2.3.1 Melt butter and chocolate
in microwave
2.3.2 Mix other ingredients in
bowl
WBS Examples
2.4 Grease pan
2.5 Preheat oven
2.6 Pour batter in pan 3. Baking Process
3.1 Bake in oven
3.2 Test with toothpick
3.3 Remove from oven
3.4 Turn off oven 4. Cleanup Process
4.1 Wash dishes
4.2 Cool brownies
Making Brownies 1. Prepreparation 1.1 Read recipe
1.2 Check ingredients at home
1.3 Make shopping list
1.4 Go on shopping trip 2. Preparation
2.1 Gather tools
2.2 Gather ingredients
2.3 Mix ingredients
2.3.1 Melt butter and chocolate
in microwave
2.3.2 Mix other ingredients in
bowl
WBS Examples
2.4 Grease pan
2.5 Preheat oven
2.6 Pour batter in pan 3. Baking Process
3.1 Bake in oven
3.2 Test with toothpick
3.3 Remove from oven
3.4 Turn off oven 4. Cleanup Process
4.1 Wash dishes
4.2 Cool brownies
How I should break down the
project? • Geographically separated areas for product or
activities
• Major chronological time periods
• By structural, process, system, or device components
• By “intermediate” deliverables required in the production of the “end” deliverables
• By separate areas of responsibility, departments, or functional areas
Benefits of the WBS
91
WBS
Estimates
Schedule
Project Plan
Risk and Contingency
Plans
Progress Reports
Activity List
Risk Control
Project Control Change
Control
Communication Control
92
Common Approaches
Brainstorming all work
to be done and then
grouping into a
hierarchy.
Bottom Up
Using a general-to-
specific structure to
progressively detail the
work.
Top Down
Bottom up
WBS Development
NO
Yes
1. Create the “to-do”
list of work.
2. Organize the
“to-dos”.
3. Review and Adjust
with group.
4. Correct
and
Complete?
WBS Complete
16
Top Down WBS
Development
1. Choose your
model.
2. Verify highest level
Deliverables/Phases.
4. Review, Verify and
or modify the
next subsequent level.
3.
Can adequate
ests. be made at
this level?
WBS Complete Yes
No
5. Confirm lowest
level.
25
Top Down 1. Choose your model
• Review various:
life cycle models,
similar project’s WBS, or
life cycle templates.
• Choose a model closest to
your specific project.
26
2. Verify highest level phases/deliverables Top Down
Start at the top of a model
- Deliverables
• Verify deliverables represent the major
phases of your project,
• Verify purpose/need of each major deliverable or phase,
• Determine if a previous project completed
a major deliverable, e.g. Feasibility.
• Choose to: eliminate or modify deliverable after review of
previous completed work
28
Note* This step’s question means
- different levels of
decomposition are appropriate
for each
of the major deliverables/phases.
• Can it be completed within a
2 – 3 week period?
• Adequate may change over
the course of the project.
• Estimating a major work
package that will be produced
6 – 12 months out may not be
possible.
Top Down
“Yes” Decisions Guidelines
3. Can adequate estimates
be made at this level?
29
Top Down 4. Review, verify and or modify the
next subsequent level.
• Verify, from the model, the next
subsequent level’s, more specific work detail.
• Choose the appropriate work elements.
elements should be described in tangible, verifiable results in
order to facilitate the
project progress.
• Repeat step 3 for each work element that you
have chosen necessary for the project.
30
5. Confirm lowest level
Can the item be scheduled? Budgeted? Assigned
to a specific organizational unit (e.g., department,
team, or person)?
If no, combine items, add to,
delete, redefine.
If no, revise or expand the
descriptions
If no, the item must be modified,split,
redefined.
Top Down
Are the lower-level items both necessary
and sufficient?
Does the work item
description provide
a scope?
31
100
Top Down
• Requires more up front discussion.
• Terminology & structure
can get in the way.
• Decreases participation.
• Slower to start.
Lesson Learned
Bottom Up
• Easy to start.
• No terminology issues.
• Higher participation.
• What do we do with this?
What’s Next?
101
– Briefly describe each item
– Reference by number
– List associated activities
– List milestones
– List other information needed
to facilitate work
Further decomposition into a WBS Dictionary
WBS Summary
• Defines the hierarchy of deliverables
• Supports the definition of all work required to implement
deliverables
• Graphical representation of project scope
• Framework for all deliverables
• Framework for schedule and cost calculations
• Facilitates assignment of resources
• Facilitates reporting
• Provides a framework for project evaluation
Example
Annotated example
WBS representation
An exercise
• Create a WBS for creating “brownies”
Brownies WBS
Example WBS/phase
DETAILED WBS EXAMPLE
CUSTOM SYSTEM DEVELOPMENT
Develop
4.0
Online
Processes
4.1
Integration
Testing
4.5
System
Interfaces
4.3
User & Tech
Documentation
4.6
Screen
Development
4.1.1
Program
Development
4.1.2
Batch
Processes
4.2
Conversion
Programs
4.4
4.1.1.1.
Dev elop & Test
Screen A
4.1.1.2.
Dev elop & Test
Screen B
4.1.1.3.
Dev elop & Test
Screen C
4.1.2.1.
Dev elop & Test
Program A
4.1.2.2.
Dev elop & Test
Program B
4.1.2.3.
Dev elop & Test
Program C
4.1.2.4.
Dev elop & Test
Program D4.1.1.4.
Dev elop & Test
Screen D
4.3.1.
Dev elop & Test
Interf ace Pgm A
4.3.2
Dev elop & Test
Interf ace Pgm B
4.3.3
Dev elop & Test
Interf ace Pgm C
4.3.4
Dev elop & Test
Interf ace Pgm D
4.4.1.
Dev elop
Conv ersion Plan
4.4.2.
Dev elop & Test
XY Z Conv ersion
Programs
4.5.1.
Plan Test
4.5.2.
Establish Test
Ev ironment
4.5.3.
Implement Test
Tools
4.6.1.
Dev elop User
Manual
4.6.2.
Dev elop
Production
Documentation
4.6.3.
Dev elop Disaster
Recov ery
Documentation4.5.3.
Dev elop Test
Reports
4.5.3.
Execute Test
Other tools
• Scope Matrix – Requirements inventory
• Deliverable Tracking Matrix