This is the third article in a series that discusses the most critical steps necessary for a successful program. The first critical task, the need to develop a complete set of high level performance requirements as the initial step, was discussed in January. Critical Task No. 1 has different names but is commonly referred to as either a Mission Need Statement (MNS) or Critical Requirements Document (CRD). The second critical task for a successful program, known as a Business Case Analysis (BCA), was discussed in February.
This article focuses on the third critical task required for a successful program: the development of a complete and accurate set of project work tasks and the schedules and cost estimates for each of them. These program components are required to establish a final baseline for a program. Information developed for the BCA is frequently used to establish the “initial” or preliminary baseline for a program. This third critical task will ultimately determine if a program is successful or unsuccessful.
If the program, system, or service is not accomplished within the base-lined costs and schedules, it will be deemed “unsuccessful” by many, even if it provides all of the required services or technical performance. There are many reasons for this assessment but the primary reason is that some or most of the benefits projected for the program will likely not be achieved if the program is not accomplished within the base-lined costs and schedules.
For example, if the program schedule is delayed, then the realized benefits or services decrease because of the reduced “service” time of the program. Similarly, if the program is fielded on time but it has cost growth, then the net difference between the base-lined costs and the projected benefits decreases and the program could actually result in a negative benefit-to-cost value. Other negative results that can result if the program deployment is not accomplished within the approved schedule are that the program technology may be overcome by newer technology or the original performance requirements may no longer be valid.
The first step of this critical task is to develop a Work Breakdown Structure (WBS) for the program.
What is a WBS?
A program WBS is a categorized structure and list of all significant tasks required for the program, regardless of the size, scope or complexity of the program. A program WBS should be structured to address the following types of work task information:
- Each of the phases required for the program
- Each of the work categories required for each phase of the program
- The levels of work tasks necessary to achieve a complete and accurate list of tasks and consequently an overall program schedule
The drawing below is a simplified functional WBS illustrating how a WBS should be structured to address the phases, work categories, and levels of task detail for a typical program.
A product or deliverable WBS may also be developed for programs instead of a functional WBS. The first level for a radar project in a product WBS would be same as the functional WBS – Radar Project. The second level of work categories in a product WBS would be units of the radar system (e.g., computer, radar antenna, display, radar electronics, etc.). The third level of work tasks would be each of the unit subassemblies and so forth. The Department of Defense and many other government agencies use Military Standard 881(MIL-STD-881) for guidance in developing WBS for programs.
What are the phases of a program WBS?
As shown above, most programs have multiple phases such as:
- Acquisition planning and start-up
- Research, Design, Test and Evaluation (RDT&E) (frequently multiple phases)
- Life cycle operation and maintenance
The Acquisition Planning phase of a program typically covers all planning, management, and contract award efforts required to execute the program. Tasks typically covered by this phase include the preparation of program management documents such as the Program Management Plan (PMP), Risk Management (RM) Plan, Acquisition Strategy Plan (ASP); preparation of a request for proposal (RFP) and proposal evaluation plans; and other program documents that must be prepared to start the program.
The RDT&E Phase of a program may have multiple phases of research, design and development phases for high technology programs. Examples of work tasks to be included in this phase(s) would be system software and hardware design documents; system interface design documents; test and evaluation documents; system, subsystem and interface tests; and other work tasks that must be completed before a system moves into the Production/Manufacturing phase.
The work efforts that must be addressed in the next phases of a program include all efforts necessary to manufacture large quantities of the systems, install them and then operate and maintain them over their service life.
What are the work categories of a program WBS?
Within each phase of a program, a list of work tasks should be identified for each category of work that must be performed during that phase. The same work category may be required for multiple phases of a program. For example, engineering tasks will be required during the Design, Development, Test, Production, Installation and Life Cycle Support phases of most programs. Examples of work categories for a typical program are:
- Program Documentation: preparation of program documents and reports
- Contract Tasks: preparation of requests for proposals; contract documents such as specifications, statements of work, and contract data requirements; proposal evaluation plans, etc.
- Budget and Financial: preparation of budget requests and financial reports
- Engineering: design and development tasks and documents
- Logistics Support: tasks and documents (e.g., requirements for human factors, safety, supportability, training, etc.)
- Test & Evaluation: preparation of test documents and the conduct of the tests
- Installation: preparation of installation plans/documents and the installation and testing of the production systems
- Life Cycle Support: preparation of documents and plans to provide life cycle support for the program and all life cycle support tasks such as engineering change proposals (ECP), operator and maintenance training, tech refresh efforts, etc.)
What are the levels of a program WBS?
All tasks in each work category of a program are broken down by levels, with each descending level having more detail. As illustrated previously in the WBS drawing, all major programs should have a WBS with at least four levels of tasks. The number of levels necessary for a program WBS is determined during the actual preparation of the WBS since each significant task must be included in the WBS in a logical hierarchical manner. In other words, a WBS should be prepared to the lowest level necessary to account for all significant program tasks.
More information and suggestions concerning the development of a program WBS and cost and schedule estimates for the establishment of a final program baseline will be provided in my next blog. In the meantime, for a conversation about any of the first three critical tasks we’ve discussed so far, feel free to contact us.