DePaul University

1. DePaul University Project Management I - Work Breakdown Structure Instructor: David A. Lash

2. PM Should Be Defined Process • Charter • Purpose • review and publish • SOW • A. Document goals, scope deliverables HL budget estimate • Review with Project board • Communication Plan • Document communication methods of various level • Review with project board, various stakeholders • Risk Strategy - A plan for managing risk & uncertainty • WBS - A tool for breaking down project into its component parts. • Project Plan • Execute HL Plan LL Plan

3. OVERALL PLANNING STEPS

4. What Is A WBS? • A tool for breaking down a project into its component parts. • Identifies all tasks in a project • Can be specified as chart form (figure 6.2) or outline form (figure 6.3) • It helps to: • Provide a detailed illustration of project scope - (doing WBS really helps understand scope of project) • Can help measure progress since, defines tasks in measurable units of work (defines work packages for workers.) • provides basis for team role definition • provides basis for cost estimates that includes equipment, labor, materials listed for each task

5. What Is A WBS? • Summary Tasks - includes several subordinate tasks. • Work Package - each separate tasks. Work Packages Summary Tasks

6. 3 Steps to WBS Development 1. Begin at The Top 2. Name all tasks needed to produce deliverables 3. Organizing the WBS (there are multiple ways to organize WBS.)

7. Step 1 - Begin at The Top • List the major deliverables or high-level tasks from the scope • might also include intermediate deliverables (if major and not an end-product) Landscape Project Design Lawn Fence Grass Shrubs

8. Step 2. Name all tasks needed to produce deliverables • For example put in grass might include • buy dirt & seed • spread dirt • spread seed • water for 2 weeks • Don’t worry about order of activities yet. • May need people closer to project tasks to help. • Can be difficult in new situations • for example, if never before executed a process or new technology use • May need to call team together to develop strategies for WBS development (high level)

9. Step 3 - Organizing the WBS There are multiple ways to organize WBS. (See example 6.5) Some things to consider • organize in a way closer to • development process • organize in a way easier to manage • organize in way meaningful to sponsors.

10. Some criteria for successful WBS 1. WBS broken down starting from top • Top down decomposition w/ each task lower a subset of above • Can use standard project management software • Make sure summary levels are meaningful

11. Some criteria for successful WBS 2. Work packages must add up to summary tasks • subordinate tasks should add up to summary task • Take care not to omit needed tasks 3. Each summary task must be named as an activity that produces a product • That is, no open ended task - • e.g., perform research - could go on for ever. • Better to name the products of the research (e.g., research new smelting technique to develop harder swords.) • No leaky or open ended tasks • bad: database - what does it mean? • Better: test the DB - Much clearer • For example 6.4 shows major deliverables of design, lawn and fence

12. More Criteria For Successful WBS 4. Provide an initial task description and exit criteria - When possible providing detail is very useful. It helps clarify task and gives a more uniform basis for review. - For example, Dig Trenches - dig approximately 45 trenches for fence about 20x12 inches deep. Implement Feature X - write and unit test feature X based on design. Review test results. 5. Formally Review WBS - Review the WBS with team members.

13. Sizing Work Packages Correctly • Keep work packages between 1-10 days long. • Too long and becomes its own project • Too small may be part of another task • Keep work packages short enough so not to span status meetings • If break a task down into sub-tasks usually 1 of 3 reasons to do so: • It is easier to estimate (perhaps less uncertainty) • Is is easier to assign - (Keep single people or areas accountable) • It is easier to track • If not one of these 3 reasons, consider not further breaking down task.

14. Other Sizing Guidelines • 8/80 Rule - No task should be smaller than 8 hours of labor or greater than 80 as a guideline. • Reporting Period Rule - Try to keep tasks shorter than the regular status meetings. (For example if weekly meetings, about 1 week long) • This can be difficult to achieve but if done so would be useful. • If its “useful” rule - breaking down tasks should make the management of project easier to estimate, assign or track.

15. More on Work Package Sizing • Keeping units small can help control the project. • Consider examples in book • Waste treatment plant had project budge > 500 Million • contractors required to report work packages no larger than 2 weeks or 50K • This made identification of problems and cost overruns quicker to find • Microsoft has huge projects but require developers to analyze details in 1/2 day to 3 day chunks • people personally commit to their schedules • Can help to greatly increase estimations

16. Building In Quality • Building quality into project can have a huge effect on its success • The later you find a problem the most expensive it is to fix. • Consider automobile manufacturing • Finding error in requirements VS development VS when the car is in the field • Need to ensure proper standards are set to judge the quality of the work.

17. WBS Summary • WBS • breaks projects into parts • WBS Provides the structure for the project • Discussed 3 steps to develop WBS • Begin at top • Name all the tasks needed to produce deliverables • Organizing the WBS • Discussed work package size