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 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? Activity INFO 420 Chapter 6 3 Project time management 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 Activity 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) INFO 420 Milestone – end of phase review (follows e.g. 1.4) 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 INFO 420 they still focus on producing deliverables Chapter 6 8 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 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 What do these tasks produce? WBS INFO 420 is deliverable oriented supports the MOV All lower level tasks should be enough to complete the next higher level task Chapter 6 12 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 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, INFO 420 one basket, that problem Chapter 6 14 Estimation We’ll look at several approaches for doing task estimation Guesstimating Delphi technique 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-guessconsensus 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 Internal logical 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 INFO 420 can estimate equivalent LOC from FP Chapter 6 28 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 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