CHAPTER 7
Portfolio Management and a Standard WBS
In Chapter 1, the definition of portfolio is stated as: A collection of related projects or programs and other work that groups projects or programs together in order to support effective management of the total work effort in a way that meets strategic business or organizational objectives. Portfolio management or Project Portfolio Management (to differentiate from a portfolio of securities) is, therefore, the process of addressing all the projects in an enterprise as a whole in order to achieve some level of optimization with regard to achieving enterprise goals. This process involves the continuous selection and evaluation of projects to ensure that they are meeting enterprise goals, mission, and vision.
This chapter provides a brief overview of project portfolio management and the role of the WBS in implementing the concept in several different enterprises. It also discusses several standard WBSs that have been developed.
INTRODUCTION1
Project Portfolio Management (PPM) is a term that was used initially by software companies and consulting firms and now is in broader use to describe various approaches characterized by treating projects as part of an overall project investment portfolio. Use of the term is seen as a shift away from focusing on only one project at a time when making decisions regarding support by the enterprise. Most PPM tools and methods attempt to establish a set of values, techniques, and technologies that enable visibility, standardization, measurement, and process improvement across all projects in the enterprise. PPM tools attempt to enable organizations to manage the continuous flow of projects from concept and selection to completion.
Developers of PPM tools see their solutions as borrowing from the financial investment and economic microanalysis world.
The definition of a project that we have been using is: a temporary endeavor undertaken to create a unique product, service or result. This is the output-focused definition that is basic to project management. The PPM world uses an economic perspective, and projects are often viewed as collections of inputs or a composite of resource investments like skilled labor and associated salaries, materials, and opportunity costs of deferring other project work. These inputs produce things like hardware and software as outputs. Since economics is the study of allocating scarce resources, this makes sense for PPM.
As project resources are constrained, business management can derive greatest value by allocating these resources toward project work that is objectively and relatively determined to meet business objectives more than other project opportunities do. Thus, the decision to invest in a project can be made based upon criteria that measure the relative benefits (for example, supporting business objectives) and the relative costs and risks to the organization.
In principle, PPM attempts to address issues of resource allocation, such as money, time, people, and capacity. In order to truly borrow concepts from the financial investment world, the portfolio of private-sector projects should be grounded in a financial objective such as increasing shareholder value or top-line growth. It is equally important that risks are computed in a statistically and actuarially meaningful sense. Optimizing resources and projects without these items in mind fails to consider the most important resource any organization has—a resource that is easily understood by people throughout the organization, whether they are in engineering, IT, finance, or marketing—money. Other criteria, such as efficiency or effectiveness, must be used for public-sector or not-for-profit enterprises.
Beyond the project investment decision, PPM aims to support ongoing measurement of the project portfolio so that each project can be monitored for its relative contribution to business or organization goals. If a project is either performing below expectations (cost overruns, benefit erosion) or is no longer highly aligned to business objectives (which change with natural market and statutory evolution), management can choose to de-commit from a project and redirect its resources elsewhere. This analysis, done periodically, will “refresh” the portfolio so that it better aligns with current states and needs.
Historically, many organizations were criticized for focusing on “doing the wrong things well.” PPM attempts to focus on a fundamental question: “Should we be doing this project or this portfolio of projects at all?” One litmus test for PPM success is to ask, “Have you ever canceled a project that was on time and on budget?” With a true PPM approach in place, it is much more likely that the answer is “yes.” As goals change, so should the portfolio mix of what projects are funded or not funded, no matter where they are in their individual life cycles. Making these portfolio-level business investment decisions allows the organization to free up resources, even those on what were before considered “successful” projects, to then work on what is really important to the organization
Further discussion of portfolio management as it pertains to projects is available from PMI.2
WBS ROLES
There are two roles of the WBS in project portfolio management: (1) Displaying the projects in a logical hierarchical format for presentation purposes, and (2) using a WBS to design a project portfolio management system.
The first instance is not really a WBS; it is only using some of the WBS logic and familiar display techniques to organize the programs and projects of a cost or profit center to facilitate communication. Most WBS software, as discussed in Chapter 3, could achieve this purpose well because such software can also accommodate the presentation of various figures of interest, such as ROI, breakeven, and other microeconomics financial evaluation factors or whatever scoring models the enterprise used. Figure 7-1 uses the General Services Administration (GSA) to illustrate the locations of programs and projects within the overall enterprise. Other data, such as annual budgets, could be added to the project boxes.
FIGURE 7-1 Enterprise PPM Projects
PLANNING A PORTFOLIO MANAGEMENT SYSTEM
The second usage would be the normal use of a WBS to facilitate the planning of a project to develop a project portfolio management system.
Figure 7-2 presents such a WBS, as suggested by Rad and Levin,3 with some minor modifications by the author. This WBS represents the work required to develop a comprehensive system to establish and manage an enterprise PPM system.
FIGURE 7-2 WBS for PPM System Development Project
ESTABLISHING AN ENTERPRISE STANDARD WBS
The use of the WBS concept for structuring programs and to assist in meeting executive-level planning requirements varies widely by enterprise. Enterprises fall into one of five categories:
Category A. They have developed a standard WBS or WBS template at the program level for enterprise use that covers all life cycle phases.
Category B. They have developed a family of WBSs or templates for the primary phase of the project life cycle (the acquisition phase).
Category C. They have developed a combination of the two preceding usages that covers the entire life cycle as well as multiple product lines or services.
Category D. When outsourcing, they refer contractors to a handbook, standard, or specification for guidance in the preparation of the WBS.
Category E. They have not developed any standard usage.
Category A—Enterprise-Level WBS Standard
Enterprises that fit into Category A have developed a standard WBS or WBS template at the program level for enterprise use that covers all life cycle phases.
For example, the Federal Aviation Administration (FAA) has developed an enterprise-level WBS (see Figure 7-3). The FAA has been active for years in developing its project and program management capabilities. In April 2005, the FAA published the latest version of its Standard Work Breakdown Structure, Version 4.1 on its FAA Acquisition System Toolset (FAST) website.4 It is one of the items in the FAA toolset available to support FAA program and project managers.
The FAA’s Standard WBS represents and is defined by the FAA as “the complete set of activities that may be accomplished to provide a solution that satisfies an FAA mission need. Solutions include products and services such as hardware, software, facilities, communications services, technical assistance services, infrastructure, training, procedures, etc.”5 The elements in the WBS represent work areas, not the resources needed to accomplish the work.
As is the case in many standard WBSs, the FAA’s Standard WBS is intended for use across the FAA for developing life cycle cost estimates of programs and for planning the portfolio. The FAA’s Standard WBS also supports management of projects during the implementation and in-service management phases, and is intended to aid in the comparison of life cycle cost estimates to actual costs that have been collected through the FAA’s cost accounting system.
The FAA’s Standard WBS is intended to provide uniformity in definition and consistency of approach for developing the top three levels of the WBS for programs. While providing consistency, the WBS also permits flexibility: Users need use only those elements that apply to their programs and may add detail below the specified levels as needed.
Figure 7-3 presents the first two levels of the FAA Standard WBS; the complete WBS is available in Appendix A. The corresponding extensive WBS dictionary, which describes each of the elements at these top three levels is available on the FAA website.
In the FAA WBS, “Mission Analysis” and “Investment Analysis” work activities precede the formal establishment of a specific program. The remaining elements in the WBS are work elements that are directly associated with a specific program.
This concept of “pre-program” work is commonly used to describe the preliminary effort before a program is formally established. In the life cycle decision process, there is often a decision milestone at the end of the program definition phase that is a formal kickoff for an approved program; then the program can proceed to the next phase, which is usually a planning phase.
The FAA WBS applies to all acquisition, research, and development programs regardless of cost or appropriation. There are no specific WBS elements for technology refreshment activities, so such work is structured into the appropriate WBS elements on a case-by-case basis.
The FAA WBS is used for all acquisition program life cycle cost estimates and for tracking actual costs in the FAA accounting system. Furthermore, FAA prefers that contractors submit proposals utilizing the FAA WBS or show the mapping between the Contractor Work Breakdown Structure (CWBS) and the FAA WBS. The WBS is used to collect costs related to acquisitions and to directly feed into the FAA accounting system, which also collects costs from additional sources.
The FAA provides three sets of justifications for the use of the a standard WBS that are also applicable to many other organizations and enterprises.6
1. Life Cycle cost estimates: Improves life cycle cost estimates by providing structure for completeness and “apples-to-apples” comparisons:
Provides common data elements and definitions for orderly data integration and collection
Serves as a checklist for the program manager
Builds corporate history of comparable program experiences for future estimates
Allows direct comparison of estimated and actual costs
Facilitates update of models and techniques to reflect organizational experience
2. Project management: Improves the management of projects:
Provides visibility of high-cost program elements
Facilitates affordability assessments and budgeting
Facilitates comparison of evolving estimates
Provides audit trail
Allows direct comparison of estimated and actual costs
Facilitates acquisition and implementation of performance measurements (e.g., earned value management, cost accounting)7
3. Facilitates other FAA processes: Provides a framework for other FAA initiatives and management activities:
Activity-based costing
Fee for service
Line of business workforce management
Government Performance and Results Act requirements
Category A is the preferred model for organizations that have a single product line or a primary service. Another example is the generic representative museum exhibit life cycle WBS presented in a previous chapter.
Category B—Family of Standard WBSs or Templates
The Category B enterprises either formally or informally have developed a family of WBSs or templates for the primary phase of the project life cycle: the acquisition phase. The Category B WBSs focus on only this one phase and do not address the entire program life cycle.
In the case of DoD systems, Category B describes the DoD MIL-HDBK-881A use of the WBS at the DoD program level. It differs from Category A in two respects: (1) It focuses on only the systems acquisition phase, and (2) it has eight system templates from which the user can choose (see Figure 7-4). The templates are really “superproject” templates and have served the DoD well over the years.
FIGURE 7-4 MIL-HDBK-881A Templates
During the system engineering in the earlier life cycle phases, the WBS for the systems acquisition phase is developed to increasing levels of detail.
Category C—Life Cycle Framework
Category C enterprises have a framework that covers the entire life cycle as well as multiple product lines or services. The framework provides a structure for planning, data collection, and performance management of all phases of the life cycle. In addition, the framework provides WBS templates for the primary systems or products acquired by an enterprise.
As discussed in Chapter 6, each phase of the life cycle of a program should be planned and managed as a project in its own right. Each phase has a set of discrete outputs and therefore meets the definition of a project. In most cases, the type of work in the initial phases is the same for each product. Economic analyses, mission analyses, cost-benefit studies, and tradeoff analyses are performed, and a program plan and master schedule are developed for each product. One output of earlier phases is usually the WBS for the primary acquisition phase, which evolves from the systems engineering and planning and analysis activities.
When the product lines differ, separate templates are needed for those phases of the program WBS that are product-specific. This usually is only the acquisition or implementation phase.
For the FAA model to move to this category, the systems could be the following:
Communications systems
Navigation systems
Automation systems
Enterprise systems
For each of these systems, templates and WBS dictionaries that are similar to those listed for the DoD could be developed. The FAA has its own terminology for its life cycle phases, so these would be alternates for “Phase 3. Solution Development” (for example, Solution Development– Communications Systems). This is the only phase where Level 3 items are system-unique. The other phases all have similar WBS elements at Level 3 for each program.
Even in the DoD WBS templates for the eight systems identified in Figure 7-4, some WBS elements are common to all the systems (e.g., program management, logistics support), which reduces the number of variables in terms of WBS elements. These WBS elements are identified and defined in the DoD Handbook as common items.
Category D—Standard for WBS Development
Enterprises in Category D use a recommended source (handbook, standard, or specification) for guidance in the preparation of the WBS, both when preparing the WBS internally and when the work is outsourced. The most commonly used source for military programs is MIL-HDBK-881A, which contains extensive user information, logical rules, and guidelines for developing a WBS.
One of the problems with this approach is that MIL-HDBK-881A, although an excellent document, does not fit all enterprises and all program phases—it was intended to focus on the acquisition phase of DoD-type programs. The same difficulty exists for the comparable document developed by Caltrans that is discussed in Chapter 9.
One of the purposes of this book is to provide guidelines for the development of effective WBSs for all programs, program phases, and projects.
Category E—No Existing Standard
Enterprises in which no guidance is provided fall into Category E. This category is where the project management level of maturity is at the lowest level.8 In this situation, the members of PMI® and other professional project management organizations and those who have attended PMBOK® Guide-based training courses have a distinct advantage: They have an idea of the advantages and intent of the WBS and can approach their project management assignments accordingly. However, with the executive level requirement to implement EVM, organizations will be expected to improve their WBS maturity by moving from Category E performance toward Category A, B, or C.
CONCEPT FOR A STANDARD ENTERPRISE WBS
Figure 7-5 presents a recommended outline process for establishing an enterprise-wide standard WBS to provide the framework for planning and to meet enterprise management requirements. Each level of the standard WBS must still meet the 100 percent rule.
FIGURE 7-5 Standard Enterprise WBS Process Steps
OUTSOURCING—WBS REQUIREMENTS PLACED ON CONTRACTORS
The common approach of organizations that fit Category A, B, or C is to provide the enterprise WBS down to Level 3 (or below, if necessary) and have the contractor extend or decompose the WBS to the levels needed for management and control. In the DoD, the result of this action is referred to as the Contract WBS or CWBS. The CWBS provides the capability to roll up data via the WBS to the standard categories used by the enterprise without unduly constraining the contractor to use a structure that does not match its product or method of management. The enterprise is then able to respond to the executive-level reporting requirements, as well as provide a basis for consistent data collection.
NOTES
1. This introduction to project portfolio management is derived from Wikipedia, “Project Portfolio Management,” Wikipedia, The Free Encyclopedia, and was edited by the author. Online at http://en.wikipedia.org (accessed June 15, 2007).
2. Project Management Institute, Practice Standard for Portfolio Management (Newtown Square, PA: Project Management Institute, 2006).
3. Parviz E. Rad and Ginger Levin, 3. Project Portfolio Management (New York: IIL Publishing, 2006), 94.
4. Federal Aviation Administration, “FAST—The Federal Aviation Adminis-4. tration Acquisition Toolkit.” Online at http://fast.faa.gov (accessed April 16, 2008).
5. Ibid.
6. Office of System Architecture and Investment Analysis, Investment Analysis and Operations Research Directorate, Basic FAA Work Breakdown Structure Training Course (Washington, D.C.: Federal Aviation Administration, February 2002).
7. Office of Management and Budget, Circular A-11: Preparation, Submission, and Execution of the Budget (Washington, D.C.: Office of Management and Budget, 2002), Part 7.
8. See also Gregory T. Haugan, Project Planning and Scheduling (Vienna, VA: Management Concepts, 2002), 88–90.