SW Project Management WBS and Project Estimation

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

2. 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

3. 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? Chapter 6

4. 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

5. 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 Chapter 6

6. 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

7. 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 Chapter 6

8. 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

9. 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

10. 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

11. 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 Chapter 6

12. 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 Chapter 6

13. 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 Chapter 6

14. 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 Chapter 6

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

16. 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 Chapter 6

17. 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 Chapter 6

18. 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

19. 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 Chapter 6

20. 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

21. 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

22. 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 Chapter 6

23. 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

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

25. 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 Chapter 6

26. 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 Chapter 6

27. 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 Chapter 6

28. 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

29. 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 Chapter 6

30. 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 Chapter 6

31. 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 Chapter 6

32. 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 Chapter 6