Deciding the work to be Performed (Work Breakdown Structure)
Goals of the Unit Understanding the transition from project goals to the project schedule Introducing the Work Breakdown Structure notation spm - 2014 adolfo villafiorita - introduction to software project management!2
Initiate Plan Execute & Monitor Close Assess Feasibility Formalize Goals Define Schedule Define Costs Monitor Goals, Cost and Schedule Collect Outputs Develop Kick Off Activities Close Release [Obtain Approval] Change Control & Configuration Management Quality Management Risk Management Human Resource Management
What is a WBS? A Work Breakdown Structure (WBS for short) is a (deliverable-oriented) hierarchical decomposition of the work to be executed by the project team to accomplish projects objectives and create the required deliverable spm - 2014 adolfo villafiorita - introduction to software project management!4
WBS Example 1 Software System 1.1 1.2 1.3 1.4 1.5 1.6 Configuration Management Main Requirements Mobile Client Development Appstore Deployment Dev. Tools Procurement User Manual 1.3.1 1.3.2 1.3.3 1.3.4 Detailed Requirements Architecture Code Tests 1.3.4.1 1.3.4.2 1.3.4.3 Unit Tests System Tests Integration Tests spm - 2014 adolfo villafiorita - introduction to software project management!5
WBS: Remarks Two formats Graphical tree (Vision, Graffle, LibreOffice,...) Textual outline (MS Word, Text Editor, Outliner,...) Uses a decimal numbering system to identify elements (Ex: 3.1.5) Shows is contained in relationships Does not show dependencies nor durations spm - 2014 adolfo villafiorita - introduction to software project management!6
Why is it useful? A WBS establishes the basis for: Defining the work to be performed in a project Showing how various activities are related to the project objectives Establishing a framework for defining, assigning, and monitoring work and costs Identifying the organizational elements responsible for accomplishing the work spm - 2014 adolfo villafiorita - introduction to software project management!7
WBS Rules of the Thumb Everything (and nothing else) is in place: The 100% rule: make sure all work items are there (product oriented WBS are better suited for this kind of rule) The ME rule (Mutually Exclusive rule): make sure there are no overlaps in the definition of the elements (see coupling, below) No need to make it balanced: all paths do not have to go to the same level Quality of the WBS is high (*) Coherence: tasks within a work package should have the same goal; Coupling: work package dependencies should be minimised, so that team members can work independently; Continuity: production work packages should be full-time to maximise efficiency; Cost: bottom level work packages should require between one man- week and one man-month of effort. (*) Criteria taken from the ESA standards for software development spm - 2014 adolfo villafiorita - introduction to software project management!8
When do you stop? Simple answer: at the work-package level (which, btw, could be composed of more elementary activities, which, however, you do not want to trace) However: how big is a work-package? According to DOD and NASA Guide to PERT COST : leaves of the WBS should be no more than 3 months of work or $100.000 of expenditure According to other standards: 1-2 weeks for 1-2 people Mind you though, the level of details depends on the size of the project... spm - 2014 adolfo villafiorita - introduction to software project management!9
WBS Types (1/3) Product WBS It develops according to the structure of the outputs that need to be produced It can start from a Product Breakdown Structure, when defined Process WBS It develops according to the phases in which a project is organized For instance: Requirements, Analysis, Design, Testing Hybrid WBS: both of the above It mixes process and product For instance: life-cycle phases at higher levels; component at lower levels spm - 2014 adolfo villafiorita - introduction to software project management!10
WBS Types (2/3) Organizational WBS and Geographical WBS Higher levels are organizational units Lower levels collect the work which is under the responsibility of a Unit. Can be useful for highly cross-functional projects Geographical WBS Higher levels are geographically distributed teams (e.g. NY team, Trento Team) Lower levels collect the work under the responsibility of a team Remarks: according to the PMBOK, these are not WBS s. In any case, they are less commonly used. spm - 2014 adolfo villafiorita - introduction to software project management!11
WBS Type (3/3) PWBS: Program (project) WBS, used to coordinate all projects (systems) PWBS - Program WBS Program Project A Project B Project C CWBS: Contract WBS, basis for subcontracting system development System A CWBS - Contract WBS System B Contract X System C (Used by NASA) Subsystem 1 Subsystem 2 Subsystem 3 spm - 2014 adolfo villafiorita - introduction to software project management!12
Product WBS Example Software System Requirements Document Architecture Document Front End Middleware Back End Site Templates Web Pages SQL Schema DB Data Admin Intf Dynamic Pages Static Pages spm - 2014 adolfo villafiorita - introduction to software project management!13
Process WBS Example System Development Requirements Analysis Analysis and Design Coding Testing Cycle 1 Cycle 2 Integration Scenarios Analysis Security Reqs. Analysis Supportability Requirements Analysis System Test Acceptance Test spm - 2014 adolfo villafiorita - introduction to software project management!14
WBS Example (MIL-HDBK-881)
WBS Dictionary A WBS dictionary helps further specify the entries of a WBS It might contain title, number, detailed description of the element, quantities, associated work, contractual items Rules of the thumb: it can be done for each entry in the tree. follow the definition: increase the details as you move down the tree a good practice is doing it for the leaves (work-packages) spm - 2014 adolfo villafiorita - introduction to software project management!16
WBS Dictionary Work package number Work package title Activity type Participant number Participant short name Personmonths per participant 1 Start date or starting event: Month 1 Case Study Requirements and Experimentation Site Assessment RTD 1 2 3 4 5 6 7 8 P1 P2 P3 P3 P4 P5 P6 P7 1 0 0 9 6 0 2 0 Objectives Description of work Deliverables Milestones Task 1. Task 2.... D1.1. D1.2. M1.1. M1.2.