SW Project Management

WBS and Project Estimation

INFO 420
Dr. Jennifer Booker
INFO 420 Chapter 6 1
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

INFO 420 Chapter 6 2

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?

INFO 420 Chapter 6 3

Project time management
 Activityduration 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 we’ll focus on activity definition
and estimation

INFO 420 Chapter 6 4

WBS
 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

INFO 420 Chapter 6 5

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)

INFO 420 Chapter 6 6

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 phase
 Milestones have zero duration
 Milestones are great focal points for the team

INFO 420 Chapter 6 7

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

INFO 420 Chapter 6 8

WBS Overview
 Some deliverables could entail many
individual items, such as test results, or
documentation, or logical design
 It’sup 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

INFO 420 Chapter 6 9

Naming tasks
 For everything below the Phase level in
the WBS, start task and milestone names
with a verb
 “Data Flow Diagram” doesn’t tell me if you’re
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

INFO 420 Chapter 6 10

Milestones
 Milestones also provide a stopping point
to reflect on the project’s 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

INFO 420 Chapter 6 11

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

INFO 420 Chapter 6 12

WBS guidelines
 Picka 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

INFO 420 Chapter 6 13

Estimation
 After defining the tasks, next estimate how
much effort is needed for each
 This is the hardest part of software project
management
 Often a blend of approaches is used –
don’t rely on one method
 Eggs, one basket, that problem

INFO 420 Chapter 6 14

Estimation
 We’ll look at several approaches for doing
task estimation
 Guesstimating
 Delphitechnique
 Time boxing
 Top-down estimating
 Bottom-up estimating

INFO 420 Chapter 6 15

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

INFO 420 Chapter 6 16

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

INFO 420 Chapter 6 17

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

INFO 420 Chapter 6 18

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
 Time’s up? You’re done.
 Often used when strict time constraints
exist, but scope may suffer

INFO 420 Chapter 6 19

Top-down estimating
 Often projects are given a broad budget
($X and Y months)
 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 project’s effort and schedule
devoted to each phase; or see heuristics

INFO 420 Chapter 6 20

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

INFO 420 Chapter 6 21

Other approaches
 Analogous estimation estimates tasks
based on similar past projects
 Often very accurate, but needs history!
 Personally, I’ve 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

INFO 420 Chapter 6 22

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

INFO 420 Chapter 6 23

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

INFO 420 Chapter 6 24

Size
 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 LOC’
 Function points are a language-independent
measure of system complexity and size

INFO 420 Chapter 6 25

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
 Internallogical files
 External interface files

INFO 420 Chapter 6 26

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

INFO 420 Chapter 6 27

Function points
 Assess 14 general system characteristics
(GSC) on a scale from 0 to 5 (not present
to strong influence)
 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

INFO 420 Chapter 6 28

COCOMO
 Several tools have been developed for
estimating software projects
 A famous and free one is COCOMO
 Firstpublished 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

INFO 420 Chapter 6 29

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

INFO 420 Chapter 6 30

Estimation tools
 There are other estimation tools out there
 SLIM
 Cost*Xpert
 Etc.
 None are as accurate as having historic
data, but they’re better than a wild guess

INFO 420 Chapter 6 31

So what’s the best way to
estimate?
 There is no one answer; that’s 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

INFO 420 Chapter 6 32