The Work Breakdown Structure: A Brief Synopsis

Note to reader The discussion of history and practice in this White Paper is based on readily available documents and references obtained through a reasonably diligent search of relevant archives and public domain information sources. This White Paper should not be construed as an exhaustive, academic-quality, professional research paper. The information provided here is intended for use in establishing context and background for the development of the concept of the Work Breakdown Structure. Opinions or conclusions expressed in this White Paper reflect the views of the authors and do not necessarily reflect the opinions or position of the Project Management Institute. Authors: Shelly A. Brotherton, PMP Robert T. Fried, PMP George A. Ksander, PMP Eric S. Norman, PMP April, 2006 The History of the Work Breakdown Structure The WBS has been at the core of project management practice since the beginning of the professionalization of project management. The Work Breakdown Structure (WBS) began to come into use in the late 1950s and early 1960s. Creation of a WBS was evident in the DoD and NASA Guide PERT COST Systems Design June 1962 (Chapter II, pages 23 35), which was, in turn, based on the original PERT system developed by the US Navy (NASA PERT and Companion Cost System Handbook. October 30, 1962, p. II-1). The concept of the WBS and the practices around its use were initially developed by the US Department of Defense (DoD) and National Aeronautics and Space Administration (NASA) for the purpose of planning and controlling large acquisition projects whose objective was development and delivery of weapons or space systems (Cleland, Air University Review, 1964, p14). These projects often involved many industrial contractors each with responsibility for separate components of the system and were managed by a central administrative office, either within a governmental agency or within one of the contracting firms which served as prime contractor. In this environment, the WBS was used to ensure that the total project is fully planned and that all derivative plans contribute directly to the desired objectives (NASA PERT and Companion Cost System Handbook, 1962). As described by the DOD and NASA Guide. PERT Cost Systems Design (June 1962, p. 26), the development of the work breakdown structure:

Defines the project tasks to be performed and establishes their relationship to the project end item(s) and project objectives;

Establishes the framework for integrated cost and schedule planning and control;

1

Establishes a framework for summarizing the cost and schedule status of the project for progressively higher levels of management.

During this early period and into the 1970s, sophisticated techniques and information systems for managing and controlling the project schedule and budget, such as PERT, CPM, C/SCSC and others, were also developed (Kloppenborg and Opfer, 2002). The WBS was the foundation for all of these systems (DoD MIL-STD881A, 1975). The use of these systems, including the WBS, was mandatory for projects above a certain size and was recommended for all projects (DOD MIL-STD881A, 1975). To support this requirement, a series of guidelines, handbooks and manuals was promulgated to provide uniformity of procedure and documentation among the many administrative offices and contractors working on a single project. These documents have been periodically updated and continue in effect to the present day by both US and other governments. (MIL-STD881A 1998, Australian Defence Standard Draft Def(Aust)5664 Issue A, Jun 2004). Government requirements for the use of project control techniques, including the WBS, facilitated the diffusion of knowledge of these techniques and appreciation of their value throughout those industries doing business with the government. As the value of project management thinking and methods spread beyond large military industrial projects, so too did appreciation of the value of the WBS. In part this spread was facilitated by practitioners who moved from the government into private sector industries. In part it was stimulated through the teaching and consulting of academics in business and engineering schools and a number of instructional papers and texts (for example: Globerson, 1994, Pritchard 1998, Haugan 2002). Development of the WBS was one component of the evolution and codification of the broader collection of organizational theory and practices that have become known as Project Management (Cleland, 1964, Stewart, 1965, Kerzner, 1996, Webster 1999). Another manifestation of the increasing professionalization of project management was the formation of the Project Management Institute (PMI) in 1969 in order To promote a unifying influence in the advancement of the field of Project Management with emphasis on the tools and methods for the planning, scheduling and control of project oriented tasks (Project Management Institute, Articles of Incorporation, 1969). One significant effort of the Project Management Institute, among others, was the evolution of a set of standards which described and codified The content and structure of the professions body of knowledge (standards) (PMBOK Guide Third Edition, 2004, p. 309). This most recent result of this effort is the PMBOK Guide Third Edition, the purpose of which is to identify that subset of the Project Management Body of Knowledge that is generally recognized as good practice (PMBOK Guide Third Edition, 2004, p.3) as well as a series of Application Area Extensions (Program and Portfolio Management Standards, Earned Value Practice Standard, Government Extension, DOD Extension, Construction Extension) which describe generally accepted knowledge and practices that are specific to those areas (PMBOK Guide Third Edition, 2004, p 329). Throughout the growth and expansion of these standards, the WBS has played a central role as a tool and technique for organizing and managing the project scope and supporting other processes. The WBS has received progressively more attention in successive versions of the PMBOK Guide, and in the Third Edition a new Project Management Process was included, i.e., 5.3 Create WBS. PMI recognized the unique importance of the WBS when it published, in 2001, a Practice Standard devoted exclusively to the WBS. The Practice Standard for Work Breakdown Structures was intended to provide guidance in the initial generation, subsequent development, and application of the Work Breakdown Structure (WBS) (Project Management Institute, 2001, p. xi). This document was the first practice standard, i.e., it focused on providing guidelines on the mechanics (e.g., nuts and bolts, basics, fundamentals, step-by-step usage guide, how it operates, how to do it) for the WBS (Project Management Institute, 2001, p. 29). A Practice Standard is intended to be more prescriptive than the PMBOK Guide (Project Management Institute, 2001, p. 30). Increasing sophistication in the use of the WBS has stimulated production of this updated and revised edition - Practice Standard for Work Breakdown StructuresSecond Edition.

2

The publication of updated and revised editions of the PMBOK Guide and WBS Practice Standard recognizes the growth and increased sophistication of project management thought and practice in general, and of the WBS in particular. In some cases this evolution reflects revised thinking and reformulation of earlier concepts, and in other cases it represents progressive elaboration and formalization of concepts that were previously only implicit. With respect to the WBS, an example of revised thinking is the concept of the WBS as Deliverable-oriented. In the 1987 PMBOK Guide, the WBS was defined as a Task-oriented family tree of activities. In the 1996 and 2000 editions of PMBOK Guide, the WBS was defined as a deliverable-oriented grouping of project elements. In the PMBOK Guide Third Edition, it had become a deliverable-oriented decomposition of the work to be executed. Throughout this development, however, the WBS was consistently seen as a tool to organize and define the total work, the scope, of the project. (Project Management Institute, PMI Today, April 2003, (Project Management Institute, PMBOK Guide Third Edition, p. 379). The evolution from a task orientation to a deliverable orientation reflects the realization that decomposition of project deliverables, expressed as nouns, is necessary for complete scope definition and control, and that the lowest level of the WBS may be connected to activities and work packages defined in terms of actions, expressed as verbs (Berg and Colenso, 2000, p 69; Project Management Institute, 2001; PMI Today, April 2003.) An example of increasing formalization of implied concepts is the explicit statement in the Practice Standard for Work Breakdown StructuresSecond Edition of the WBS Quality Principle #1 which states that a WBS is characterized by a set of Core Characteristics that must be present in every WBS, as these characteristics enable the WBS to satisfy project needs that are present in every project and a set of Use-related Characteristics that may vary from one WBS to another because they enable the WBS to be used for purposes that are unique to a specific project, industry or environment, or are applied in a particular way to individual projects. (Work Breakdown Structure Practice Standard - Second Edition, p. 21). These concepts had been implicit in descriptions of the WBS from the earliest days but only became explicit in the latest edition of the Practice Standard. (Core Characteristics: Office of the Secretary of Defense. DoD and NASA Guide PERT COST Systems Design, June 1962, pp.28, 33, 144; Rad, 1999, p. 35; Use-related Characteristics: Office of the Secretary of Defense. DoD and NASA Guide PERT COST Systems Design, June 1962, pp. 33; NASA PERT and Companion Cost System, 1962, p IV-1, Globerson, 1994; p. 3; Berg and Colenso, 2000, p. 69,). For example, DoD and NASA Guide PERT COST Systems Design, June 1962 states the Core Characteristic:

The work breakdown structure establishes the framework for defining the work to be accomplished (p. 26).

The same document provides an early expression of the concept of Use-related Characteristics :

..the level of detail should be determined by the program or project manager and should be a function of such factors as: the size and complexity of the project, the degree of uncertainty in the work, the familiarity with the work to be performed, and the time available for planning., (p.33).

The idea has also been expressed by Berg and Colenso:

The WBS is project management tool that can be used in different ways, depending on the needs pf the project (Berg and Colenso, 2000, p 69).

The WBS has become a powerful and flexible tool that can be designed to meet the needs of many disparate types of projects, including projects managed with a Rolling Wave approach (Githens, 2001), enterprise projects (Dinsmore, 2000), projects characterized by repetitive subprojects (Shtub, 1997), complex projects that require parallel WBSs to manage different aspects of the project (Grove, Hallowell,

3

and Smith, 1999), and projects where the ability to repackage work on a daily basis is important (Luby, Peel and Swahl, 1995). We turn now to a look at how the evolved understanding of the WBS is being used in current practice. Work Breakdown Structures Present Use Today, Project Managers are more frequently finding high value in the creation of Work Breakdown Structures (WBS) as they begin the process of project management. Project success may be attributed specifically to use of a WBS (Halli, 1993). As an essential element of the Planning Process Group outlined in the PMBOK Guide - Third Edition, everyday practice is revealing with increasing regularity that creation of a WBS to define the scope of the project will help ensure delivery of the projects scope, objectives and outcomes. Moreover, the more clearly the scope of the project is articulated before the actual work begins, the more likely the success of the project the intelligent structure of work breakdowns is a precursor to effective project management. (Gunn and Homer, 1995, p. 1). Specifically, the Planning Process Group begins with three essential steps Scope Planning (3.2.2.2), Scope Definition (3.2.2.3) and Work Breakdown Structure Development (3.2.2.4). (PMBOK Guide - Third Edition). The following discussion will examine the current trends and practice in regards to Work Breakdown Structures. It is widely written that Work Breakdown Structures are fundamental building blocks for project management practice. There are many writings on the subject, here are a but a few key examples:

Harold Kerzner writes: The WBS provides the framework on which costs, time, and schedule/performance can be compared against the budget for each level of the WBS (Kerzner, p. 791). From The PMBOK Guide - Third Edition: The WBS is a deliverable-oriented hierarchical decomposition of the work to be executed by the project team, to accomplish the project objectives and create the required deliverables The WBS represents the work specified in the current approved project scope statement. Components comprising the WBS assist the stakeholders in viewing the deliverables of the project (p. 112). Dr. Gregory T. Haugan: The WBS is the key tool used to assist the project manager in defining the work to be performed to meet the objectives of a project (Haughan, 2002, p. 15). Carl L. Pritchard: the WBS serves as the framework for project plan development. Much like the frame of a house, it supports all basic components as they are developed and built (Pritchard 1998, p. 2).

Work Breakdown Structure Usage Trends As we have discussed earlier in this paper, project managers in certain industries including Defense, Aerospace, Pharmaceuticals, Construction, Financial Services, and others, regularly rely on standard and elaborate Work Breakdown Structures to plan and manage their work. (DoD Military Standard Work Breakdown Structures for Defense Material Items MIL-STD-881A; Mansuy, p18; Figure 3, PMBOK Guide - Third Edition, etc.) This practice is less established in other industries such as Consumer Retail and some information technology (IT) functions, though as evidenced by the recent survey found in Appendix A of this document, that trend is changing (see survey results, attached). More and more frequently, project managers across a broad array of technologies and industries are using Work Breakdown Structures to articulate and define the work of their projects before developing

4

other project tools such as resource matrices, network diagrams and schedules. Additionally, leaders are finding that project difficulties including scope creep, budget shortfalls, poor project performance and missed deliverables can be traced directly to the absence of a logical WBS or the completeness and quality of the WBS if it exists - and to the amount of effort spent developing and maintaining the WBS. By the same token, from anecdotal evidence gathered during the update of the Practice Standard for Work Breakdown Structures, there remains a contingent of project managers who find little value in the scope planning and control functions offered by the WBS. For many in this group, creating a WBS is often seen as an unnecessary task that can be skipped with little or no consequence - or the WBS becomes simply a representation of the projects schedule in outline form, little more. Conflicting and Confusing Messages for the Project Manager If it is clear the WBS is the starting point in the planning process for many other essential project management processes such as Estimating, Scheduling and Controlling, then why do some project managers find the WBS a difficult component to create, or a redundant and potentially unnecessary step in the project planning process? There are likely many reasons why a decreasing number of project managers give little time or energy to WBS creation. Here are some considerations: First, in the highly volatile and competitive environment that characterizes the information technology, financial services and software development industries, there is ever increasing pressure on the project manager to deliver quickly, using a fluid, flexible and light weight project planning process. It is not unusual for project mangers in these industries to find themselves encouraged to fast track the planning phase - or skip from the inception of a project to development of the projects schedule. Speed to market is of the highest importance and any step that might appear to be expendable becomes a target for exclusion and is eliminated many times with unintended results. Without a scope statement and an effective WBS, the project may eventually encounter difficulty and may result in poor performance or outcomes. Beyond this, over the past five years, process management and scheduling tools for project management have evolved to become sophisticated and robust product suites. These tools now offer an array of automated functions including what many claim as work breakdown structure outputs (see Exhibit 1). Naturally, it is quite easy for Project Managers to rely on these tools to produce what at first glance appears to be the WBS they require for their projects. Unfortunately, these tools do not help the project manager define and decompose the scope of the project in terms of its deliverables (the true foundational role of the WBS) (PMBOK Guide - Third Edition) but rather enable the project manager to enter a listing of schedule tasks, push a button and produce what appears to be a WBS.

5

Figure 1. Project schedule example. Additional factors including the above stated need for fast track project delivery and a broadly held assumption that smaller projects do not require Work Breakdown Structures tend to weaken the importance of the WBS. At the same time - for complex projects, broad or long-running projects, costly projects and projects of critical importance to an organization or agency, the necessity to carefully detail project scope has evolved to an imperative. Compounding this issue is the array of conflicting guidance regarding the proper approach to structuring the creation of a WBS. As discussed above, the PMBOK Guide - Third Edition defines the WBS as a deliverable-oriented, hierarchical grouping of the work to be executed by the project team to accomplish the project objectives and create the required deliverables. It organizes and defines the total scope of the project. Each descending level represents an increasingly detailed definition of the projects work (PMBOK Guide - Third Edition, p. 394). This definition of the WBS is grounded in decades of experience, a vast array of empirical evidence and analysis of practical application. Additionally, this perspective is also generally recognized as good practice, most projects, most of the time. (PMBOK Guide - Third Edition, p. 18) As described earlier, the concept of deliverable-oriented development of Work Breakdown Structures is also reinforced by writings from the Department of Defense (MIL-HDBK-881 1998) and the standard established for development of the WBS, viz, PMIs current Practice Standard for Work Breakdown Structures . None-the-less, many authors recommend creating PROCESS-oriented Work Breakdown Structures (Chapman, 2004, p. 2), while others suggest the best approach is an ACTION-oriented approach (Pritchard, 1998, p. 9). Further clouding the path to development of effective Work Breakdown Structures, Systems Development Lifecycle practices such as agile methodologies or Rationals RUP (Rational Unified Process) are built on the principle of process-orientation and dont easily translate or lend themselves to the creation of deliverable-orientated Work Breakdown Structures to support them. In these cases where a process-orientation is an effective method used during project planning, the development and use of a separate, deliverable-oriented WBS to define the project scope may be a valuable complement.

6

Finding Answers Evaluating Alternatives for WBS Creation Lets examine these approaches to WBS orientation more carefully. We will discuss process-oriented, task-oriented and deliverable-oriented approaches in order, below. Process-oriented WBS construction does not articulate project outcomes Carefully developing process-oriented Work Breakdown Structures may ensure that each project process is clearly articulated and that each of these processes is detailed to the appropriate work package level. Following standard WBS development practices, when creating a process-oriented WBS, will guide the project manager to develop an associated WBS Dictionary to carefully explain the content of each element in the WBS. Developing a process-oriented WBS will not, however, aid the project manager in defining the outcomes, results or deliverables from the project effort. Though a process-oriented WBS may be constructed using best in class practice, the resulting WBS does not necessarily document and communicate outcomes, but rather details the processes employed to deliver the intended outcomes. In this case, it would be quite possible to successfully execute WBS elements or entire WBS constructs, ensuring the processes are being executed with a high degree of quality while overlooking or omitting key products from one or more of the WBS elements. As an example, in a process-oriented WBS, one of the level 2 elements may be Testing Processes; and within this element, Unit Testing, Integration Testing and System Testing at level 3. In a process-oriented approach, with focus on the quality of the process it would be possible to perform any and all of these testing processes without error - and do so repeatedly without delivering the intended product. Action-oriented WBS construction does not provide clear direction for delivering project deliverablesAs in the process-oriented WBS construction described above, it is also possible to perform project tasks and activities with a high degree of quality, without delivering desired project outcomes. The example here is similar to the process-oriented discussion. The WBS can be defined in terms of broad Tasks or Activities at level 2 that include narrower and smaller elements at levels 3 and beyond (decomposition of the work). To use an example, a level 2 task may be described as Design the Product, while level 3 elements include Design Internal Components, Design External Components, Design Common Components and Design Integration Components level 4: Design sub-components 1 n. In a hierarchical-outline format we would represent this in a WBS as follows (Exhibit 2)

2.1 Design the Product

2.1.1 Design Internal Components 2.1.1.1 Design internal sub-component 1 2.1.1.2 Design internal sub-component 2 2.1.1.3 Design internal sub-component n

2.1.2 Design External Components 2.1.2.1 Design external sub-component 1 2.1.2.2 Design external sub-component 2 2.1.2.3 Design external sub-component n

2.1.3 Design Common Components 2.1.3.1 Design common sub-component 1 2.1.3.2 Design common sub-component 2 2.1.3.3 Design common sub-component n

2.1.4 Design Integration Components 2.1.4.1 Design integration component 1 2.1.4.2 Design integration component 2 2.1.4.3 Design integration component n

Figure 2. Sample action-oriented WBS.

7

Here, the WBS is again defined in terms of the activities and tasks (actions) that must occur. Further, these actions may be described within the associated WBS Dictionary in enough detail to recommend or imply a particular order (which, as reviewed above is more oriented toward a scheduling exercise than scope definition). Whatever the case, once again, while it may be possible to perform design activities/tasks precisely, the intended outcomes products of these efforts are not particularly called-out by the WBS construction or associated dictionary (implied herein, but not presented). The most important deliverables specifically the Product Design and its associated External, Internal and Integration components are not defined. In action-oriented WBS examples (Pritchard, 1998, p. 9, p. 20) there may be great detail describing the task or activity to be performed, including specific tools, responsible persons, task duration and the like, with little clarification of the outcome of the action or criteria by which it would be deemed complete and acceptable by the receiver(s). Deliverable-oriented WBS construction focuses on project outcomes Creating deliverable-oriented Work Breakdown Structures focuses the project manager, project team, stakeholders and sponsors on the outcomes or products of the project. As discussed earlier, the deliverable-orientation and progressive decomposition will facilitate the process by which the project manager and team describe, detail, communicate and measure progress toward project results. To provide an example, describing WBS levels as deliverable-oriented groupings, levels 2, 3 and beyond would contain nouns and adjectives to describe their content. For instance, Figure 3 illustrates a deliverable-oriented breakdown of the same work illustrated in Figure as an action-oriented breakdown.

2.1 Product Design

2.1.1 Internal Components Design 2.1.1.1 Design of internal sub-component 1 2.1.1.2 Design of internal sub-component 2 2.1.1.3 Design of internal sub-component n

2.1.2 External Components Design 2.1.2.1 Design of external sub-component 1 2.1.2.2 Design of external sub-component 2 2.1.2.3 Design of external sub-component n

2.1.3 Common Components Design 2.1.3.1 Design of common sub-component 1 2.1.3.2 Design of common sub-component 2 2.1.3.3 Design of common sub-component n

2.1.4 Integration Components Design 2.1.4.1 Design of integration component 1 2.1.4.2 Design of integration component 2 2.1.4.3 Design of integration component n

Figure 3. Sample deliverable-oriented WBS.

The WBS dictionary for these elements would carefully describe the subject elements in great detail and may include (though not limited to) the WBS element owner, resource pool, tools, requirements, dependencies, and would specifically include a definition of the finished product including criteria detailing how the completeness of the element would be defined as well as the process by which it would be measured to the point of including the metrics used for its evaluation. With this process as a foundation, each WBS element articulates and drives toward a specific measurable outcome or product, whether that outcome is an internal deliverable (internal to the project) or an external deliverable (a project outcome intended for receivers or stakeholders outside the project team or organization). Moreover, the WBS constructed in this manner provides a detailed definition of the project scope as well as its limits, and provides the project manager with a foundation composed of a

8

group of unique building blocks on which to construct the project schedule, resource matrix, risk plan, change control process and more. Benefit to the Project or Program Practical evidence has revealed that Work Breakdown Structures provide a foundation for other project related elements and activities. By decomposing the work into meaningful, clearly articulated elements that relate to one another as well as the overall product of the effort, the project manager provides a basis for budget and resource forecasting, network diagram and schedule development, change and risk management Benefit to Stakeholders The WBS also provides a clear articulation of the projects scope to stakeholders. The WBS can be used as a basis for communicating with stakeholders about the outcomes of the project and can be the primary vehicle for negotiating scope change requests. In this way, the WBS becomes a cornerstone of the project or program effort. 100% Rule One of if not the most important guiding principle in the development, decomposition and evaluation of the WBS is the 100% Rule. The rule states:

The next level decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element. (Haugan, 2002, p 17).

If the 100% Rule is followed from the highest level to the lowest levels of WBS decomposition, then it follows that 100% of the project scope will have been defined. The application of this rule to WBS development is a crucial element to ensuring that the project scope captures ALL project deliverables internal, external and interim in terms of the work to be completed, including project management. (Practice Standard for Work Breakdown Structures Second Edition, 2006) Beyond the creation of the WBS, if the rule is applied down to the activity level of the project schedule, then 100% of the relevant activities will have been identified. (Haugan, 2002, p 17) No matter which approach one takes for WBS development, the end result should always represent the full scope of the project. By effectively utilizing the 100% Rule, project managers can ensure that the desired result is consistently achieved. Related Tools and Documents for building the WBS To supplement the importance of the WBS as a foundational scope definition step developed during project planning, the authors will provide contextual linkage to related project management documentation and will clarify these documents as the starting point for WBS development. The primary building blocks for the WBS are the documents the parties engaged in project inception and planning use and share to describe the boundaries of the project. These are documents that discuss the outcomes or objectives to be accomplished, the resources that will be made available for use, the expected performance objectives of the final product, end-product acceptance criteria, etc. Often these data and key informational elements are found in project chartering documents, Statements of Work (SOW), Requests for Proposal/Quote (RFP/RFQ), Contracts and Letters of Intent (LOI). In these documents the project manager will find words that describe outcomes in very specific terms. Most importantly, the project manager must be on the lookout for words that solidify commitment and articulate boundaries words such as shall, must, will; will not, must not, and shall be delivered on or before xx/xx/xxxx (a particular date). These are examples of contract and agreement wording that describe the specific outcomes of the project and product to be delivered. These words help the project manager, the customer and the provider organization agree on what a complete, acceptable solution will be. Once understood, these types of documents, and the words contained in them, help the project manager frame the WBS for the remainder of the project. Brief examples follow:

9

Contracts, Statement of Work (SOW) or Statement of Objectives (SOO) The project contract, Statement of Work or Statement of Objectives often contain the three key boundaries for the project the triple constraint, for these documents often succinctly describe what the customer will be purchasing from the supplier, described as end products. In these documents the project manager will frequently find statements that describe the final deliverables of the project and may contain words such as: Project A will have 5 features, each performing one of the five following functions, (numbered and briefly detailed), will be available in production for end-users by January, 1, 2099, and will be delivered at a cost of no more than $99M. This key information is often contained in larger documents that also describe a variety of standard contractual features and functions (frequently referred to as boilerplate) that control activities between the parties and can be easily overlooked. The project manager should attempt to locate copies of the contract agreements, SOW and SOO whenever possible these are fundamental inputs to WBS creation. Project Scope Statement The projects scope statement is often the single paragraph, page or documented statement that describes, in as few words as possible, the complete objective(s) of the project its purpose, its characteristics, its attributes, its form and function. This statement is frequently the single description that accompanies or details the project title that appears in the topmost box or element in the WBS and is included in the WBS Dictionary. The project scope statement is often the customer's only description of what he/she perceives is the reason for funding the effort and frequently describes the customers vision of the project outcome in terms of deliverables. The project manager should not begin creating the WBS without first understanding the scope of the project. If the project scope statement isnt written, the project manager should work to create the scope statement with assistance and approval from both the sponsor and provider organization leadership before creating the WBS. The project scope statement is one of the most important inputs to WBS development. Project Charter The project charter represents the authorizing document provided jointly by the sponsoring and provider organizations for project initiation. The project charter frequently describes the project team in great detail, the commitments being made by the contracted parties and the spirit as well as the letter of the agreement between them. In this document the project manger will often find the project Mission, Vision and Objectives, stated in terms of the sponsoring company/organizations overall strategy. This is a high-value and important building block, along with the project scope statement, of the WBS for the project manager - as these statements describe in a few words, how the project is placed in the overall corporate/organizational strategy and imply the relative importance of the effort to the leadership of the organization. In addition to containing statements regarding commitment to the project by both organizations, the project charter may also describe performance incentive plans that articulate bonus payments for early delivery or penalties for missed requirements, cost overruns or delivery date slippage. It may also describe the minimum criteria for acceptance of a component of the project that is of particular interest - or the entire project as a whole. Finally, the project charter may describe what elements will be measured to validate achievement of objectives and how those measurements will be conducted. At the very least, the Project Charter is a key compendium of information for the project manager and is used as an input for the development of the WBS.

Because statements of scope in these documents are very concise and are often expressed in general terms as high level customer requirements, they need to be re-stated in greater detail in order to enable project planning. The WBS is the tool that enables this detailing and elaboration of the work of the project. It thereby provides visible traceability of project work to the customers high level specification of

10

the product or result to be delivered by the project. And thus the WBS is the pivotal tool for translating the customers expressed needs, wants and expectations into the project that will deliver them.

Following the creation of the WBS, the project manager will be challenged to apply and integrate the WBS into other project processes and Knowledge Areas (PMBOK Guide - Third Edition). To enable this, a number of tools are available to the project manager. We will discuss a few of these below, however, the authors would like to point out that the examples provided are not intended to be an exhaustive or complete list of tools, but rather examples of how other information available to the project manager can enhance the value of the WBS.

WBS Dictionary The WBS Dictionary is an accompanying document for the Work Breakdown Structure and is used to further detail and define the scope elements described in the WBS itself. While the WBS is limited and contains brief titles and hierarchical indications, the WBS Dictionary explains the content of each WBS element and can describe in great detail the scope outlined in each parent or child element listed. The WBS Dictionary is linked to the WBS by its hierarchical indicator and can contain (not limited to):

A scope statement that details and articulates the content of the WBS element Budget and accounting levels Resources assigned Specific outcomes or direction regarding the WBS element Dates, milestones, sub-milestones Risks and contingency plans Decision analysis points Escalation processes Approval hierarchy

The WBS Dictionary is used by the project manager to reinforce the content of the WBS and to clearly describe the scope outlined in the WBS for the project. The WBS Dictionary is maintained and versioned under formal Change Management processes, as is the WBS. Organizational Breakdown Structure (OBS) A natural accompaniment or outcome of the WBS, the Organizational Breakdown Structure is developed by the project manager to further explain how the projects work, once defined by the WBS, will be accomplished by the Project Team or the existing organization from which the projects resources will be taken. Regardless of the actual organization structure, the OBS articulates, for the stakeholders as well as the project manager, who will be performing the work of the project and how those involved with the various deliverables described in the WBS are, or will be organized. This document speaks to project organizational alignment rather than resource and task assignment, and together with the Network Diagram, aids the project manager in bridging the span between project scope definition and project schedule. The OBS also clearly shows project financial oversight responsibility at the work package level by indicating the hierarchical relationship among the personnel responsible for each of the cost accounts found in the project.

Just as the WBS decomposes the work of the project into deliverables, the OBS decomposes the organization of the resources producing the deliverables to clearly show the relationship between the work and the organization that will direct the activities of the resources. Resource Breakdown Structure (RBS) The Resource Breakdown Structure extends the OBS and describes specifically which human resources possess which skills, and often which specific individuals will be performing specific tasks. While the OBS is an organizational representation of the team, the RBS is a skill/competency/attribute list and an association of those skills/competencies/attributes to individual tasks and events. The RBS is additionally important to the project in that it is not restricted to human resource definition. The RBS can reflect non-

11

human resources including (but not limited to) budget, systems and facilities. By detailing the projects resources in this way, the project manager can forecast resource consumption, cost, duration and delivery. Responsibility Assignment Matrix (RAM) The Responsibility Assignment Matrix helps the project manager link the WBS and the OBS. By defining responsibility, accountability and authority, this document shows which of the projects resources will be responsible and accountable for delivering particular components or WBS elements. The RAM additionally assigns cost to appropriate resources and provides a foundation for resource utilization with associated cost tracking. Provided as a table, this document depicts an easily-explained relationship between project outcomes and the project team members who will be overseeing delivery as well as those responsible for delivering project outcomes.

SUMMARY The concept of the WBS has evolved to meet the evolving requirements of the project management profession. This is an evolution which has elaborated the core concept of the WBS: a tool to enable the definition, development, communication and execution of project scope. And thus the WBS is the pivotal tool for translating the customers expressed needs, wants and expectations into the project that will deliver them. LOOKING AHEAD: Present practice and trends suggest that WBS evolution will continue into the future. Initial research indicates a growing reliance on the WBS to document project scope and broader acceptance of the WBS as a foundational building lock for project planning and delivery. From a survey focused on WBS usage by project management professionals from around the globe conducted by the Practice Standard for Work Breakdown StructuresSecond Edition Core Team between February of 2005 and February 2006, results have shown that: Today, 87% of survey respondents say that they use the WBS as a planning tool for project

management activities at least half of the time - while 37% use the WBS all of the time 99% of respondents stated that they will use the WBS at least as much as they do today and over

60% will use it more often. Of those who use the WBS frequently, their main objectives are to support the following:

o Activity definition o Resource Planning o Scope Planning and Definition o Cost Estimating o Risk Planning

91% of the respondents stated they were either satisfied or very satisfied with the ability of the

WBS to meet the objectives Three fourths of all respondents who use WBSs employ them for projects of less than one year in

duration. It is the opinion of the authors, that the WBS is central to the practice of Project Management. The survey results illustrate the broad acceptance and use of the WBS in project management practice today. Surprisingly, the results also indicate that a great number of project managers employ the WBS for what could be considered short-duration projects.

12

While the Practice Standard for Work Breakdown Structures (First Edition) is in active use today, a number of respondents to the survey have recommended improvements many of which have been incorporated into the second edition. In conclusion, as suggested by this paper, the WBS has evolved as a useful Project Management tool significantly since its inception. It is clear from current trends that this evolution will continue into the future and is supported by the latest release of the practice standard. The practice standard will also continue to evolve in parallel with generally accepted project management practice. (Note: for additional detail regarding survey results, please see the completed survey attached)

13

BIBLIOGRAPHY Author?. 2002. Independent Verification and Validation White Paper. December. Macdonald Bradley,

Inc., retrieved 2/20/2005, Website: http://www.mcdonaldbradley.com/comps/white%20papers/IVV%20white%20paper.pdf

Berg, Cindy and Colenso, Kim. 2000, Work Breakdown Structure Practice Standard Project WBS vs.

Activities, PMI Network, April. P. Chapman, James R. 2004. Work Breakdown Structures, Version 2.01, (November, 2004) retrieved

2/22/05, Website http://www.hyperthot.com/pm_wbs.htm Cleland, David I. 1964A. Air University Review, November-December. P. 13. Cleland, David I. 1964B. Why Project Management? Business Horizons. Winter. P. 81. Department Of Defence. 1995 Work Breakdown Structures For Defence Materiel Projects,

Commonwealth of Australia, Australian Defence Standard Draft Def(Aust)5664 Issue A. Department of Defense, 1975. Military Standard Work Breakdown Structures for Defense Materiel Items,

(MIL-STD-881A), Washington DC, 1 November 1975 Department of Defense, 1998. Department Of Defense Handbook. Work Breakdown Structure MIL-

HDBK-881 Washington DC. 2 January 1998 Department of Energy. 2001. Performance Based Contracting: Development of a Work Statement.

August, retrieved 1/18/2005, Website: http://www1.pr.doe.gov/acqguide/AGChapter37.htm Dinsmore, Paul C. 2000. Enterprise Project management: A Road map for Getting off to the Right Start.

PM Network. June. P. 27. Githens, Gregory D. 2001. Manage Innovation Programs with a Rolling Wave. PM Network. May. P. 35. Globerson, S. 1994. Impact of various work-breakdown structures on project conceptualization.

International Journal of Project Management. 12 (3), p. 165. Grove, Cornelius, Hallowell, Willa and Smith, Cynthia J. A Parallel WBS for International Projects. PM

Network. March. P. 37. Halli, Wayne. 1993. PM Network. May. p. 12. Haugan, Gregory T. 2002, Effective Work Breakdown Structures, Management Concepts: Vienna, VA. Homer, John L and Gunn, Paul D. 1995. Work Structuring for Effective Project Management. Project

Management Institute 26th Annual Seminar/Symposium. New Orleans LA, October, 1995, p. 84. Kast, Fremont and Rosenzweig, James. 1961. Weapon System Management and Organizational

Concepts. Journal of American Military. December. Kerzner H. 1997. Project management: A systems approach to planning, scheduling, and controlling (6th

ed.). New York: John Wiley & Sons Kerzner H. 1996, The Growth and Maturity of Modern Project Management. 27th Annual

14

Seminar/Symposium October 1996, Boston MA: Project Management Institute. Kloppenborg, Timothy J and Opfer, Warren A. 2002. The Current State of project management Research:

Trends, Interpretations, and Predictions. Project Management Journal. V. 33, No. 2. Luby, Robert E., Peel, Douglas, and Swahl, William. 1995. Component-based Work Breakdown Structure

(CBWDS). Project Management Journal. December. P. 38. Mansuy, John. 1991. Work Breakdown Structure: A Simple Tool for Complex Jobs, Cost Engineering

Vol. 33/No. 12, December. National Aeronautics and Space Administration. 1962. DOD and NASA Guide. PERT Cost Systems

Design. June 1962. Washington DC: Office of the Secretary of Defense. National Aeronautics and Space Administration. NASA PERT and Companion Cost System Handbook.

Washington, DC. October 30, 1962 Pritchard, Carl. 1998. How to Build a Work Breakdown Structure, The Cornerstone of Project

Management. Arlington, Virginia: ESI International. Project Management Institute Standards Committee. 1987.???? A Guide to the Project Management

Body of Knowledge (PMBOK Guide). Darby PA: Project Management Institute.1987. Project Management Institute Standards Committee. 1996. A Guide to the Project Management Body of

Knowledge. Darby PA: Project Management Institute. Project Management Institute. 1969. Articles of Incorporation Project Management Institute. 2000. Practice Standard for Work Breakdown Structures (PMBOK Guide

2000 Edition). Newton Square, PA: Project Management Institute. Project Management Institute. 2004. Project Management Body of Knowledge (PMBOK Guide - Third

Edition.). Newtown Square, Pennsylvania: Project Management Institute Inc. Project Management Institute. PMI Today, April 2003. Rad, Parviz F. Advocating a Deliverable-oriented Work Breakdown Structure. Cost Engineering, Vol 41,

No 12, Dec 1999, p 35. Raz, T. and Globerson, S. 1998. Effective Sizing and Content Definition of Work Packages. Project

Management Journal. December. Shtub, Avraham. 1997. project Segmentation a Tool for Project Management. International Journal of

Project Management vol 15, No. 1. p. 15. Stewart, John M. 1965. Making Project Management Work. Business Horizons. Fall. 1965. Ward, Gregory F. 2001. The WBS Dictionary Extending the Work Breakdown Structure, Proceedings of

the Project Management Institute Annual Seminars & Symposium. November. Nashville TN: Project Management Institute.

Webster, Francis M. Jr. 1999. They Wrote the Book. The Early Literature of Modern Project management.

PM Network. August.

15

Current WBS Standard as a Tool

1. How often do you use a Work Breakdown Structure (WBS) as a planning tool for project management activities you lead or participate in?

Number of Responses

Response Ratio

100% of the time (SKIP TO Question 5) 90 37% 75%-99% of the time (SKIP TO Question 5) 79 32% 50%-74% of the time (SKIP TO Question 5) 45 18% 25%-49% of the time (SKIP TO Question 5) 13 5% 1%-24% of the time (SKIP TO Question 5) 12 5% Never 5 2%

Total 244 100% 2. If you have answered never, Is it corporate policy not to use a WBS?

Number of Responses

Response Ratio

Yes 1 5% No 18 95%

Total 19 100% 3. If you have answered never, Do you use other tools instead of a WBS for planning project management activities?

Number of Responses

Response Ratio

Yes 3 16% No 16 84%

Total 19 100% # Responses 1 Excel 2 Product Based Planning 3 PBS & OBS as well as wbs 4. If you have answered never, Why do you prefer to use other tools besides the WBS for planning project management activities? # Responses 1 due to the size (small) and complexity (low) of projects I manage 2 not instead but as well - wbs is only part of the scope and responsibility modeling 5. What are your objectives when using a WBS please check all that apply.

Number of Responses

Response Ratio

Activity definition 207 86% Resource planning 171 71% Cost estimating 127 53% Cost budgeting 84 35% Risk management planning 106 44% Scope planning 160 67% Scope definition 165 69% Other, Please Specify 37 15% 1 Sanity check 2 Earned Value Performance Measurement 3 Communication planning, Quality planning 4 Earned Value Performance Management 5 Communication tool 6 Quality Planning 7 Team building 8 Contract/SOW approvals 9 Communication 10 Buy in from team and customer 11 matching product/project assembly structure

16

12 Schedule preparation 13 Procurement Planning 14 Logical Org/Structure of doc/software/equipment 15 dependencies, timeline 16 Scope baseline defining project deliverables 17 forecast completion date and look at dependencies 18 Progress reporting 19 Critical Path Analysis 20 The team builds and agrees on WBS and estimates 21 Confirmation of scope 22 Stakeholder Directory 23 Visualize the entire project globally logically 24 Monitoring, progress, schedule 25 Assumption and Uncertainty Definition, Gap Analysis 26 Dependencies, Critical path 27 quality planning 28 objective presentation of project to stakeholders 29 Scope control integrated with effort reporting 30 schedule planning, status monitoring 31 Requirements Management, Specification Tree Development 32 Time estimation and progress measurement 33 Grouping Phases of Work 34 Communication to team and stakeholders 35 Documentation 36 all the others flow from good scope 37 Actual Cost Tracking 6. How satisfied are you with the ability of the WBS to meet this objective?

Number of Responses

Response Ratio

Very satisfied 95 40% Satisfied 122 51% Neither satisfied nor dissatisfied 16 7% Dissatisfied 6 3% Very dissatisfied 0 0%

Total 239 100% 7. What is the size of project for which you use a WBS? Please check all that apply.

Number of Responses

Response Ratio

Projects which are large compared to others in my company 184 77% Projects which are medium compared to others in my company 189 79% Projects which are small compared to others in my company 103 43% 8. What is the complexity of the projects for which you use the WBS? Please check all that apply

Number of Responses

Response Ratio

Projects that are highly complex 186 78% Projects with some complexity 204 85% Project that are not complex 90 38% 9. What is the longevity of the projects for which you use the WBS? Please check all that apply.

Number of Responses

Response Ratio

Less than one year 175 74% 1-2 years 180 76% 3-5 years 71 30% 6 or more years 52 22% 10. In your opinion, will you use the WBS more often or less often in the next 3-5 years?

Number of Responses

Response Ratio

More often 147 62%

17

As often 88 37% Less often 4 2%

Total 239 100% 11. What component(s) of the WBS has changed the most over the last 5 years?

1 The use of the WBS as a cost accounting tool. 2 As clients & co-workers in the US begin to understand what "management by

deliverables", they are better able to comprehend making the WBS deliverable based. 3 WBS by Phase 4 equipment and hardware human resourcing 5 definition and guidance 6 Greater Number of levels 7 The relation Work Package versus Activity 8 This has become more extensive and better defined 9 Standards for usage 10 The focus has really shifted from activity-based to deliverables-based. I think there's

more acceptance for the need for the WBS to be more fluid so that it can adapt to the needs of the project, rather than rigidly structured to force the project into a specific structure.

11 level of detail 12 Definition of work packages for vendors is now far more detailed. 13 When we first started using WBS, it was merely to map out and monitor schedules and

some scope; now we use it as an integrated tool to monitor cost, schedule, and scope. This year we have begun to use the WBS for planning risk.

14 Contractor WBS going down two more levels 15 1) WBS Dictionary 2) Work Packages 16 Level of detail, reflecting the whole complexity 17 Availability of more "standard" WBS's for specific project lifecycles has increased 18 None as far as I know 19 Inclusion of "soft" activities such as public consultation 20 For myself, none. I may be considered "old school," but I still use a WBS as I learned to

use the WBS 20+ years ago and have not read or been introduced to anything that indicates a "better" usage that what I learned.

21 Our company adapted the WBS usage policy in 2004 as our corporate standard for project initiation so we don't have much to compare to.

22 no significant change 23 I have just started using this concept. 24 More awareness by participants More templates and standards 25 Level of decomposition 26 Linkages with other systems 27 shifted more from action's to milestones 28 Less focus on risk around deliverables, but more focus on what the actual deliverable

should be. 29 Introduction of activities, to which I totally disagree. WBS should be defined as in the

MIL-HDBK-881A standard 30 level of detail of the work package 31 Constant battle between functional, organizational, & product partitioning - multi-view

environments are now more effective in sophisticated activity network tools. 32 Alignment to Product Breakdown Structures 33 Definition about what should be included/excluded...accounting for 100% of the work 34 WBS has become more integral to overall schedule / cost planning of projects. 35 Level of detail has increased. Importance of WBS throughout entire planning and

execution of project. 36 Scope - inclusions, activity definitions - modifications 37 Cost estimation

18

38 Scope. Resource allocation. 39 Work Package 40 we focus on the WBS being deliverable-oriented 41 The components haven't changed, but the level of detail for each activity has increased. 42 Development of WBS templates to support a product development methodology 43 For me, not much. But I've notice more people using quality gates or entrance and exit

criteria before going from one phase to another 44 Managing organizational change and stakeholder communication 45 I find that the company I work for defines much of how the WBS is used. 46 Components have not changed as much as our approach/application/use of the WBS.

Previously viewed more as an activity list. 47 I am not aware as I have recently become a PMP 48 I am not aware of changes to the WBS definition. I am becoming more skilled in creating

and using the WBS. 49 Estimating time (Duration vs. Effort). 50 Introduction of a generic project life cycle on top of the traditional PBS (product

breakdown structure) 51 The team builds and agrees on WBS and estimates before the Plan is finalized. And as

life changes, sometimes WBS needs to change so the WBS and the Plan most be evolutionary to the Times. The Team must agree and be part of the evolution.

52 The injection of time phasing 53 The project scope management plan 54 did not start using it until 2005 55 Project Management 56 On entry level: deliverables acceptance and its breakdown. On level 2-5: various

elements in cost/finance, HR, procurement, quality, risk, value, and communication aspect.

57 level of detail is increasing 58 Not sure but I know that WBS needs to be explained in more simple terms using

examples. People tend to do a detailed WBS down to the individual tasks and it is not meant for this. I was once faced with WBS elements of less than 5 hours!!!! Yes, it was a MASSSIVE WBS. I trimmed it generously.

59 level of detail required in WBS...now going down to 7+ levels 60 Cost account 61 Resource Leveling 62 Degree of complexity 63 split task 64 The Structure of WBS. 65 attempts to use WBS for risk management planning and cost estimation, rather than

only resources and task planning 66 The standard to use the WBS 67 Usability of software tools. 68 Calculating float and earned value 69 level of details, input to scheduling and project control tools 70 down time 71 Using the WBS as a basis of estimates 72 The development and integration of a distinct WBS for "project management

deliverables" and one for "product lifecycle deliverables" 73 The number of levels used. Currently use more levels now than in the past. 74 Deliverables 75 None, it's only been around a year or two. 76 Don't see 77 planning concepts 78 Management reviewing and understanding them has increased

19

79 Work Package assignment and modification. Email notification to management when Work Package SLAs are not in compliance.

80 Define Scope as clear as possible and as detail as possible 81 Definition of deliverables vs. standard activities on the project. It has been difficult to

separate PM/Product Development process activities (methodology) from actual project deliverables sometimes.

82 Using a product breakdown structure orthogonal to the WBS. 83 WBS should be tailored to suit every project - not be an organization standard 84 I usually do a matrix type WBS and then add columns for cost, duration, personnel

resources assigned, tools required etc. This way I get a complete matrix of all the needed information for the specific task.

85 less waterfall and more overlapping 86 I don't think the WBS has changed at all, but if you mean our understanding of it, then

I'd say "inclusion of project management deliverables and tasks." 87 Definition at level 6 88 Concept of work packages 89 Peoples knowledge and ability to use the wbs but there hasnt been much

improvement. in general people are ignorant of how and why to use any BS 90 focus on deliverables vs. tasks 91 WBS Level 92 The standard has helped clarify it is deliverables oriented. 93 Lack of detail necessary to plan properly. 94 The WBS dictionary, this has become vital in "What is in Scope" vs. "Out of Scope".

Without the dictionary, projects with longer periods of performance become problematic. 95 Scope Definitions have become more details to increase understand of task & during

shorter (i.e. a day or less) 96 the focus on the activities - work elements - and less on schedule time and duration

12. Which component(s) should be updated in the next 5 years? 1 Quality standards for the WBS; Better integration between the WBS & related PM

components (scheduling, risk management, EVM, etc.) 2 equipment and hardware human resourcing 3 assessment ability 4 The interrelation between Work Package and Quality, Communication and Risk

Management 5 Methods defined in WBS can be refined 6 creation of a standard WBS for our company so that cross-project activities can be

reported 7 Cost, and risk identification and mitigation. How to use the WBS as a tool as a

communications tool and how to report on performance of WBS. 8 the Macro vision 9 1) Control Accounts 10 More clarity in the relationship of the "deliverable" to the activities.

Refinement/documentation of the processes to 1) identify all deliverables and 2) to drive down to the activity level from the deliverable. Best practice for incorporating PM lifecycle in to the project lifecycle and representing PM deliverables in the WBS

11 I'm not sure, I think its emphasis in deliverables and then in activities should be stressed 12 Better tools to incorporate into other elements integrated with cost and schedules etc... 13 Client awareness 14 template availability 15 Cost/effort reporting tools using the WBS entries as key accounts 16 Integration of WBS components, phase versus product WBS alignment. Importance of

WBS as a comprehensive planning tool. 17 The WBS should be based on tangible products and services as defined by the MIL-

HDBK-881A standard. Please keep activities out of WBS.

20

18 Emphasis on levels of integration and how they play across the project lifecycle; formalizing a multi-view partitioning at third(?) level of WBS to minimize complexity of artificially creating lower levels to satisfy different management views.

19 Costing 20 Using WBS more consistently. Establishing schedule based on WBS, as Primavara

software requires. 21 As indicated in 11 22 Risk management 23 Activity and Scope. 24 WBS Dictionary 25 More examples. Incorporate information from "Effective Work Breakdown Structures" --

best book I know on the topic. 26 improved integration with project schedule development and risk management 27 1) Benefit realization planning 2)External dependencies/inputs 28 PMI needs to recognize how the business (non-PMP's and non-PM's) affects the WBS

and what they expect from it. It's not just a tool for the PM, but can also serve as a tool for the business owners, if presented in the proper manner.

29 Tying the WBS for projects to WBS for programs and portfolios. How to tie an organizations portfolios/programs/projects together through the use of the WBS

30 Measurement 31 Integration of how to integrate (dovetail) the PBS into the Project life cycle (phased) in

order to become a WBS that comprises ail deliverables to be done. This means deliverables from the product oriented processes as well as the deliverables from the project management processes

32 The team builds and agrees on WBS and estimates before the Plan is finalized. And as life changes, sometimes WBS needs to change so the WBS and the Plan most be evolutionary to the Times. The Team must agree and be part of the evolution.

33 The injection of time phasing. The WBS is used too much as a "scheduling" tool. We need to go back to basics and use it only for the breakdown of work. The WBS is not well suited for phasing (scheduling) work.

34 WBS dictionary 35 Risk Management 36 Depends on the applicable solution and customer requirements. 37 WBS dictionary components and linkage to WBS 38 WBS is not well understood. Use modern terms? Use more graphics? Use various types

of examples to explain? Sell the usefulness of it? Simple is better. 39 Dictionary information to accompany the WBS, it is difficult by a 'title' to understand what

was the intended scope of that item - different people interpret the WBS title differently 40 Numbering of the Project itself. 1.0 is a non-sense. It should read "1". In a series of

books, the first one is "Volume 1", not "Volume 1.0"... 41 Concurrent tracking 42 Need models for varying types of standard projects. 43 The Structure of WBS. 44 perhaps an inclusion of its practical use for small projects ("simple WBS") rather than

the current complex, large project focus only 45 development 46 Standards for WBS development. 47 Break down of time. What I mean specifically, when assigning a resource the

assumption is that anyone assigned a task that takes a total of 10 days, is 100% committed to the task. What needs to be investigated further is that the same task may take 10 days, but the resource only needs to be committed to a 20% time commitment due to other projects' demands.

48 setting time 49 Standardize across industry or specific function (i.e.) software development

21

50 The sections that address sequencing deliverables, especially when one deliverable serves as input to deliverables in more than one later phases of the project. For example. One deliverable might be a "technical requirements" document. It is the input to a deliverable called "technical design" in the design phase and to the "Test Plan" deliverable in testing phase AND to the "Deployment Plan" in the Deployment phase. In this example, the Requirements acts as input to Planning deliverables, possible to the sub WBS for Testing and Deployment and the critical path of the Design deliverable. Although this may vary by discipline, it creates several issues with traceability, change management, resource leveling, and in what phase to place the planning deliverable for a specific phase (Do you wait to the testing phase to create the Test Plan?, not without creating artificial slack).

51 Rolled out to more of the organization, make versions specific to different organizations. 52 Resource 53 operation results 54 Team utilization. I find that as the PM, I am the primary creator and user. Having

technically competent team members creating a WBS can be difficult. Often times, I lead them through the exercise by either creating the WBS and having them review it and update it or step them through the creation process by "white boarding" the activities necessary to complete the overall task

55 Visual display of the WBS. Report and query generation for upper management. 56 Lack of understanding as a general business planning and reporting tool Management

stipulations that Reports be made at particular WBS level - showing a lack of knowledge of what the WBS is for Integration of Code of accounts into cost accounts The most important thing that can come out of the new WBS is a common standardization of terms for work, activity, task, work package, process, etc. And the Hierarchy order of how these terms interact - the definition of the Taxonomy. Scheduling Tools use Task and Activity interchangeably and this is confusing to general business managers

57 include cost estimating and resource planning while doing the WBS 58 A more simple way to input/organize WBS elements into a computer format without

going to the detail of MS Project tasks. A simple way to identify "typical" deliverables as a form of checklist to ensure the creation of the WBS addresses all the relevant concerns of a particular industry or project type.

59 As above - WBS is an individualized tool for individual projects. It can only be templated for those projects that are becoming processes where the tasks are standardized

60 I don't really have an opinion. I modify it as I need to to meet my needs. 61 We have to admit that technology has an impact on how we manage. Thus, we should

not be afraid to let concepts, stemming from the use of project management scheduling software, impact the development of the standard.

62 All strategic levels after maturation 63 Work packages terminology should be deleted and the lowest level of the WBS be

called Activities. 64 education on how to use the BS 65 Clarify the last, lowest level, work package. 66 The integration of the WBS within the project management framework of the company. 67 There should be something in the WBS that reflects the negotiation process. In other

words sometimes during negotiations the Program Manager will have to make a concession or take something for less than estimated. This should be reflected in the WBS rather than just the cost negotiated. Just because you negotiate work it doesn't mean the work goes away, it just becomes more of a risk. This is the area we are the least effective in putting in the WBS, those areas of risk that we create ourselves based on negotiations.

22

PMI's Practice Standard for Work Breakdown Structures 13. Have you read the PMI's Practice Standard for Work Breakdown Structures?

Number of Responses

Response Ratio

Yes 141 59% No 88 37% Not sure 10 4%

Total 239 100% 14. Have you used the PMI's Practice Standard for Work Breakdown Structures?

Number of Responses

Response Ratio

Yes 107 45% No 107 45% Not sure 26 11%

Total 240 100% 15. Please rate your level of agreement with the following statements regarding PMI's Practice Standard for Work Breakdown Structures: The top percentage indicates total respondent ratio; the bottom number represents actual number of respondents selecting the option

1 Strongly

Agree

2 Somewhat

Agree

3 Neither

agree nor disagree

4 Disagree

5 Strongly disagree

1. I find the framework of the Practice Standard for Work Breakdown structures easy to follow.

21% 40

38% 72

34% 64

5% 10

1% 2

2. I find the framework of the Practice Standard for Work Breakdown structures to be very useful.

21% 39

36% 66

34% 63

8% 14

2% 3

16. Please rate the usefulness of each of the following content areas/features. The top percentage indicates total respondent ratio; the bottom number represents actual number of respondents selecting the option

1 Very useful

2 Somewhat useful

3 Not at all useful

1. Framework 58% 95

41% 68

1% 2

2. Terminology 52% 86

45% 75

3% 5

3. Level of details 38% 63

54% 89

7% 12

4. Resource planning 39% 64

50% 82

11% 18

5. Cost estimating, cost budgeting 34% 57

56% 93

10% 16

6. Risk management 36% 59

50% 81

14% 23

7. Scope planning and scope definition

57% 95

39% 65

5% 8

17. What in the current Practice Standard is unclear and should be clarified or explained further in the next edition? 1 Need more examples of high-quality WBS construction 2 Items not related to the WBS (e.g. scheduling issues, activity planning); WBS Quality 3 Level of Effort elements. Relation between WBS elements (nouns) and project

activities (verbs). 4 Risk Management 5 The issue hasn't been clarity in my experience so much as the individual nuances of a

given client site.

23

6 That there must be at least two children to a parent 7 The level of classification for the cost estimating. 8 Provide charts showing the hierarchies of the examples in appendices. 9 The WBS examples should be progressively done, by steps (as PM phases). 10 Off hand, cannot say. It should be printable from the web-site. I just ordered the bound

copy, but I suspect most people will not take the time to order it and will not want to continuously have to pull up the .PDF off the website to refer to it. If you want it to be widely adopted and used, you need to make it more accessible to practitioners. I didn't even know it existed until I got this survey.

11 The entire treatment is too verbose for the high level of information covered. Should be able to trim it down to something more manageable, say 30-35 pages.

12 Level of detail - provides examples of how to decompose and to what level. Resource Planning - how to level resources Cost estimating and cost budgeting - the difference between estimating and budgeting should be made clearer Risk management - this remains a new area for many of us and the example does not provide sufficient clarification Scope planning and scope definition - many persons in my field (international development) need a clearer understanding of scope definition

13 Information technology projects should needs more attention. 14 Examples are not necessarily consistent with the practice standard. Better examples

could be found. 15 Relationship with other standards such as PMBOK(r) Guide, OPM3(r), etc... 16 What components must be apart of a WBS, i.e. resource skills, risk magnitude,

deliverable description, level of detail required to properly management project 17 That the scope can be decomposed into work packages in many different ways (by

function, by project phase, by deliverable, etc.) and that whatever method is chosen, the work packages should be the identical.

18 There should be a direct comparison to Mil-Std-881 (maybe reserved for a DoD appendix, like with the PMBOK Guide?). Necessary levels and recommendations on multi-view partitioning at some level.

19 I like to see examples. 20 Procedures to structure tasks and activities, project process-wise or product process-

wise? 21 Risk Management 22 Terminology and its derivatives could be more lucid. 23 Level of details 24 Everything. I found it almost completely useless. Look at "Effective WBS" by Haugan

for an example of what this document should have been. 25 Please Please Please clearly distinguish between a WBS and a project work plan.

Many project managers are using the terms interchangeably. 26 A period of exposure and use is needed to determine this answer 27 building a WBS and standardizing the levels 28 A clear delineation between projects' life cycles and/or products/deliverables. 29 PBS versus PLC versus total WBS (the dovetailing process) 30 Take it from a standard to How to guide. 31 Using the WBS, the resource planning seems to be more clarified 32 If the WBS should contain verbs or substantives 33 1. Applicable input & follow up after WBS (benchmark to PMBOK 3rd Edition where

flow chart is provided to understand the whole picture). 35 Rules of thumb for decomposing. 36 Resource planning 37 downtime 38 estimating resources and costs, scope 39 Risk management 40 Clarify the use of the terms activities, deliverables, tasks and phases

24

41 Personally, I do not like the fact that control account (CA) is above the WBS element. I work with a CA under the lowest level element (not a work package) and have them intersect with the OBS.

42 I THOUGHT THE STANDARD NEED MORE DETAIL TO EXPLAIN CONCEPTS AND BE USEFUL DIAGRAMS.

43 Resource planning and cost estimating & budgeting 44 Too often, the PM framework and the actual WBS are interwoven in the WBS OR the

PM framework is not included at all. 45 Defining the relationship between Project Risk and the WBS. 46 The relation of the WBS with other knowledge areas and EVM. 47 the Hierarchy of terms Taxonomy of terms 48 Cost estimating 49 The scope of wbs: deliverables, tasks or both. 50 WBS is the ultimate scope definition tool and is central to all aspects and functions of

managing a project. The standard should address structure and format of WBS not content

51 PMBOK 2000 presented the project management processes within a phase; some people think that phases can only happen one after the other; some think only big projects, like sending a man to the moon, has phases; some complain that using initiation, planning, monitoring & controlling, and executing PM documentation, through every phase would just be too cumbersome. Somehow, maybe some case studies could show how some managers might be more informal than others, requiring less structured, but equally important, communication to convey that tasks and minor deliverables are getting done.

52 The definition of work packages 53 The whole volume is extremely poor. 18. In your opinion, what enhancements should be made to the Practice Standard for Work Breakdown Structures? 1 Job-aids, templates, cases need to be added and more guidance about how to

construct quality WBSs 2 Definition of WBS Quality Better focus on WBS specific elements 3 More graphics. How to customize WBS to particular projects or applications that may

have special needs. 4 Less terminology 5 Since my experience is limited to IT systems, my opinion would tend to be slanted. My

suggestion would be to develop enhancements that could be applied as generically as would be practical.

6 Indicate that indenting is NOT WBS, i.e. the format as used by Microsoft Project. The WBS is not

7 PMI has to give more attention to the PM part of WBS. Product is very simple. The problem and the important thing is just the PM side of WBS activities. It should also be pointed that Quality, Risk and Communication Activities has to be put straight into the WBS map. With examples

8 This should cover to take care of various changes from the Customer end and how to tackle it

9 Industry examples, templates. For instance, IT, construction, manufacturing, etc. The bicycle example is great for getting general concepts across to all learners, but you also need to target ways to use WBS in the various disciplines so they feel more comfortable with applying it.

10 more examples from outside of the traditional engineering, IT type industries 11 Ensuring people understand that Outlining is not WBS 12 An Arabic Version with simple and easy terminology 13 Explanation of working examples of projects in WBS standard will certainly help.

25

14 Describe the development of a WBS with a team. Recommend standard labeling of WBS levels - show how different labels can describe the same deliverable conveying different levels of understanding. For example - "Environmental Impact" vs. "Environmental Impact Report for Tower siting".

15 It should include a How to section, with practical recommendations of use. 16 Produce real examples from projects and show level of breakdown required for a

deliverable. 17 The link (roll wave planning) between Scope, Time, cost, risk and quality. 18 Which is the best practice, phase alignment or product alignment of top level WBS 19 There is some controversy in the field as to whether the elements of a WBS ought to

have a standard format of verb-noun ("Test Software") or noun ("Software Test"). Whether there ought to be a standard at all ought to be addressed, as well as my belief that whatever method is chosen, it ought to be consistent across the WBS at a given tier.

20 Please leave out the idea of using project phases for the second level. 21 There should be a direct comparison to Mil-Std-881 (maybe reserved for a DoD

appendix, like with the PMBOK Guide?). Necessary levels and recommendations on multi-view partitioning at some level.

22 Please put in examples 23 Level-wise procedures to structure tasks, activities, work package. Definition of tasks,

activities and work packages. 24 Standard templates 25 More information on Cost budgeting. 26 Should have more models 27 Practical tips for how to work with teams to develop the WBS. Examples of WBS docs

as they take shape. Lots of examples of real WBS documents. 28 Distinguish between a WBS and a project work plan. The level of detail required to

fully estimate a project (6 or more levels) vs. the level of detail to track a project (3 or 4 levels). Develop a WBS structure or template that complies with the Project Management Lifecycle: Initiating, Planning, Executing, Controlling, Closing.

29 A period of exposure and use is needed to determine this answer 30 More realism based on actual large scale complex projects 31 providing a 6 level standard 32 A position on WBS as either a life cycle of the project OR a product/deliverable

oriented breakdown of a project 33 Reporting and Resources 34 The Project Team builds and agrees on WBS and estimates before the Plan is

finalized or brought to management for time & $$. And as life changes, sometimes WBS needs to change so the WBS and the Plan most be evolutionary to the rimes. The Team must agree and be part of the evolution.

35 Examples are great! 36 I believe the use of the WBS for things other than scope planning and definition is not

good. 37 Create and develop more levels of SOW and Work Package 38 More examples 39 More WBS templates in Telecommunication, On-shore/offshore oil & gas projects,

Process/System Development Projects 40 Make sure it is simple and not full of jargon that a world-wide audience from various

industries will not necessarily interpret the same way. It is really useful. It just needs to be sold as such.

41 Benchmarking for different industries and different types of projects. 42 I was unaware that PMI had published a separate practice standard for WBS. My

WBS usage has been based on the PMBOK and various PM publications, other than PMI.

43 implement robots

26

44 more specific examples by industry or functional area include more about estimating 45 Developing a structure to plan and sequence more effectively. The use of network

diagrams, etc. not realistic. Maybe product specific list of minimum set of deliverables with sequence. i.e. business application software, web product, pharmaceutical, building. Also, by sub discipline Requirements, Design, construction, testing, deployment.

46 THE WBS IS A BASIC TOOL FOR PLANNING AND CONTROL 47 Should include more examples related to IT development projects 48 I would like to see the standard include the SDLC and PM frameworks interwoven and

identified as such. 49 Providing many examples of "real world" WBS in varied industries. 50 Include the EVM practice to WBS practice. 51 the Hierarchy of terms Taxonomy of terms 52 Relate to scope change control 53 Stop trying to portray WBS as a process description tool. It needs to be shown as the

ultimate scoping tool which describes the work of the project and is almost always unique to a given project. The skill in WBS formulation is in the prediction at a detail level of the work required to achieve a prescribed result. Efficiency and effectiveness in work and job design are key knowledge elements

54 Again, how do the PM processes work in the background to get the scope done? 55 Identify lowest level of the WBS as Activities. 56 re-write it using someone who actually gets good mileage out of scope definition from

product breakdown to organization/ cost/ risk/ phase/ breakdowns and is competent to actually describe how they do it

57 Make it clear that the verbiage should be for Deliverables and the WBS should have a dictionary.

Background Information

19. In which country/state do you currently Reside (Country/State): Africa

Camaroon Argentina Australia (2)

Victoria (2) South Australia

Belgium Brazil (3)

Parana Minas Gerais Sao Paulo (2)

Canada (4) Ontario (7) British Columbia New Brunswick Quebec

Eastern Europe Latvian Republic

England Egypt France (4) Germany (2)

27

India (7) Bangalore (2) Gujarat (2) Maharastra (4) Mumbai (2) New Delhi Tamil Nadu (3)

Indonesia Jakarta

Italy Japan Kuwait (2) Mexico (2)

Mexico City (2) Monterrey

Nuevo Len Nepal Netherlands New Mexico

Albuquerque New Zealand (3)

Wellington Nigeria Pakistan

Islamabad Puerto Rico Saint Lucia San Jose

Costa Rica Scotland Singapore (2) Spain (1)

Barcelona United Arab Emirates (1)

Sharjah United Kingdom (5)

Hampshire Leicestershire

USA (3) Alabama (2) Arizona (3) Arkansas California (12) Colorado (3) Connecticut (3) Florida (4) Georgia (4) Idaho (2) Illinois (6) Iowa Kansas Kentucky (2) Maryland (2) Massachusetts (5) Michigan (9) Minnesota (4)

28

Nebraska (2) New Hampshire (3) New Jersey (6) Nevada (2) New York (5) North Carolina (2) Ohio (3) Oklahoma Oregon (2) Pennsylvania (6) South Carolina (2) Tennessee Texas (11) Utah Virginia (8) Washington Wisconsin (2)

**US-II Venezuela (1)

Anzoategui 20. What is the primary industry focus of the company you work for?

Number of Responses

Response Ratio

I am currently unemployed or retired 2 1% Aerospace 11 5% Business services (advertising, marketing, staffing, etc.) 3 1% Construction 12 5% Consulting 48 20% Engineering 22 9% Financial Services 24 10% Food and Beverage 1 0% Government 21 9% Healthcare 12 5% Information Technology 75 32% Insurance 9 4% Legal 0 0% Manufacturing 12 5% Pharmaceuticals 6 3% Real Estate 2 1% Resources (Agriculture, Mining, Coal, Gas, Oil) 2 1% Telecommunications 15 6% Training/education 12 5% Transportation 8 3% Utility 4 2% Other (Please specify):

Biotechnology Project Management PMI Chapter International Development I am a Project Director and work in all industries Retail PMI Chapter Defense Contractor Manufacturer of Printing and Packaging Supply Chains & 3rd party logistics Internet Services Rail Signaling

25 11%

29

Publishing Retail/Wholesale Energy Defense Marketing Non-Profit Political Think-tank Power Researching Utility Media Advertising ERP Development Home Entertainment Media Provider Oil & Gas Exploration Education

21. Please select the title/position that best describes your role within your company:

Number of Responses

Response Ratio

CEO/President 12 5% CIO/Chief Technology Officer 3 1% Vice-President 4 2% Director, Project/Program Management 19 8% Director of Project Management Office (PMO) 14 6% Portfolio Manager 4 2% Program Manager 36 15% Senior Project Manager 51 22% Project Manager 51 22% Project Team Leader 26 11% Project Management Consultant/Advisor 25 11% Professor/ Educator 4 2% Researcher 5 2% Trainer 5 2% Other, Please specify:

Programmer Sr. Business Analyst IT Manager Marketing Manager Principle Cost Schedule Manager PMI Manager Business Analyst Program Planning & Controls Specialist Manager, Project Management Office Project Control Analyst/EVMS Project Admin Project Controls Manager Engineering Planner Planner Business Financial Manager Admissions Director, MBA Program Sales

18 8%

22. Are you a PMP? Number of Responses

Response Ratio

Yes 152 66% No 80 34%

Total 232 100%

30

23. How many years in total have you worked in project management? Please round up to the nearest year.

Number of Responses

Response Ratio

3 years or less 17 7% 4-5 years 37 16% 6-10 years 80 34% 11-15 years 50 21% 16-20 years 27 11% 21 years or more 26 11% 24. Does your organization have a Project Management Office (PMO)?

Number of Responses

Response Ratio

Yes 123

52%

No 112 48% Total 235 100%

25. Annual revenue of your organization: Number of Responses

Response Ratio

Less $50 million (US) 75 33% $50 to $250 million (US) 42 18% $250 million to $1 billion (US) 36 16% $1 billion + (US) 75 33%

Total 228 100%

31

The Work Breakdown Structure: A Brief SynopsisThe History of the Work Breakdown StructureWork Breakdown Structures Present UseWork Breakdown Structure Usage TrendsConflicting and Confusing Messages for the Project ManagerFinding Answers Evaluating Alternatives for WBS CreationProcess-oriented WBS construction does not articulate project outcomesAction-oriented WBS construction does not provide clear direction for delivering project deliverablesDeliverable-oriented WBS construction focuses on project outcomes

Benefit to the Project or ProgramBenefit to Stakeholders100% RuleRelated Tools and Documents for building the WBSContracts, Statement of Work (SOW) or Statement of Objectives (SOO)Project Scope StatementProject CharterWBS DictionaryOrganizational Breakdown Structure (OBS)Resource Breakdown Structure (RBS)Responsibility Assignment Matrix (RAM)SUMMARYLOOKING AHEAD:

BibliographyCurrent WBS Standard as a ToolPMI's Practice Standard for Work Breakdown StructuresBackground Information