SW Project Management WBS and Project Estimation - PowerPoint PPT Presentation


PPT – SW Project Management WBS and Project Estimation PowerPoint presentation | free to download - id: 56362a-NjFiM


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

SW Project Management WBS and Project Estimation


SW Project Management WBS and Project Estimation INFO 420 Glenn Booker Time for the details Now we have outlined the project in its charter, clarified it with a ... – PowerPoint PPT presentation

Number of Views:70
Avg rating:3.0/5.0
Slides: 33
Provided by: gle991
Learn more at: http://cci.drexel.edu


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: SW Project Management WBS and Project Estimation

SW Project ManagementWBS and Project Estimation
  • INFO 420
  • Glenn Booker

Time for the details
  • Now we have outlined the project in its charter,
    clarified it with a scope description, and
    thought about the right organization needed to
    manage it
  • Time to figure out the details of what is needed
    to make this project work

Project time management
  • This is formally (PMBOK) known as project time
    management, which includes
  • Activity definition what tasks are needed to
    produce project scope deliverables
  • Activity sequencing put them in order
  • Activity resource estimation who needs to
    perform the tasks? How many of them?

Project time management
  • Activity duration estimation calendar time for
    each task
  • Schedule development put together a schedule
    with all the above information in it
  • Schedule control define processes to control
    changes to the schedule
  • For now well focus on activity definition and

  • A Work Breakdown Structure (WBS) gives a
    hierarchical structure to project tasks
  • Allows more detail to be added later
  • The WBS decomposes the work to be done to
    accomplish each deliverable
  • Each smaller unit is a work package, which may
    have a person assigned to manage it

WBS Overview
  • Since the scope defined the deliverables, the
    WBS work packages can each be focused on
    creating some deliverable
  • Project (task number 0)
  • for each Phase (tasks 1.0, 2.0, 3.0, )
  • for each Deliverable (tasks 1.1, 1.2, 1.3, 2.1,
  • Task(s) to create deliverable (tasks 1.1.1,
    1.1.2, etc.
  • Milestone - Approval of deliverable (follows
    task, 1.1.3)
  • Milestone end of phase review (follows e.g. 1.4)

WBS Overview
  • Each phase might have many deliverables
  • The number of tasks to create a deliverable could
    be from one to dozens
  • Milestones are major decision points, typically
    to approve a deliverable, or approve the end of a
  • Milestones have zero duration
  • Milestones are great focal points for the team

WBS Overview
  • Tasks associated with the SDLC typically are
    grouped into life cycle phases or iterations or
    time boxes
  • Some support tasks for project processes might
    run throughout the project (project management,
    CM, risk management, etc.)
  • But they still focus on producing deliverables

WBS Overview
  • Some deliverables could entail many individual
    items, such as test results, or documentation, or
    logical design
  • Its up to you to determine exactly what is
    needed for that project to fulfill that category
    of deliverable a key judgment call
  • Then define the steps needed to produce and
    approve each deliverable

Naming tasks
  • For everything below the Phase level in the WBS,
    start task and milestone names with a verb
  • Data Flow Diagram doesnt tell me if youre
    creating it, reviewing it, getting it approved,
    updating it, or something else
  • The package level task might be to Develop Data
    Flow Diagram for example

  • Milestones also provide a stopping point to
    reflect on the projects progress
  • Phase milestones allow consideration if
    continuing the project is really a good idea
  • Milestones are a risk management tool
  • By getting customer (sponsor?) involvement, they
    also help manage expectations and get an outside
    quality review

WBS guidelines
  • Some general rules to help produce a better WBS
  • WBS is deliverable oriented
  • What do these tasks produce?
  • WBS supports the MOV
  • All lower level tasks should be enough to
    complete the next higher level task

WBS guidelines
  • Pick a good consistent level of detail
  • Get experts to help develop the WBS
  • Who knows what tasks are really needed?
  • Keep track of lessons learned to develop a better
    WBS the next time

  • After defining the tasks, next estimate how much
    effort is needed for each
  • This is the hardest part of software project
  • Often a blend of approaches is used dont rely
    on one method
  • Eggs, one basket, that problem

  • Well look at several approaches for doing task
  • Guesstimating
  • Delphi technique
  • Time boxing
  • Top-down estimating
  • Bottom-up estimating

  • Often estimations are made without any formal
    basis, so we politely call them guesstimates
  • Dont do this!
  • Often fails to account for key tasks, produces
    optimistic estimates, or may be flat out wrong

Delphi technique
  • This is an average-expert-guess-consensus method
    for estimating
  • 1. Collect some experts
  • 2. Ask them to estimate the tasks
  • 3. Compare the estimates
  • 4. Ask them why some estimates were much higher
    or lower than the others

Delphi technique
  • 5. Repeat steps 2-4 until the estimates are
    fairly close
  • 6. Average the estimates, and use that for your
  • Sounds dopey?
  • Maybe, but its fairly accurate, though time
    consuming to generate

Time boxing
  • Time boxing, in this context, refers to setting a
    fixed duration for the task
  • Get as much done as possible during that time box
  • Times up? Youre done.
  • Often used when strict time constraints exist,
    but scope may suffer

Top-down estimating
  • Often projects are given a broad budget (X and Y
  • Can use this to break down how much time and
    effort each phase gets, and allocate effort to
    tasks accordingly
  • McConnell (ISBN 1556159005) has guidance on the
    percent of a projects effort and schedule
    devoted to each phase or see heuristics

Bottom-up estimating
  • Many projects are estimated from the bottom up,
    i.e. estimate each task individually, and add
    them up!
  • Often exceeds the overall budget for a project,
    so top-down and bottom-up are both used to find a
    happy medium

Other approaches
  • Analogous estimation estimates tasks based on
    similar past projects
  • Often very accurate, but needs history!
  • Personally, Ive noted that estimates follow a
    kilo-to-lb scaling rule
  • If you know how long a task should take, double
    it and add a little more

Brooks Law
  • Adding people to a late software project makes
    it later
  • -- from the legendary Mythical Man-Month book by
    Frederick Brooks
  • Why?

  • Metrics just refers to measuring something
  • In the context of software development, we want
    to measure important aspects of what were
  • Size
  • Effort (hence cost)
  • Schedule
  • Quality (defects)

  • The two main measures of software size are Lines
    of Code (LOC) or function points
  • LOC has the strongest correlation to development
    time and effort. Period.
  • Need to define consistent rules for what is a
  • Function points are a language-independent
    measure of system complexity and size

Function points
  • Function points are an internationally recognized
    way to measure system size
  • Based on counting how many and how complex parts
    of the system will be
  • Types of parts are
  • Internal logical files
  • External interface files

Function points
  • External inputs
  • External outputs
  • External inquiries
  • Each part is measured on a hi/med/lo complexity
    scale, and has function points assigned
  • Then add up the raw function points

Function points
  • Assess 14 general system characteristics (GSC) on
    a scale from 0 to 5 (not present to strong
  • The GSC score contributes to an adjustment
    factor, which is multiplied by the raw total
    function point count
  • Got that?
  • Or can estimate equivalent LOC from FP

  • Several tools have been developed for estimating
    software projects
  • A famous and free one is COCOMO
  • First published by Barry Boehm (USC, 1981)
  • Based on the type and size of product, team
    expertise, and many other factors
  • Not terribly accurate, but better than a guess

  • A heuristic is a rule of thumb, just sounds
  • Such as my kilo-to-lb scaling rule
  • Lots of heuristics are available, but their
    accuracy and relevance to your project is

Estimation tools
  • There are other estimation tools out there
  • SLIM
  • CostXpert
  • Etc.
  • None are as accurate as having historic data, but
    theyre better than a wild guess

So whats the best way to estimate?
  • There is no one answer thats why this is the
    hardest part of software management!
  • Try several approaches, and throw out outliers
  • Be wary of adjusting estimates to get the right
    answer to make your boss happy
About PowerShow.com