INFO 420 Chapter 6 1
SW Project ManagementWBS and Project Estimation
INFO 420Dr. Jennifer Booker
Chapter 6 2INFO 420
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
Chapter 6 3INFO 420
Project time management
This is formally (PMBOK) known as project time management, which includesActivity definition – what tasks are needed
to produce project scope deliverablesActivity sequencing – put them in orderActivity resource estimation – who needs
to perform the tasks? How many of them?
Chapter 6 4INFO 420
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 we’ll focus on activity definition and estimation
Chapter 6 5INFO 420
WBS
A Work Breakdown Structure (WBS) gives a hierarchical structure to project tasksAllows more detail to be added later
The WBS decomposes the work to be done to accomplish each deliverableEach smaller unit is a work package, which
may have a person assigned to manage it
Chapter 6 6INFO 420
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)
Chapter 6 7INFO 420
WBS Overview
Each phase might have many deliverablesThe 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 phaseMilestones have zero durationMilestones are great focal points for the team
Chapter 6 8INFO 420
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
Chapter 6 9INFO 420
WBS Overview
Some deliverables could entail many individual items, such as test results, or documentation, or logical design It’s 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
Chapter 6 10INFO 420
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
Chapter 6 11INFO 420
Milestones
Milestones also provide a stopping point to reflect on the project’s progressPhase milestones allow consideration if
continuing the project is really a good ideaMilestones are a risk management toolBy getting customer (sponsor?) involvement,
they also help manage expectations and get an outside quality review
Chapter 6 12INFO 420
WBS guidelines
Some general rules to help produce a better WBSWBS 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
Chapter 6 13INFO 420
WBS guidelines
Pick a good consistent level of detailGet 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
Chapter 6 14INFO 420
Estimation
After defining the tasks, next estimate how much effort is needed for eachThis is the hardest part of software project
management Often a blend of approaches is used –
don’t rely on one methodEggs, one basket, that problem
Chapter 6 15INFO 420
Estimation
We’ll look at several approaches for doing task estimationGuesstimatingDelphi techniqueTime boxingTop-down estimatingBottom-up estimating
Chapter 6 16INFO 420
Guesstimating
Often estimations are made without any formal basis, so we politely call them guesstimatesDon’t do this!Often fails to account for key tasks, produces
optimistic estimates, or may be flat out wrong
Chapter 6 17INFO 420
Delphi technique
This is an average-expert-guess-consensus method for estimating1. Collect some experts2. Ask them to estimate the tasks3. Compare the estimates4. Ask them why some estimates were much
higher or lower than the others
Chapter 6 18INFO 420
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
Chapter 6 19INFO 420
Time boxing
Time boxing, in this context, refers to setting a fixed duration for the taskGet as much done as possible during that
time boxTime’s up? You’re done.
Often used when strict time constraints exist, but scope may suffer
Chapter 6 20INFO 420
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
Chapter 6 21INFO 420
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
Chapter 6 22INFO 420
Other approaches
Analogous estimation estimates tasks based on similar past projectsOften 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
Chapter 6 23INFO 420
Brooks’ Law
“Adding people to a late software project makes it later”-- from the legendary Mythical Man-Month
book by Frederick Brooks Why?
Chapter 6 24INFO 420
Metrics
Metrics just refers to measuring something In the context of software development,
we want to measure important aspects of what we’re developingSizeEffort (hence cost)ScheduleQuality (defects)
Chapter 6 25INFO 420
Size
The two main measures of software size are Lines of Code (LOC) or function pointsLOC 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
Chapter 6 26INFO 420
Function points
Function points are an internationally recognized way to measure system sizeBased on counting how many and how
complex parts of the system will be Types of parts are
Internal logical filesExternal interface files
Chapter 6 27INFO 420
Function points
External inputsExternal outputsExternal inquiries
Each part is measured on a hi/med/lo complexity scale, and has function points assigned
Then add up the raw function points
Chapter 6 28INFO 420
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
Chapter 6 29INFO 420
COCOMO
Several tools have been developed for estimating software projects
A famous and free one is COCOMOFirst published by Barry Boehm (USC, 1981)Based on the type and size of product, team
expertise, and many other factorsNot terribly accurate, but better than a guess
Chapter 6 30INFO 420
Heuristics
A heuristic is a rule of thumb, just sounds betterSuch as my kilo-to-lb scaling rule
Lots of heuristics are available, but their accuracy and relevance to your project is questionable
Chapter 6 31INFO 420
Estimation tools
There are other estimation tools out thereSLIMCost*XpertEtc.
None are as accurate as having historic data, but they’re better than a wild guess
Chapter 6 32INFO 420
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
Top Related