1

WBS, Estimation and Scheduling

Adapted from slides by John Musser
2
Today
Work Breakdown Structures (WBS)
Estimation
Network Fundamentals
PERT & CPM Techniques
Gantt Charts
3
Estimation
Predictions are hard, especially about the
future, Yogi Berra
2 Types: Lucky or Lousy
4
Plan, Estimate, Schedule
Whats the difference?
Plan
Identify activities. No specific start and end dates.
Estimate
Determine the size and duration of activities.
Schedule
Add specific start and end dates, relationships, and
resources.
5
Project Planning: A 12 Step Program
1) Set goal and scope
2) Select lifecycle
3) Set org./team form
4) Start team selection
5) Determine risks
6) Create WBS
7) Identify tasks
8) Estimate size
9) Estimate effort
10) Identify task
dependencies
11) Assign resources
12) Schedule work
6
How To Schedule
1. Identify what needs to be done
Work Breakdown Structure (WBS)
2. Identify how much (the size)
Size estimation techniques
3. Identify the dependency between tasks
Dependency graph, network diagram
4. Estimate total duration of the work to be done
The actual schedule
7
WBS & Estimation
How long will your project take?
Not an easy answer
Especially not on a real project
How to manage that issue?
8
Partitioning Your Project
Decompose your project into manageable chunks
ALL projects need this step
Divide & Conquer
Two main causes of project failure
Forgetting something critical
Ballpark estimates become targets
How does partitioning help this?
9
Project Elements
A Project: functions, activities, tasks
10
Work Breakdown Structure: WBS
Hierarchical list of projects work activities
Two Formats
Outline (indented format)
Graphical Tree (Organizational Chart)
Uses a decimal numbering system
Ex: 3.1.5 (0 is typically top level)
Includes
Development, Management, and project support tasks
Shows is contained in relationships
Does not show dependencies or durations
11
WBS
Contract WBS (CWBS)
First 2 or 3 levels
High-level tracking
Project WBS (PWBS)
Defined by PM and team members
Tasks tied to deliverables
Lowest level tracking
12
A Full WBS Structure
Up to six levels (3-6 usually) such as
Upper 3 can be used by customer for reporting (if
part of RFP/RFQ)
Different level can be applied to different uses
Ex: Level 1: authorizations; 2: budgets; 3: schedules
13
WBS Chart Example
14
WBS Outline Example
0.0 Retail Web Site
1.0 Project Management
2.0 Requirements Gathering
3.0 Analysis & Design
4.0 Site Software Development
4.1 HTML Design and Creation
4.2 Backend Software
4.2.1 Database Implementation
4.2.2 Middleware Development
4.2.3 Security Subsystems
4.2.4 Catalog Engine
4.2.5 Transaction Processing
4.3 Graphics and Interface
4.4 Content Creation
5.0 Testing and Production
15
WBS Types
Process WBS
a.k.a. Activity-oriented
Ex: Requirements, Analysis, Design, Testing
Typically used by PM
Product WBS
a.k.a. Entity-oriented
Ex: Financial engine, Interface system, DB
Typically used by engineering manager
Hybrid WBS: both of above
This is not unusual
Ex: Lifecycle phases at high level with component or feature-
specifics within phases
Rationale: processes produce products
16
Product WBS
17
Process WBS
18
Outline WBS w/Gantt
19
WBS by PMI Process Groups
20
WBS Types
Less frequently used alternatives
Organizational WBS
Research, Product Design, Engineering, Operations
Can be useful for highly cross-functional projects
Geographical WBS
Can be useful with distributed teams
NYC team, San Jose team, Off-shore team
21
Work Packages
Generic term for discrete tasks with definable end results
Typically the leaves on the tree
The one-to-two rule
Often at: 1 or 2 persons for 1 or 2 weeks
Basis for monitoring and reporting progress
Can be tied to budget items (charge numbers)
Resources (personnel) assigned
Ideally shorter rather than longer
Longer makes in-progress estimates needed
These are more subjective than done
2-3 weeks maximum for software projects
1 day minimum (occasionally a half day)
Not so small as to micro-manage
22
WBS
List of Activities, not Things
List of items can come from many sources
SOW, Proposal, brainstorming, stakeholders, team
Describe activities using bullet language
Meaningful but terse labels
All WBS paths do not have to go to the same level
Do not plan more detail than you can manage
23
WBS & Methodology
PM must map activities to chosen lifecycle
Each lifecycle has different sets of activities
Integral process activities occur for all
Planning, configuration, testing
Operations and maintenance phases are not
normally in plan (considered post-project)
Some models are straightened for WBS
Spiral and other iterative models
Linear sequence several times
Deliverables of tasks vary by methodology
24
WBS Techniques
Top-Down
Bottom-Up
Analogy
Rolling Wave
1
st
pass: go 1-3 levels deep
Gather more requirements or data
Add more detail later
Post-its on a wall
25
WBS Techniques
Top-down
Start at highest level
Systematically develop increasing level of
detail
Best if
The problem is well understood
Technology and methodology are not new
This is similar to an earlier project or problem
But is also applied in majority of situations
26
WBS Techniques
Bottom-up
Start at lowest level tasks
Aggregate into summaries and higher levels
Cons
Time consuming
Needs more requirements complete
Pros
Detailed
27
WBS Techniques
Analogy
Base WBS upon that of a similar project
Use a template
Analogy also can be estimation basis
Pros
Based on past actual experience
Cons
Needs comparable project
28
WBS Techniques
Brainstorming
Generate all activities you can think of that
need to be done
Group them into categories
Both Top-down and Brainstorming can be
used on the same WBS
Remember to get the people who will be
doing the work involved (buy-in matters!)
29
WBS Basis of Many Things
Network scheduling
Costing
Risk analysis
Organizational structure
Control
Measurement
30
WBS Guidelines
Should be easy to understand
Some companies have corporate standards for
these schemes
Some top-level items, like Project Management,
are in WBS for each project
Others vary by project
What often hurts most is whats missing
Break down until you can generate accurate time
and cost estimates
Ensure each element corresponds to a deliverable
31
WBS Guidelines ..2
How detailed should it be?
Not as detailed as the final project plan
Each level should have no more than 7 items
It can evolve over time
What tool should you use?
Excel, Word, Project
Org chart diagramming tool (Visio, etc)
Specialized commercial apps
Re-use a template if you have one
32
Estimations
Very difficult to do, but needed often
Created, used or refined during
Strategic planning
Feasibility study and/or SOW
Proposals
Vendor and sub-contractor evaluation
Project planning (iteratively)
Basic process
1) Estimate the size of the product
2) Estimate the effort (man-months)
3) Estimate the schedule
NOTE: Not all of these steps are always explicitly performed
33
Estimations
34
Estimations
Remember, an exact estimate is an oxymoron
Estimate how long will it take you to get home
from class tonight
On what basis did you do that?
Experience?
Likely as an average probability
For most software projects there is no such average
Most software estimations are off by 25-100%
35
Estimation
Target vs. Committed Dates
Target: Proposed by business or marketing
Do not commit to this too soon!
Committed: Team agrees to this
After youve developed a schedule
36
Cone of Uncertainty
37
Estimation
Size:
Small projects (10-99 Function Points),
variance of 7% from post-requirements
estimates
Medium (100-999 FPs), 22% variance
Large (1000-9999 FPs) 38% variance
Very large (10K+ FPs) 51% variance
38
Estimation Methodologies
Top-down
Bottom-up
Analogy
Expert Judgment
Priced to Win
Parametric or Algorithmic Method
Using formulas and equations
39
Top-down Estimation
Based on overall characteristics of project
Some of the others can be types of top-down
(Analogy, Expert Judgment, and Algorithmic methods)
Advantages
Easy to calculate
Effective early on (like initial cost estimates)
Disadvantages
Some models are questionable or may not fit
Less accurate because it doesnt look at details
40
Bottom-up Estimation
Create WBS
Add from the bottom up
Advantages
Works well if activities well understood
Disadvantages
Specific activities not always known
More time consuming
41
Expert Judgment
Use somebody who has recent experience
on a similar project - not easy for software!
You get a guesstimate
Accuracy depends on their real expertise
Comparable application(s) must be
accurately chosen
Systematic
Can use a weighted-average of opinions
42
Estimation by Analogy
Use past project
Must be sufficiently similar (technology, type,
organization)
Find comparable attributes (ex: no. of inputs/outputs)
Can create a function
Advantages
Based on actual historical data
Disadvantages
Difficulty matching project types
Prior data may have been mis-measured
How to measure differences no two exactly same
43
Priced to Win
Just follow other estimates
Save on doing full estimate
Needs information on other estimates (or
prices)
Purchaser must closely watch trade-offs
Priced to lose?
44
Algorithmic Measures
Lines of Code (LOC)
Function points
Feature points or object points
Other possible
Number of bubbles on a DFD
Number of of ERD entities
Number of processes on a structure chart
LOC and function points most common
(of the algorithmic approaches)
Majority of projects use none of the above
45
Code-based Estimates
LOC Advantages
Commonly understood metric
Permits specific comparison
Actuals easily measured
LOC Disadvantages
Difficult to estimate early in cycle
Counts vary by language
Many costs not considered (ex: requirements)
Programmers may be rewarded based on this
Can use: # defects/# LOC
Code generators produce excess code
46
LOC Estimate Issues
How do you know how many in advance?
What about different languages?
What about programmer style?
Most algorithmic approaches are more effective
after requirements (or have to be after)
47
Function Points
Software size should be measured by number and
complexity of functions it performs
More methodical than LOC counts
House analogy
Houses Square Feet ~= Software LOC
# Bedrooms & Baths ~= Function points
Former is size only, latter is size & function
Six basic steps
48
Function Point Process
1. Count number of business functions per category
Categories: outputs, inputs, db inquiries, files or data structures,
and interfaces
2. Establish Complexity Factor for each and apply
Simple, Average, Complex
Set a weighting multiplier for each (0->15)
This results in the unadjusted function-point total
3. Compute an influence multiplier and apply
It ranges from 0.65 to 1.35; is based on 14 factors
4. Results in function point total
This can be used in comparative estimates
49
Wideband Delphi
Group consensus approach
Rand Corporation used Delphi approach to predict future technologies
Present experts with a problem and response form
Conduct group discussion, collect anonymous opinions, then feedback
Conduct another discussion and iterate until consensus
Advantages
Easy, inexpensive, utilizes expertise of several people
Does not require historical data
Disadvantages
Difficult to repeat
May fail to reach consensus, reach wrong one, or all may have
same bias
50
Parametric Method Issues
Remember: most projects dont use these methods
This is normal, so dont be surprised
Come in to new job and say Hey, lets use COCOMO
These are more effective on large projects
Where a past historical base exists
Primary issue for most projects are
Lack of similar projects
Thus lack of comparable data
Catch-22: how to get started
51
Code Reuse and Estimation
Does not come for free
Code types: New, Modified, Reused
If code is more than 50% modified, its new
Reuse factors have wide range
Reused code takes 30% effort of new
Modified is 60% of new
Integration effort with reused code almost as
expensive as with new code
52
Effort Estimation
Now that you know the size, determine the
effort needed to build it
Various models: empirical, mathematical,
subjective
Expressed in units of duration
Man-months, person-months
53
Effort Estimation
McConnell has schedule tables to convert size to effort
As with parametric size estimation, these techniques
perform better with historical data
Again, not seen in average projects
Often the size and effort estimation steps are combined
(not that this is recommended, but is what often is done)
Commitment-Based Scheduling is what is often done
Ask developer to commit to an estimate (his or her own)
54
COCOMO
COnstructive COst MOdel
Allows for the type of application, size, and Cost
Drivers
Outputs in Person Months
Cost drivers using High/Med/Low & include
Motivation
Ability of team
Application experience
Biggest weakness?
Requires input of a product size estimate in LOC
55
Estimation Issues
Quality estimations needed early but information is limited
Precise estimation data available at end but not needed
Or is it? What about the next project?
Best estimates are based on past experience
Politics of estimation:
You may anticipate a cut by upper management
For many software projects there is little or none
Technologies change
Historical data unavailable
Wide variance in project experiences/types
Subjective nature of software estimation
56
Over and Under Estimation
Over-estimation issues
The project will not be funded
Conservative estimates guaranteeing 100% success may mean
funding probability of zero.
Parkinsons Law: Work expands to take the time allowed
Danger of feature and scope creep
Be aware of double-padding: team member and manager
Under-estimation issues
Quality issues (short changing key phases like testing)
Inability to meet deadlines
Morale and other team motivation issues
57
Estimation Guidelines
Estimate iteratively!
Process of gradual refinement
Make your best estimates at each planning stage
Refine estimates and adjust plans iteratively
Plans and decisions can be refined in response
Balance: too many revisions vs. too few
58
Know Your Deadlines
Are they Real Deadlines?
Tied to an external event
Have to be met for project to be a success
Ex: end of financial year, contractual deadline, Y2K
Or Artificial Deadlines?
Set by arbitrary authority
May have some flexibility (if pushed)
59
Estimation Presentation
How you present the estimation can have huge impact
Techniques
Plus-or-minus qualifiers
6 months +/-1 month
Ranges
6-8 months
Risk Quantification
+/- with added information
+1 month of new tools not working as expected
-2 weeks for less delay in hiring new developers
Cases
Best / Planned / Current / Worst cases
Coarse Dates
Q3 02
Confidence Factors
April 1 10% probability, July 1 50%, etc.
60
Other Estimation Factors
Account for resource experience or skill
Up to a point
Often needed more on the low end, such as for a new
or junior person
Allow for non-project time & common tasks
Meetings, phone calls, web surfing, sick days
There are commercial estimation tools available
They typically require configuration based on past data
61
WBS Project Homework
Start with level 0, which is a single node the
name of your project.
Then do level 1, the highest level breakdown -
about 4-7 nodes.
Finally do level 2. Go deeper at your discretion.
Use either a process, product or hybrid approach.
Process is probably best at the highest level.
Use Excel, Word, Project or whatever. Follow the
standard WBS hierarchical numbering scheme.