1 / 32

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 scope description, and thought about the right organization needed to manage it

magnar
Télécharger la présentation

SW Project Management WBS and Project Estimation

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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

More Related