Work Breakdown Structures

Work Breakdown Structures Identifying Manageable Activities

Agenda 1. Creating a WBS 2. Using the WBS for Estimation

Work Breakdown Structure • Work • A WBS considers the work that needs to be performed • This includes development, but also user manuals, sales support, administration, deployment, media, etc. • Breakdown • Work is broken down (decomposed) into small pieces (activities) • Activities are eventually broken down into tasks • A task is something that takes less than a week to complete • Activities are normally assigned to individuals • Structure • Each unit of work is broken down into a number of components • The result is a hierarchical structure • The lowest layers are tasks • e.g. A function that generates a polynomial collision-handling hash function is completed • e.g. Send user manual prototype to printer for an estimate • The middle layers could be milestones • e.g. “Getting started” tutorial is completed • The highest layers are normally deliverables • e.g. Source code distribution, with configuration and makefiles, is completed

Terminology • Activity: • Some behaviour that needs to be done • Produces some outcome (e.g. a deliverable) • Is often decomposed into other activities or tasks • Task: • An activity that is not decomposed • Is at the lowest level of the WBS • Also called a work package

Example WBS Usability Training 1 - Personnel Available 2 - Training Seminars Booked 57 - Hotel Rooms Reserved … … … 2.1 - Deal Made with Susan Carleson 2.2 - Budget Approval Form Submitted to Accounts Payable 2.13 - Cheque Requisition Made to Accounts Payable …

Advantages of a WBS • The WBS: • Gives you a somewhat complete list of tasks • Later, this can be a checklist to show how much is still to be done, and how much is done • Allows you to easily assign work to team members • Requires you to solidify things that are still vague, even after requirements analysis • Generating a WBS enables you to methodically decompose the work, exposing new risks and resource requirements

WBS Process Overview • The WBS process is basically as follows: • The WBS is normally created from the top down • The estimates are created at the bottom • The estimates are summed from the bottom up • The totals at the top are used as input for the schedule

Creating a WBS: Top-down • The top-down approach: • Start with the project’s overall goal • Decompose the goal into deliverables • Decompose the deliverables into modules … • When you are finished you have tasks • Tasks should be a few days work or less • This is an iterative technique to creating a WBS • In XP projects, the WBS iterations might produce only a part of the next level while requirements are still being worked out • However, it should produce some tasks, so that work can begin • It is a good idea to create the WBS as a group • This can prevent important activities from being missed, and can add a level of peer evaluation to the process

When is a WBS done? • Since WBS is iterative, it could go on forever • There are guidelines for what is enough: • Status/completion is measurable • The activity/task is bounded • The activity/task has a deliverable • Time and cost are easily estimated • Activity/task duration is within acceptable limits • Work assignments are independent

Status/Completion is Measurable • Project managers will ask team members about status • Status is generally how close they are to completion • Activities: • Status of an activity is the ratio of completed tasks • e.g. I’m finished 35 of 55 tasks, so I’m 64% done • Completion of an activity is when all of its tasks are complete • Tasks • Status of a task is generally small enough to estimate • e.g. I’ve written all the code for the class, and just need to test it, so I’m about 50% done • Completion of a task should take a few days or less

The Activity/Task is Bounded • The starting and ending points of an activity should be well-known • How do you get started on the activity? What task to do first? • How do you finish the activity? What is the last task to be done? • e.g. Optimize the search engine • Tasks: • Determine from customers the expected wait time • Measure existing search engine for comparison • Examine code for potential slowdowns • Make changes where possible • Investigate compiler options which could improve performance • Update build file to use new compiler options • Deploy search engine to test server • Measure new search engine performance • Verify that search engine meets customer criteria • Deploy search engine in public server • Ask customer for review and acceptance

The Activity/Task Has a Deliverable • All activities should produce something • High-level activities produce the deliverables outlined in the requirements • e.g. Source code distribution, user manual, DVD media • Lower-level activities can produce other ‘deliverables’ • e.g. AI engine, device API for bar code readers, a customer class

Time & Cost are Easily Estimated • The less work is involved in an activity, the easier it is to estimate • When we get down to task level, it should be possible to accurately estimate time and cost • Time: It is less work, so estimates should be accurate, particularly when the task is similar to something else done recently • e.g. Write the code to manage persistence of customers to/from the database • This is similar to other persistent code you have (or will) write, so can be accurately estimated • Cost: You will know if there are additional costs required • e.g. Licenses for an IDE, books, training • We’ll deal with estimation separately

Activity/Task Duration is Within Acceptable Limits • Activities can take a very long time • However, tasks (the lowest level of decomposition) should be limited in duration • Generally, less than 1-2 weeks is considered acceptable • This is something that can be easily tracked • Also, if something goes wrong, things should not go to far off track • e.g. A 5 day task takes 7 days to complete • e.g. A 10 day task was a waste of time, and needs to be re-thought

Work Assignments are Independent • When a task is assigned to a team member, it should be possible for that team member to complete without further instructions • e.g. A team member should not be meeting daily with a manager or customer while working on a 10 day task • A team member working on a task should have all they need when they begin • A team member building on another task’s deliverables should start the task after the other task’s deliverable is ready • e.g. • A team member is working on improving the design for the 3D graphical engine • When this is complete, another programmer might want to incorporate her code into the graphics engine • This should not be done until the graphics engine is complete (with respect to the re-design)

Common Sense with WBS • Another way to ensure a WBS is complete is to use common sense • If you were to tell a young child to brush their teeth, they might need more detailed instructions • Get your toothbrush and the toothpaste • Put a little bit of toothpaste on the toothbrush • Brush the front, back, tops, bottoms, and sides of your teeth • Spit into the sink • Rinse out your mouth with some water • Put away the toothbrush and toothpaste • However, team members have done similar tasks before • If you say brush your teeth to an adult, they know what to do • Not only is it a waste of time to go into more detail, it is also insulting • This is called micromanaging

Activity/Task Names • Activities and tasks should have active names: • e.g. Create a chart of search engine performance • e.g. Develop a sales pattern for the sales team • e.g. Establish a set of coding standards

Task Sequencing • In the WBS, tasks and activities are listed in chronological order where possible • e.g. In the setup development environment activity: • ‘Purchase new computers’ must come before ‘Install IDE’ • However, specific task ordering will be done in the schedule later

Estimation

How to Estimate Software • How do you estimate how long it will take to develop a project? • Let’s say you have an assignment due in 2 weeks • You want to decide when to work on it • You want to fit that into your schedule • To do so, you need to know how many hours it will take

Estimation • Estimation involves using the following information in order to make an educated guess about time or resource requirements: • Knowledge of the work required (expertise) • Ask people who know how long it should take • Group knowledge • Coming up with estimates as a group is no substitute for expertise, but sometimes expertise is not available • Advice from a group is generally more reliable than advice from an individual • Prior experience • e.g. It previously took 8 minutes to copy, print, seal, stamp, and address 1000 brochures • It should take about 80 minutes to get 10,000 brochures ready • Historical data • e.g. The team has worked on 3 other projects, which were all 25-50% over-budget on time • Therefore, expect them to go over their own estimates by a similar factor

Estimation • Who creates estimates? • Technically, the project manager does • However, the PM is not an expert in all areas (e.g. deliverables) • Thus, the ‘experts’ need to be consulted when creating estimates • The experts are the people who might be asked to do the work • It is wise to get a second (or third) opinion, to offset estimate bloat and over-optimism • Estimates should start from the task level, since they are easy to estimate

Estimates as Ranges • If you don’t know what the customer wants, so you can’t yet make an informed decision This house should take about 4 months to build. Good! We have a deal. Contractor Customer

Estimation Units • There are several units in estimation: • Total time • e.g. It should take 3-4 weeks, with a most likely estimate of 18 days • This makes it obvious when the project should be completed • Human resource utilization (effort) • e.g. It should take 2-3 person-months, with a most likely estimate of 10 person-weeks • This way, you can see how adding people to the project will affect its duration • Lines of code (size) • e.g. It should be around 50,000 lines of code • This figure can then be used for other estimates, such as total time • However, few developers count lines of code anymore, so this is not very common • Also, not all lines of code are created equal • Function points (size/difficulty) • An estimate of the number of inputs, outputs, files, database tables, etc. that an application will require • e.g. This should have 6 inputs of low complexity (x3), 2 inputs of medium complexity (x4), and … for a 286 function point score

Creating Estimates • Estimates are created at the bottom, and work their way up • Tasks can be estimated easily • The activity durations can be computing by taking the sum of the task durations • This allows us to estimate activities that are cross-disciplinary • However, minor deviations in task durations can quickly add up to major deviations in activity duration • This is exactly why you use an estimate range • If your range includes the actual duration, it will be difficult to say that you were wrong • Creating an accurate estimate from day one is impossible

Case Study PathFinder 2.0

Getting an Initial Estimate Barb: Having gathered requirements for the PathFinder 2.0 project, how long do you think it will take? Tyrone: I’ve been thinking about this quite a bit, and I’ve come up with about 4 months. Barb: That long?! I told the board of directors it would be ready in about a month! Tyrone: We might be able to save some time here and there. Let me look at it again. Barb: Good. Let’s aim for 1 month.

After Some Thought… • Having examined the project further, Tyrone was able to cut corners by shortening the design duration, but still not enough to fit the 1 month schedule • However, Barb was so outraged by his original estimate, that he didn’t have the courage to say anything to her about the slip • Perhaps the team will pull it together with the tighter budget

3 Weeks Later Tyrone: Barb, the team has been putting loads of overtime into this project, but we’re not even close to being finished. We just plain need more time. Barb: That’s disappointing Ty. Ok, let’s aim for 3 months total. That should be more than enough time, given the extra hours your team is putting in. Tyrone: Yes, I think so.

In the Meantime… • Many aspects of the software have been hacks and the result is really ugly, low-quality code • The code is being constantly re-worked due to the lack of a decent design • The development is taking longer than expected, since team members have a tough time understanding the code with all the hacks and poor design • However, since they are in such a rush, they do not feel there is enough time to fix the hacks or refactor the code to represent a better design • The result is slow development and unreliable code • To meet the schedule, Tyrone increases development time well into the QA time

2 Months Later Tyrone: We’re finished coding. This week will be for quality assurance. Barb: Good, but I thought that QA was scheduled for 3 weeks? Tyrone: It was, but we had to finish development.

The result… • The final code was very poor quality, due to: • Poor design • Rushed development, which included many: • Bugs • Hacks

The result… • The reduced QA time meant that the team only found the most obvious bugs and were able to fix them by the deadline • When the customer saw the finished product, it crashed twice and produced the wrong output on one occasion • The customer requested that the project be more thoroughly tested • After 6 more weeks, the product still had some bugs, but was finally useable • However, the customer was no longer interested, since: • So much time had passed (5½ months), they lost interest • Market share had already been acquired by another competing product • They lost confidence in the team due to the poor quality product • Not to mention management’s confidence in Tyrone • Is this entirely Tyrone’s fault?

Summary : • The creation of WBS has only a few rules : • It is created with the help of a team • The 1st level is completed before the project is broken down further • Each level of the WBS is a smaller segment of the level above • Work towards the project deliverables • Work not in the WBS is not part of the project • Break down the project into work packages or activities that : • Can be realistically and confidently estimated • Cannot be logically further subdivided • Can be completed quickly (few days) • Have a meaningful conclusion and deliverable • Can be completed without interruption (without the need for more information)

An Introduction Planning & Scheduling

What is a plan? • A project plan is a network of dependent and independent tasks • A plan may also contain descriptions of persona • A persona is a fictitious representation of a real person • The plan may also include assignments of tasks to various persona • An important part of the project plan is the network diagram, which shows task flow and task dependencies

What is a schedule? • A schedule is a description of start and end times for all the WBS’ tasks • The schedule accommodates the plan • The schedule specifies all dates in terms of offsets from the start date • Ideally, the start date is a parameter which can be changed if the project start is delayed • This way, real dates can be seen • However, dates are not hardcoded so they can be easily changed • An important part of the schedule is the Gantt chart

Planning Planning & Scheduling

Begin End Network Diagram • A network diagram shows task/activity flow • Flow from one task to another may indicate: • Dependencies between the tasks • Chronological ordering between the tasks • Parallel task flows indicate task independence • It is not necessarily the case that tasks may be done in parallel, but it is possible Example :

Task/Activity Dependencies • Finish to start: One task/activity must finish before the other task/activity can start • e.g. ‘Order PCs’ must finish before ‘Install IDE’ begins • Start to start: One task/activity must have started before the other task/activity can start • e.g. ‘Design AI module’ must start before ‘Implement AI module’ begins • Start to finish: One task/activity must start before another task/activity can finish • e.g. ‘Ensure successful handoff to Team B’ cannot finish until ‘Team B begins work’ • Finish to finish: One task/activity must finish before another task/activity can finish • e.g. ‘User documentation screenshots’ must finish after ‘User interface implementation’

Network Diagram • Many notations exist, but a UML behaviour diagram is common • Here is an example network diagram showing start to finish dependencies Make deal with Susan Carlson Submit budget approval form to accounts payable Register for seminars on the finalized dates … Collaborate with project managers to find available times for employees Finalize trip time with employees Have employees sign waivers …

Personas • A persona is a fictitious representation of a real person • e.g. Java Developer A • This could match either George Smith or Arin Kumal • The plan will not mention people by name, however • A persona has certain skills • e.g. Familiar with OOP, Java, modular programming, coding standards, documentation, etc. • A persona can be assigned responsibilities, such as tasks from the WBS

Why not use real names? • People might not be available when the project begins • A project may go over schedule • Our project start may be delayed • Replacement people will resent not being the first choice if they see the other names • The fact is, many project managers create a plan with real people in mind • They may write out somewhere else who Java Developer I is, and who Network Admin is, etc.

Task Assignment • Another part of the project plan is the task assignment • This includes a description of all team members • These are normally personas • The persona description will include a reasonable set of expected skills that the real person should have • For each task, a team member is assigned • This is done after the network diagram, so that work can be distributed evenly

Task Assignment • User interface expert • Java developer I • Java developer II • Database developer • Database admin • Server admin

Schedules Planning & Scheduling

Schedules • A schedule is an implementation of the project plan • However, in industry lingo, a project plan document normally includes the schedule • A common schedule representation is a Gantt chart • A Gantt chart is a graphical depiction of the task flow, with dates • Dates are shown as the x-axis, so questions about start/end times can be answered • e.g. Relative start times of parallel tasks • e.g. Completion of all of an activity’s tasks • e.g. Chronological dependencies between tasks • However, other formats are possible: • A calendar, showing tasks started, active, and completing • A list of task descriptions, including start and expected end dates

Gantt Charts • Visual representation can help when a project manager needs an overview: November December September October User Interface Prototype Registration Dialog …etc… Registration Persistence Code to Gen. Password MD5 …etc…

A Practical Guide Planning & Scheduling

Creating a Schedule • In practice, a PM will use a project management tool to do much of their work: • Microsoft Project • Gantt Project • Open Workbench • OmniPlan • All of these applications let you easily create: • Gantt charts • Task descriptions • Calendar views

Work Breakdown Structures