![](media/image1.png){width="1.125in" height="1.0118055555555556in"}

Guidelines for a WBS

**Number:** 580-GL-031-03 **Approved By: (signature)**

**Effective Date:** August 31, 2007 **Name:** John Donohue

**Expiration Date:** August 31, 2011 **Title:** Assoc**.** Chief, ISD

**Responsible Office:** 580/Information Systems Division (ISD) **Asset
Type:** Guideline

######### Title: Guidelines for a WBS PAL Number: 1.2.4.1

  -------------- --------------------------------------------------------
  **Purpose**    The purpose of this document is to provide uniform
                 guidance for developing the mission software project's
                 Work Breakdown Structure (WBS), which is a mechanism
                 used to formulate the project plan, report progress
                 against the plan, and facilitate communication of and
                 commitment to the plan among members of the project team
                 and ISD management.

  -------------- --------------------------------------------------------

  -------------- --------------------------------------------------------
  **Scope**      This guideline should be used by all mission software
                 projects and should align with the Software Project
                 Planning process. It should also align with the process
                 used for the Project Monitoring and Control.

  -------------- --------------------------------------------------------

+-------------+--------------------------------------------------------+
| **          | The following are in no particular order and are       |
| Guideline** | numbered for reference purposes only:                  |
|             |                                                        |
|             | 1.  A project WBS may be tailored and constructed to   |
|             |     reflect unique characteristics of the product      |
|             |     effort as appropriate.                             |
|             |                                                        |
|             | 2.  The WBS is a tree-structured, activity-oriented    |
|             |     list of all work needed to meet the requirements   |
|             |     of the project.                                    |
|             |                                                        |
|             |     a.  The WBS is organized by product or service     |
|             |         such that activities for a product (or         |
|             |         sub-product or service) are normally grouped   |
|             |         within a section of the WBS.                   |
|             |                                                        |
|             |     b.  The WBS provides a mechanism for the           |
|             |         collection of cost and schedule data on a      |
|             |         product-by-product (or service) basis, as well |
|             |         as for the project overall.                    |
|             |                                                        |
|             |     c.  It provides a framework for identifying        |
|             |         material, services, schedules, staffing, and   |
|             |         costs associated with each work element of the |
|             |         project.                                       |
|             |                                                        |
|             |     d.  It addresses all work required, including      |
|             |         organizing, planning, monitoring, controlling, |
|             |         and reporting the status of all work elements  |
|             |         across the project.                            |
|             |                                                        |
|             |     e.  *The WBS is used as the set of activities to   |
|             |         be scheduled for the project. Estimation of    |
|             |         resources required is also frequently based on |
|             |         the work defined in the WBS. If there is work  |
|             |         you must do that is not reflected in your WBS, |
|             |         it is likely to have no schedule or resources. |
|             |         It will probably result in a schedule and/or   |
|             |         cost variance.*                                |
|             |                                                        |
|             | 3.  The WBS is defined based on project requirements   |
|             |     during the project planning process. Use the list  |
|             |     the WBS checklist at                               |
|             |                                                        |
|             | > <http://s                                            |
|             | oftware.gsfc.nasa.gov/toolsDetail.cfm?selTool=1.2.4.0> |
|             | >                                                      |
|             | > as a checklist for your WBS and include any item     |
|             | > that is appropriate for your project. The checklist  |
|             | > provides a list of most high-level activities that a |
|             | > project may have to perform. It includes a WBS       |
|             | > Dictionary to assist in selecting the appropriate    |
|             | > items. Use the example of a project WBS in Addendum  |
|             | > A as a guide in creating, formatting, and            |
|             | > documenting your WBS. Your WBS will have many        |
|             | > different WBS items, but will need many of the same  |
|             | > items as in the example. Also see Resources for a    |
|             | > link to the Flight Software Branch (FSB) WBS         |
|             | > Standard.                                            |
|             |                                                        |
|             | 4.  Although the WBS is product or service based,      |
|             |     remember to include management and process         |
|             |     activities (e.g., reporting, integration,          |
|             |     training, requirements management) that must be    |
|             |     accomplished to meet the project requirements.     |
|             |     These must be included as WBS elements or they     |
|             |     will not be scheduled and they will have no        |
|             |     resources allocated to them. Some of the           |
|             |     management processes that must be covered are:     |
|             |     planning; monitoring and control; measurement and  |
|             |     analysis; CM; PPQA; requirements management;       |
|             |     acquisition management; and risk management.       |
|             |                                                        |
|             | 5.  Organize the specific work elements that must be   |
|             |     accomplished into successively smaller work        |
|             |     elements such that:                                |
|             |                                                        |
|             |     a.  The subdivisions (or decomposition) of work    |
|             |         elements are referenced in terms of levels.    |
|             |                                                        |
|             |     b.  The highest levels usually reflect the major   |
|             |         deliverable work areas or phases of the        |
|             |         project.                                       |
|             |                                                        |
|             |     c.  Higher WBS levels are sub-divided to a         |
|             |         sufficient level of detail (depth) to permit   |
|             |         accurate planning and monitoring without undue |
|             |         maintenance, data collection and reporting     |
|             |         burden. High risk activities (or those         |
|             |         requiring higher accuracy of planning and      |
|             |         estimation) should be driven to a lower level  |
|             |         of detail. A sufficient level of detail is     |
|             |         usually at least one level lower than          |
|             |         management reporting requirements.             |
|             |                                                        |
|             |     d.  To break each WBS item down further, identify  |
|             |         the steps defined for each applicable process  |
|             |         and include the steps as lower level WBS items |
|             |         where appropriate.                             |
|             |                                                        |
|             |     e.  Ensure that each WBS element summarizes all    |
|             |         WBS elements below it and that each WBS        |
|             |         element has only one parent.                   |
|             |                                                        |
|             | 6.  Each element should have further explanatory       |
|             |     information about it in a WBS Dictionary with task |
|             |     descriptions.                                      |
|             |                                                        |
|             | 7.  A unique labeling scheme for each WBS element      |
|             |     should be used that clearly denotes the            |
|             |     hierarchical nature of the WBS. Labeling is        |
|             |     normally accomplished through a hierarchical       |
|             |     numeric structure.                                 |
|             |                                                        |
|             | 8.  Each WBS element should have a documented          |
|             |     completion criteria that can be used to assess     |
|             |     whether or not all aspects of the work element     |
|             |     have been completed (i.e., all work requirements   |
|             |     of the sub-product, product, or service have been  |
|             |     successfully accomplished.)                        |
|             |                                                        |
|             | 9.  The WBS should be used as the basis for your       |
|             |     schedule. Each WBS element is scheduled and        |
|             |     assigned resources. The cost can then be estimated |
|             |     based on the work elements defined in the WBS.     |
|             |     This planning is iterative. As the planning        |
|             |     process progresses, detailed scheduling,           |
|             |     estimation, and costing may result in              |
|             |     modifications, deletions, or additions to the      |
|             |     initial set of WBS elements.                       |
|             |                                                        |
|             | 10. Because the WBS is not just for planning, consider |
|             |     how it will be used to facilitate reporting,       |
|             |     monitoring, and controlling activities on the      |
|             |     project. Adjust the WBS structure to facilitate    |
|             |     the reporting and monitoring activities.           |
|             |                                                        |
|             | 11. Each WBS element should be mapped to the           |
|             |     individual or group within the project or task     |
|             |     that is responsible for completing the work. This  |
|             |     mapping should be noted in the Product Plan. Each  |
|             |     WBS element should also have appropriate time      |
|             |     keeping and accounting structures defined.         |
|             |                                                        |
|             | 12. The WBS should be available to appropriate         |
|             |     involved parties during planning -- to solicit     |
|             |     input **and** to document commitment.              |
|             |                                                        |
|             | 13. Cost and schedule data should be available for     |
|             |     appropriate WBS elements/level (sufficient detail  |
|             |     and "roll-ups"/summary, but not to the lowest      |
|             |     level of the WBS)                                  |
+-------------+--------------------------------------------------------+
|             |                                                        |
+-------------+--------------------------------------------------------+

  ------------- --------------------------------------------------------------------------- -----------------------------------------------------------------
  **Tools and   The following tools are available. Others may exist for the local project.  
  Templates**                                                                               

                **Name**                                                                    **Description**

                [WBS                                                                        Provides a list of WBS elements that will normally cover all
                Checklist](http://software.gsfc.nasa.gov/toolsDetail.cfm?selTool=1.2.4.0)   aspects of a development project. See
                                                                                            <http://software.gsfc.nasa.gov/toolsDetail.cfm?selTool=1.2.4.0>

                [FSB WBS                                                                    General high level WBS applicable to all FSB Software Projects.
                Standard](http://software.gsfc.nasa.gov/AssetsApproved/PA1.2.4.1.1.xls)     
  ------------- --------------------------------------------------------------------------- -----------------------------------------------------------------

+-------------+-------+--------+---------------------------------------+
| **Change    | ####  | #####  | **Description of Improvements**       |
| History**   | ## Ve | # Date |                                       |
|             | rsion |        |                                       |
+-------------+-------+--------+---------------------------------------+
|             | ##### | ##     | Initial approved version by CCB       |
|             | # 1.0 | #### J |                                       |
|             |       | une 20 |                                       |
|             |       | , 2005 |                                       |
+-------------+-------+--------+---------------------------------------+
|             | ##### | #      | Example WBS replaced with a better    |
|             | # 2.0 | #####  | WBS checklist in response to DCR 31   |
|             |       | 4/2/07 |                                       |
+-------------+-------+--------+---------------------------------------+
|             | ##### | ##     | DCR 48 - WBS Checklist replaced with  |
|             | # 3.0 | #### 8 | a pointer to the WBS Checklist web    |
|             |       | /28/07 | page to avoid having to update the    |
|             |       |        | checklist in two places.              |
+-------------+-------+--------+---------------------------------------+

**Addendum A**

**Example WBS for a Project**

Use the example shown as a guideline in possible WBS tailoring as you
develop and format your WBS. You will need many of the WBS elements
shown below. Some of the WBS elements in this example you will not need.
In addition, you will likely need additional WBS elements that are
specific to your project. Make sure that ALL work you must do is
reflected in your WBS.

  ---------------------------------------------------------------------------
  **PROJECT WORK                           
  BREAKDOWN                                
  STRUCTURE AND                            
  DATA                                     
  DICTIONARY**                             
  --------------- ------------------------ ----------------------------------
  1 MANAGEMENT                             

  1               Software Management      Technical and management oversight
                                           by project of all aspects of all
                                           software to be developed

  1.1             Plan Software            

  1.1.1           Plan Technical Approach  Plan the technical approach

  1.1.1.1         Refine Project WBS       Development and refinement of WBS

  1.1.1.2         Perform Init             Make-buy studies for technical
                  Make/Buy/Reuse Analysis  approach

  1.1.1.3         Refine Life-Cycle for    Establish project life cycle
                  project                  

  1.1.1.4         Plan Acquisitions /      Identify and schedule acquisitions
                  Receivables              and receivables

  1.1.1.5         Plan Life Cycle Phases   Plan each life cycle phase

  1.1.1.6         Plan Builds              Identify basic build contents and
                                           schedule

  1.1.2           Plan Management Approach Plan the management approach

  1.1.2.1         Establish Organization   Establish organizational structure

  1.1.2.2         Plan Metrics Approach    Establish the metrics approach
                                           with objectives, metrics, and
                                           collection/storage approach

  1.1.2.3         Plan Stakeholder         Identify stakeholders, their
                  Approach                 roles, and monitoring approach

  1.1.2.4         Plan Data Mgmt Approach  Identify what data will be kept,
                                           who will keep it, where it will be
                                           kept, and how it will be monitored

  1.1.2.5         Plan Training Approach   Identify what training is needed,
                                           by whom it is needed, how it will
                                           be obtained

  1.1.2.6         Plan Risk Mgmt Approach  Establish the risk strategy,
                                           identify the initial risks,
                                           classify the risks and place them
                                           in the risk tool, and develop
                                           mitigation plans

  1.1.3           Estimate / Re-estimate   Estimate (and re-estimate) project
                  Cost                     costs

  1.1.4           Plan / Revise Staffing   Plan (and replan) the project
                                           staff

  1.1.5           Plan/Revise Schedule     Establish (and revise) the work
                                           schedule

  1.1.8           Plan / Revise Build      Create (and maintain) the Product
                  Contents                 Plan

  1.2             Monitor & Control        Monitor and control the project
                  Activities               activities

  1.2.1           Install Metrics Tools /  Install the metric tools and
                  ID Repositories          repositories as needed

  1.2.2           Load Plan / Revised Plan Load planned data (and revisions)
                  Data                     into spreadsheet tools

  1.2.3           Collect Metrics Actuals  Collect and store metric data
                                           monthly

  1.2.4           Assess Plan vs. Actuals  Compare actual data to plan
                                           monthly

  1.2.5           Analyze Technical        Analyze metric data monthly
                  Metrics                  

  1.2.6           Obtain TL\'s Status      Get status from task leads weekly

  1.2.7           Review Action Items      Review issues and action items on
                                           a weekly or monthly basis

  1.2.8           Review / Update Risks    Review the risks and update status
                                           at least monthly

  1.2.9           Monitor DM Collections   Verify that data management
                                           activities are ongoing

  1.2.10          Track Receivables        track receivables against the
                                           schedule

  1.2.11          Prepare and Report       Track issues and actions, and
                                           report status to stakeholders

  1.2.11.1        Track and Resolve Issues Identify, track, and resolve
                  and Actions              issues and actions

  1.2.11.2        Status To Code 400       Report monthly to Code 400 project
                  Project                  

  1.2.11.3        Status To Branch Head    Report monthly to the Branch
                                           Management

  1.2.11.4        Status To Code 500       Report quarterly to the Code 500
                  Champion                 Champion

  1.2.11.5        Lessons Learned to       Identify lessons learned bi
                  repository               annually

  1.3             Manage Configurations    Perform CM activities

  1.3.1           Plan CM Approach         Plan the CM approach (you may
                                           tailor an organizational approach)

  1.3.1.1         Identify Controlled      Identify the controlled items
                  Items                    

  1.3.1.2         Charter an Internal      Set up an IRB (like a CCB), how it
                  Review Board (IRB)       works, who is on it, and when it
                                           meets

  1.3.2           Create / Update CM Plan  Write (and maintain ) the CM Plan

  1.3.3           Select / Instantiate CM  Select, obtain, and install the CM
                  Tools                    tools to be used

  1.3.4           Conduct IRBs             Conduct IRB meetings on a regular
                                           basis to assess and manage
                                           requirement change requests, and
                                           to assess, assign, track, and
                                           disposition DCRs

  1.3.5           Configure / Baseline CIs Configure and baseline the
                                           configuration items

  1.3.6           Audit CI Configurations  Conduct and support CI audits

  1.3.7           Address CM Audit         Address audit findings
                  Findings                 

  1.4             Support Quality          Perform SQA support activities
                  Assurance                

  1.4.1           Negotiate Activities     Negotiate for SQA activities with
                  with Code 300            Code 300

  1.4.2           Review SQAP              Review the Code 300 SQAP

  1.4.3           Schedule FY Proc/Prod    Schedule process and product
                  Assessments              quality assessments

  1.4.4           Prepare for QA audits    Prepare for SQA audits

  1.4.5           Address QA Audit         Address audit findings
                  Findings                 

  1.5             Stakeholder Coordination Perform stakeholder coordination

  1.5.1           Negotiate Commitments    Negotiate with stakeholders for
                                           commitments

  1.5.2           Provide Liaison &        Provide Liaison & Support as
                  Support as needed        needed

  1.5.3           Monitor/Verify S/H       Monitor/Verify S/H Involvement
                  Involvement Monthly      Monthly

  1.5.4           Monitor/Verify S/H       Monitor/Verify S/H Commitments
                  Commitments Monthly      Monthly

  1.6             Manage Acquisitions      

  1.6.1           Determine Acquisition    Identify all hardware and software
                  Needs                    that will be procured by the
                                           project to the extent possible.

  1.6.2           Select Suppliers         Identify the desired supplier for
                                           each item to be procured. Supplier
                                           may be sole source (justification
                                           needed) or selected based on item
                                           availability, cost, or other
                                           reasonable criteria.

  1.6.3           Issue Procurements       Create or support the creation of
                                           procurement documents based on the
                                           governing processes from the
                                           Mission Project or the Procurement
                                           Office, as applicable.

  1.6.4           Accept Products          Receive hardware or software;
                                           verify it is the correct item in
                                           the proper quantity, and in good
                                           condition; install the item in the
                                           appropriate environment.

  1.6.5 -- 1.6.13 Process Additional       Assess and process any additional
                  Procurement Needs        procurement needs, quarterly at a
                                           minimum

  **2                                      
  ENGINEERING**                            

  2               Engineering              

  2.1             Systems Engineering      Perform Systems Engineering

  2.1.1           Develop Software System  Develop the project software
                  Concept                  concept

  2.1.2           Define Interface         Receive and review all ICDs
                  Requirements             related to the project software

  2.2             Dev/Test Environment Eng Perform development and test
                                           environment engineering

  2.2.1           Configure Tools          Configure Development Tools needed
                                           by the project

  2.2.2           Integrate Proc F Test    Integrate Proc F Test String
                  String                   

  2.2.3           Integrate Main Processor Integrate Main Processor Test
                  Test String              String

  **3 SYSTEM                               
  DEVELOPMENT**                            

  3               Subsystem Development    

  3.1             Architecture Design      Perform architecture design

  3.1.1           Define Requirements      Meet Stakeholders to understand,
                                           analyze, and allocate level 3
                                           requirements to subsystems;
                                           baseline level 3 requirements,
                                           conduct the Software Requirements
                                           Review (SRR), and capture and
                                           track SRR RFAs

  3.1.2           Develop Preliminary      Develop the preliminary design and
                  Design Pkg               conduct the PDR

  3.1.3           Develop Detailed Design  Develop the critical design and
                  Pkg                      conduct the CDR

  3.2             Develop Main Processor   
                  Subsystem                

  3.2.1           Develop Main Processor   Meet Stakeholders to understand,
                  Level 4 Requirements     analyze, and define level 4 Main
                                           Processor requirements, allocate
                                           level 4 requirements to tasks, and
                                           conduct Main Processor
                                           requirements peer reviews

  3.2.2           Develop Main Processor   Develop the Proc A, Proc B, Main
                  Software                 Processor, and Common Software
                                           builds and develop the
                                           documentation

  3.2.2.1         Proc A Build 1.0         

  3.2.2.2         Proc A Build 2.0         

  3.2.2.3         Proc A Build 3.0         

  3.2.2.4         Create/Update Proc A     
                  User's Guide             

  3.2.2.5         Proc B Build 1.0         

  3.2.2.6         Proc B Build 2.0         

  3.2.2.7         Proc B Build 3.0         

  3.2.2.8         Create/Update Proc B     
                  User's Guide             

  3.2.2.9         Main Proc Main Proc      
                  Build 1                  

  3.2.2.10        Main Proc Main Proc      
                  Build 2                  

  3.2.2.11        Main Proc Main Proc      
                  Build 3                  

  3.2.2.12        Create / Update Main     
                  Processor User's Guide   

  3.2.2.13        Common SW Build 1        

  3.2.2.14        Common SW Build 2        

  3.2.2.15        Create / Update Common   
                  SW User's Guide          

  3.2.3           Develop Proc C Subsystem 

  3.2.3.1         Develop Proc C Level 4   Meet Stakeholders to understand,
                  Requirements             analyze, and define level 4 Proc F
                                           requirements, allocate level 4
                                           requirements to tasks, and conduct
                                           Proc C requirements peer reviews

  3.2.3.2         Develop Proc C Software  Develop the Proc D, Proc E, and
                                           Proc F builds and develop the
                                           documentation

  3.2.3.2.1       Proc D Build 1.0         

  3.2.3.2.2       Proc D Build 2.0         

  3.2.3.2.3       Create/Update Proc D     
                  User's Guide             

  3.2.3.2.4       Proc E Build 1.0         

  3.2.3.2.5       Proc E Build 2.0         

  3.2.3.2.6       Create/Update Proc E     
                  User's Guide             

  3.2.3.2.7       Proc F Build 1.0         

  3.2.3.2.8       Proc F Build 2.0         

  3.2.3.2.9       Proc F Build 3.0         

  3.2.3.2.10      Create/Update Proc F     
                  User's Guide             

  3.2.4           Develop Diagnostic       
                  Software                 

  3.2.4.1         Develop Diagnostic       Meet Stakeholders to understand,
                  Software Requirements    analyze, and define diagnostic
                                           requirements, allocate
                                           requirements to tasks, and conduct
                                           requirements peer reviews

  3.2.4.2         Develop and Test         Develop and test diagnostic
                  Diagnostic Software      software

  **4 TEST                                 
  SOFTWARE**                               

  4               Test Software            

  4.1             Plan Test Program        Plan the overall test program

  4.1.1           Load L 4 Requirements    Put level 4 requirements into Req
                  into Req Tool            Tool

  4.1.2           Configure Test           Configure Test Environment for
                  Environment for Test     test

  4.1.3           Create Test Plan         Develop and update the test plan ,
                                           conduct plan walkthrough(s) with
                                           the Team, and obtain plan
                                           approvals

  4.2             Plan Build Test          Build the test scenarios and test
                  Scenarios and Procs      procedures for each build

  4.2.1           Proc A Build 1.0         

  4.2.3           Proc A Build 2.0         

  4.2.4           Proc A Build 3.0         

  4.2.5           Proc B Build 1.0         

  4.2.6           Proc B Build 2.0         

  4.2.7           Proc B Build 3.0         

  4.2.8           Main Proc Build 1        

  4.2.9           Main Proc Build 2        

  4.2.10          Main Proc Build 3        

  4.2.11          Common SW Build 2        

  4.2.12          Proc D Build 1           

  4.2.13          Proc D Build 2           

  4.2.14          Proc E Build 1           

  4.2.15          Proc E Build 2           

  4.2.16          Proc F Build 1.0         

  4.2.17          Proc F Build 2.0         

  4.2.18          Proc F Build 3.0         

  4.3             Build Verification Test  Conduct build tests and report
                  and Report               results for each build

  4.3.1           Verification Test Main   
                  Processor                

  4.3.1.1         Proc A Build 1.0         

  4.3.1.2         Proc A Build 2.0         

  4.3.1.3         Proc A Build 3.0         

  4.3.1.4         Proc B Build 1.0         

  4.3.1.5         Proc B Build 2.0         

  4.3.1.6         Proc B Build 3.0         

  4.3.1.7         Main Proc Build 1        

  4.3.1.8         Main Proc Build 2        

  4.3.1.9         Main Proc Build 3        

  4.3.1.10        Common SW Build 2        

  4.3.2           Verification Test Proc C 

  4.3.2.1         Proc D Build 1           

  4.3.2.2         Proc D Build 2           

  4.3.2.3         Proc E Build 1           

  4.3.2.4         Proc E Build 2           

  4.3.2.5         Proc F Build 1.0         

  4.3.2.6         Proc F Build 2.0         

  4.3.2.7         Proc F Build 3.0         

  4.4             Perform                  
                  System/Acceptance        
                  Testing                  

  4.4.1           Conduct Sys Test         Conduct a Test Readiness Review
                  Readiness Rev            for the software

  4.4.2           Validation Test System   Perform validation testing

  4.4.3           Acceptance Test System   Perform acceptance testing

  4.4.4           Conduct Accept Test      Conduct an acceptance test results
                  Results Rev              review

  4.4.5           Create System/Acceptance Complete the system acceptance
                  Test Report              test report
  ---------------------------------------------------------------------------