1. INFO 420Chapter 6 1 SW Project Management WBS and Project Estimation INFO 420 Glenn Booker

2. Chapter 62 INFO 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

3. Chapter 63 INFO 420 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?

4. Chapter 64 INFO 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

5. Chapter 65 INFO 420 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

6. Chapter 66 INFO 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)

7. Chapter 67 INFO 420 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

8. Chapter 68 INFO 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

9. Chapter 69 INFO 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

10. Chapter 610 INFO 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

11. Chapter 611 INFO 420 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

12. Chapter 612 INFO 420 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

13. Chapter 613 INFO 420 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

14. Chapter 614 INFO 420 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

15. Chapter 615 INFO 420 Estimation We’ll look at several approaches for doing task estimation  Guesstimating  Delphi technique  Time boxing  Top-down estimating  Bottom-up estimating

16. Chapter 616 INFO 420 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

17. Chapter 617 INFO 420 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

18. Chapter 618 INFO 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

19. Chapter 619 INFO 420 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

20. Chapter 620 INFO 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 heuristicsISBN 1556159005

21. Chapter 621 INFO 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

22. Chapter 622 INFO 420 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

23. Chapter 623 INFO 420 Brooks’ Law “Adding people to a late software project makes it later”  -- from the legendary Mythical Man-Month book by Frederick BrooksMythical Man-Month book by Frederick Brooks Why?

24. Chapter 624 INFO 420 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)

25. Chapter 625 INFO 420 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

26. Chapter 626 INFO 420 Function points Function points are an internationally recognized way to measure system sizeinternationally recognized  Based on counting how many and how complex parts of the system will be Types of parts are  Internal logical files  External interface files

27. Chapter 627 INFO 420 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

28. Chapter 628 INFO 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

29. Chapter 629 INFO 420 COCOMO 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

30. Chapter 630 INFO 420 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

31. Chapter 631 INFO 420 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

32. Chapter 632 INFO 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