Software Project Management
WBS, Estimation & Scheduling
The information contained in this presentation was obtained from the public domain
Reminders
• Best way to learn the most from SPM
course is not to behave like a student but
to think like a SPM.
Planning, Estimating, Scheduling
• What’s the difference?
• Plan: Identify activities. No specific start and end
dates.
• Estimating: Determining the size & duration of
activities.
• Schedule: Adds specific start and end dates,
relationships, and resources.
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*
* Relatively an old technique
7) Identify tasks
8) Estimate size
9) Estimate effort
10)Identify task
dependencies
11)Assign resources
12)Schedule work
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
Partitioning Your Project
• You need to 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?
Work Breakdown Structure: WBS
• Hierarchical list of project’s work activities
• 2 Formats
– Outline (indented format)
– Graphical Tree (Organizational Chart)
• Uses a decimal numbering system
– Ex: 3.1.5
– 0 is typically top level
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
A Full WBS Structure
• Up to six levels (3-6 usually) such as
WBS Chart Example
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
WBS Types
• Process WBS
• Activity-oriented
• Ex: Requirements, Analysis, Design, Testing
• Typically used by PM
• Product WBS
• Entity-oriented
• Ex: Financial engine, Interface system, DB
• Typically used by engineering manager
WBS Techniques
• Top-Down
• Bottom-Up
• Analogy
• Post-its on a wall
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
WBS Techniques
• Bottom-up
– Start at lowest level tasks
– Aggregate into summaries and higher levels
– Cons
• Time consuming
• Needs more requirements complete
– Pros
• Detailed
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
WBS Techniques
• Brainstorming
– Generate all activities you can think of that
need to be done
– Group them into categories
WBS – Basis of Many Things
• Network scheduling
• Costing
• Risk analysis
• Organizational structure
• Control
• Measurement
WBS Guidelines Part 1
• Should be easy to understand
• Some companies have corporate standards for
these schemes
• Some top-level items, like Project Mgmt. are in
WBS for each project
– Others vary by project
• What often hurts most is what’s missing
• Break down until you can generate accurate
time & cost estimates
• Ensure each element corresponds to a
deliverable
WBS Guidelines Part 2
• How detailed should it be?
– 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
Estimations
• Very difficult to do, but needed often
• 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
Estimations
• Remember, an “exact estimate” is difficult
• Estimate how long will it take you to get
home from class tonight
– On what basis did you do that?
– Experience right?
– Likely as an “average” probability
Estimation
• Target vs. Committed Dates
• Target: Proposed by business or marketing
• Do not commit to this too soon!
• Committed: Team agrees to this
• After you’ve developed a schedule
Estimation (Software)
• Size:
– Small projects (10-99 FPs), 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
Estimation Methodologies
• Top-down
• Bottom-up
• Analogy
• Expert Judgment
• Priced to Win
• Parametric or Algorithmic Method
– Using formulas and equations
Algorithmic Measures
• Lines of Code (LOC)
• Function points
• Feature points or object points
• Other possible
– Number of processes on a structure chart
• LOC and function points most common
– (of the algorithmic approaches)
Code Reuse & Estimation
• Does not come for free
• Code types: New, Modified, Reused
• If code is more than 50% modified, it’s “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
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 (or ‘staff-months’ now)
Effort Estimation
• 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)
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
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)

Wbs, estimation and scheduling

  • 1.
    Software Project Management WBS,Estimation & Scheduling The information contained in this presentation was obtained from the public domain
  • 2.
    Reminders • Best wayto learn the most from SPM course is not to behave like a student but to think like a SPM.
  • 3.
    Planning, Estimating, Scheduling •What’s the difference? • Plan: Identify activities. No specific start and end dates. • Estimating: Determining the size & duration of activities. • Schedule: Adds specific start and end dates, relationships, and resources.
  • 4.
    Project Planning: A12 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* * Relatively an old technique 7) Identify tasks 8) Estimate size 9) Estimate effort 10)Identify task dependencies 11)Assign resources 12)Schedule work
  • 5.
    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
  • 6.
    Partitioning Your Project •You need to 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?
  • 7.
    Work Breakdown Structure:WBS • Hierarchical list of project’s work activities • 2 Formats – Outline (indented format) – Graphical Tree (Organizational Chart) • Uses a decimal numbering system – Ex: 3.1.5 – 0 is typically top level
  • 8.
    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
  • 9.
    A Full WBSStructure • Up to six levels (3-6 usually) such as
  • 10.
  • 11.
    WBS Outline Example 0.0Retail 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
  • 12.
    WBS Types • ProcessWBS • Activity-oriented • Ex: Requirements, Analysis, Design, Testing • Typically used by PM • Product WBS • Entity-oriented • Ex: Financial engine, Interface system, DB • Typically used by engineering manager
  • 13.
    WBS Techniques • Top-Down •Bottom-Up • Analogy • Post-its on a wall
  • 14.
    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
  • 15.
    WBS Techniques • Bottom-up –Start at lowest level tasks – Aggregate into summaries and higher levels – Cons • Time consuming • Needs more requirements complete – Pros • Detailed
  • 16.
    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
  • 17.
    WBS Techniques • Brainstorming –Generate all activities you can think of that need to be done – Group them into categories
  • 18.
    WBS – Basisof Many Things • Network scheduling • Costing • Risk analysis • Organizational structure • Control • Measurement
  • 19.
    WBS Guidelines Part1 • Should be easy to understand • Some companies have corporate standards for these schemes • Some top-level items, like Project Mgmt. are in WBS for each project – Others vary by project • What often hurts most is what’s missing • Break down until you can generate accurate time & cost estimates • Ensure each element corresponds to a deliverable
  • 20.
    WBS Guidelines Part2 • How detailed should it be? – 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
  • 21.
    Estimations • Very difficultto do, but needed often • 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
  • 22.
    Estimations • Remember, an“exact estimate” is difficult • Estimate how long will it take you to get home from class tonight – On what basis did you do that? – Experience right? – Likely as an “average” probability
  • 23.
    Estimation • Target vs.Committed Dates • Target: Proposed by business or marketing • Do not commit to this too soon! • Committed: Team agrees to this • After you’ve developed a schedule
  • 24.
    Estimation (Software) • Size: –Small projects (10-99 FPs), 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
  • 25.
    Estimation Methodologies • Top-down •Bottom-up • Analogy • Expert Judgment • Priced to Win • Parametric or Algorithmic Method – Using formulas and equations
  • 26.
    Algorithmic Measures • Linesof Code (LOC) • Function points • Feature points or object points • Other possible – Number of processes on a structure chart • LOC and function points most common – (of the algorithmic approaches)
  • 27.
    Code Reuse &Estimation • Does not come for free • Code types: New, Modified, Reused • If code is more than 50% modified, it’s “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
  • 28.
    Effort Estimation • Nowthat you know the “size”, determine the “effort” needed to build it • Various models: empirical, mathematical, subjective • Expressed in units of duration – Man-months (or ‘staff-months’ now)
  • 29.
    Effort Estimation • Aswith 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)
  • 30.
    COCOMO • COnstructive COstMOdel • 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
  • 31.
    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)