Abstract
This paper provides a practical and reliable method for developing and maintaining a work breakdown structure (WBS) and ensures consistency with the contract or statement of work on which the project is based, throughout the lifetime of the project.
This technique links all of the scope elements of the project together to ensure traceability, constructability and manageability throughout all phases of the project's life cycle. It goes beyond the basic information provided in the usual guides on how to build work breakdown structures and provides a valuable addition to those guides.
The concept of product, project, and total scope are explained in relation to contracts and projects, and the steps from contract to Contract Analysis Table, and then to Action-Product Table (APT) are explained based on a genuine, commercial example. The paper then describes the way in which the APT is used to generate a WBS and shows how it supports each stage of a client engagement management life cycle, including feasibility analysis, requirements, time, cost, risk, and change management.
The concepts and approach provide a well-proven, practical, and straightforward way of developing and maintaining the key artefact required by all projects—the WBS.
Introduction
The approach described in this paper has been used successfully in a large number of multi-million euro projects by one of the authors (Werner Reiser), but it has not been formally documented in connection with the Project Management Institute's concepts of contract and scope management. This paper aims to remedy this lack. The structure of the paper, in the form of a table of contents, is provided in the appendix.
The approach presented in this paper is just as applicable and worthwhile when applied to external, contract-based projects as it is to in-house projects – assuming that they are (as they should be) clearly defined with the equivalent of a formal agreement between the internal client and the delivery organization, to take the place of a commercial contract.
As pointed out by Tim Esque (2013), much of the project management community focusses its attention on the definition, planning, and management of the requisite activities. This is certainly part of the role of a project but, in fact, only a subsidiary role. One explanation is that your employer pays you for what you do (time spent on various activities) but your client pays you for what you deliver (value of the outcome of the activities). The goal of this paper is to ensure the effective and verifiable link between these two features of projects: “work to do” or “work to make.”
Whereas most project practitioners talk about “scope management”, there are a number of different complementary definitions of “scope”. For example, it can be (Project Management Institute, 2008, 2012):
- Scope: The sum of products, services, and results to be provided as a project.
- Project Scope: The work that must be performed to deliver a product, service, or result with the specified features and functions.
- Product Scope: The features and functions that characterize a product, service, or result.
These definitions serve to support the definition of the key scope management tool, the work breakdown structure:
- Work breakdown structure (WBS): 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. It organizes and defines the total scope of the project.
- Note the only change in A Guide to the Project Management Body of Knowledge (PMBOK® Guide)—Fifth Edition (Project Management Institute, 2012) is that that the qualifier “deliverable-oriented” has been dropped in line with the change to the PMI Lexicon of Project Management Terms (Project Management Institute, 2010). This paper also allows for different hierarchical organizations in addition to the deliverable orientation.
A definition of “total scope” referred to in the definition of the WBS is needed, and is a valuable concept when used to consolidate the scope (the full set of projectized deliverables), the project scope (the work to be accomplished) and the product scope (what the deliverables look like and their verifiable characteristics). Once that concept is understood, it immediately raises the question of how to “organize and define” the total scope of a project.
But even the total scope is only a proxy for what clients really want: a solution to their requirements, not just a set of deliverables that complies with a set of specifications. For this reason, there is a need for complete, consistent, bidirectional traceability between the client needs, as expressed in the contract, through the set of deliverables and actions – some of which may also appear in the contract – to the definition of a complete set of actions, of verification tests and of validation processes.
This paper provides a practical and powerful answer to this question and links the very start of the project in terms of the initial contract or statement of work to the planning of the work (the requirements engineering and the work breakdown structure) and right up to the subsequent verification of the work performed and the validation of the project deliverables. The paper provides examples from an actual project at the international consulting and construction company, Pöyry.
The concept will be built up in the following section by first defining a two-dimensional contract breakdown structure (the Contract Analysis Table [CAT]) and then expanding it into a tool (an Action-Product Table [APT]) that can be used for creating the WBS as well as for defining, organizing, and controlling the total scope of the project.
From Contract to Total Scope
It should be noted that this approach can also be used for internal projects which, normally, are not linked directly to a formal contract, if they are effectively defined by, for example, of a formal statement of work. In fact, another benefit of this approach is that, in the case where there is no such definition document, and the project description is not clear enough to the entire project team to create the Contract Analysis Table (CAT) as defined in the following from existing documentation, the CAT structure can be used “from scratch” as a basis for requirements gathering before formally defining the project success criteria.
Contracts Define Both “What to Deliver” and “What To Do”
Although, in the ideal world, customers define only what they want to receive, its verifiable characteristics and the constraints, terms, and conditions under which the delivery should take place, in reality, customers will also define a number of activities they insist the contractor must also accomplish. This ambivalence between deliverables and actions needs to be dealt with carefully since only some of these actions will be relevant to some of the contractual deliverables – and some may even be technically unadvisable.
To separate these two contractual categories of stipulations, while maintaining the link between them, the approach proposed is to create a two-dimensional “contract analysis table” with the deliverables (the product scope) as rows and the actions (project scope) as columns.
Exhibit 1 provides an example of this approach. As shown in that exhibit, a consistent numbering system is used in which the products always start with a number and the actions start with a letter. For example, 2.* defines the overall project architecture with plant (2.1), buildings (2.2), etc., and 3.* defines the systems; for the actions, A = Project Management activities, B = Engineering activities, etc. The exhibit shows both the category of component in the table as well as its position in the breakdown hierarchy.
Exhibit 1 – Example of a Contract Analysis Table
Separating the product from the actions in this way also allows each of these sets to be structured hierarchically where relevant; for example, where the contract describes an overall deliverable – part of the product scope – (e.g., an overall power plant structure), this can then be broken down into its principal components (e.g., buildings, services, connections) and, possibly, specific details by component (e.g., plant building, storage facilities, etc.). In a similar way, if the contract specifies the activities – the work scope – of heating, ventilation, and air conditioning design, this may then be further decomposed into “design the heating system” and “design the chilled water system.”
Whether or not the contract specifies certain actions, the project manager and other experts will need to define their specific activities and add them to the action list.
Adding the Project “How to Do's”
There are two principal categories of project activities:
- Those required to ensure efficient and successful project management; and
- Those required by the technical experts or discipline managers to carry out their work in accordance with the best practices of their respective areas, such as business analysis, construction management, etc.
All of the actions from both of these categories can be added as columns to what started out as the Contract Analysis Table and should now be considered more generally as an Action-Product Table (APT). The corresponding table provides all of the information required to create the full work breakdown structure for the project. This is shown conceptually in Exhibit 2, and a version developed from the CAT in Exhibit 1 with the addition of some project management activities is shown in Exhibit 3.
The next step, naturally, is to fill in each of the cells in the APT according to whether or not the corresponding Action-Product pair is part of the project scope. The set of all in-scope cells defines the set of components of the WBS, as will be explained.
Exhibit 2 – The model for an Action-Product Table
Exhibit 3 – An Action-Product Table
From APT to WBS
According to the Practice Standard for Work Breakdown Structures, the “way that the project manager decomposes the project (i.e., the logic used for decomposing the work) can vary depending on the needs and requirements of the performing organization and the use to which the WBS will be put” (Project Management Institute, 2006).
Once the APT has been developed, these are some of the ways in which the WBS can be structured:
- Based on the product architecture (i.e., starting with the rows of the APT)
a. This is the basis of a “product-oriented” work breakdown structure.
b. The actions to be carried out will normally appear only as the lowest levels of the WBS once the level of detail of the product breakdown is sufficient.
- Based on the structured action list (starting with the APT columns), using the project scope as the highest level in the WBS.
a. The product elements affected by each action will then be subcomponents of the corresponding actions.
- Based on the project life cycle
a. This entails restructuring the set of columns of the APT (i.e., the actions) with respect to the chosen life cycle and then using option 2.
Each of these approaches for creating a WBS has its advantages and disadvantages, and people can be found to defend each of them. However, the advantage of the APT is that it removes the need of limiting yourself or the team to a single way of structuring the total scope of the project.
Even if the APT only went as far as linking the contract (or statement of work) to the WBS, it would already be a major contribution to ensuring effective project delivery; however, it supports much more than that:
- Life cycle management,
- Stakeholder management,
- Interface management,
- Time management,
- Budget control,
- Requirements management and traceability,
- Change management,
- Risk management, and
- Product, project, and contract closure.
Due to space constraints, only life cycle management is analysed in detail, although the other considerations are briefly explained.
Life Cycle Management
The Client Engagement Life Cycle
As stated in the introduction, there is a need for complete, consistent, bidirectional traceability between the client needs, as expressed in the contract, through the set of deliverables and actions – some of which may also appear in the contract – to the definition of a complete set of actions, of verification tests and of validation procedures. This implies a direct link to the beginning-to-end life cycle of the client engagement. This point of view and a similar approach are presented by Bachy and Hameri (1995) who stated that “the importance of the actions to be taken before the project planning phases begin. The approach taken stems from the production planning paradigm, with emphasis on the product, rather than on the process”.
The explanation of what this implies in our approach is based on the client engagement life cycle and shown Exhibit 4, below.
Exhibit 4 – A typical client engagement life cycle
The technique is to work through the life cycle and build up the whole APT structure progressively, as follows:
In the Project Development Phase
The start of Conception Design is triggered by a request – such as a Request for Proposal (RFP) – from a potential client.
a. The deliverables, capabilities, constraints, and any specific actions should immediately be used to form the initial components of the preliminary Contract Analysis Table (Exhibit 2).
b. The Feasibility Study can then be run, if necessary, as a project in its own right, aimed at validating financial and technical ideas and assumptions
i. In order to create the corresponding APT (Exhibit 3), the ideas and assumptions will be added to the Product Considerations and Contractual Requirements (Product Scope) rows, while the options and actions to be carried out belong in the Actions and Knowledge (Project Scope) columns.
ii. The criteria for assessing the feasibility are linked directly to the cumulative outcomes of the rows, whereas the WBS is defined by the cells of the APT corresponding to contractual or expert activities.
iii. The final results of the feasibility study can then be used in the next stage.
c. The Basic Design retains the details about the Product Considerations, the Constructability and Contractual Requirements that have been assessed in the previous stage and considered feasible, as well as the relevant activities that these imply. This information provides a factual basis for developing a credible budget and schedule on which to base the Final Tender Design.
d. All that remains in this stage is to present the proposed solution in a form that is most appropriate from the point of view of the client and the delivery organization.
If the tender is accepted, the delivery project itself can be launched and the Project Execution Phase initiated.
In the Project Execution Phase
Work on the “Detailed Design” can start directly from the APT as developed in the previous phase, plus or minus the changes that arose while negotiating the tender.
These design considerations and details will add and modify rows corresponding to relevant Product Considerations. The life cycle of the Delivery Project is aligned with the relevant stages of the Client Engagement Life Cycle as shown in Exhibit 5 and is explained in more detail further on in this document.
Exhibit 5 –The client engagement and delivery project life cycles
a. Project Initiation: The Delivery Project is initiated once the business is confirmed – that is to say once the “Final Tender design approved” (CMS 100) milestone is achieved, and the contract signed by the client.
b. Project Planning: In the Delivery Project, this phase is followed by the Planning phase, which is a companion to the Detailed Design phase of the customer solution. Once the corresponding plan has been accepted, the Execution phase can be started.
c. Project Implementation: the project Implementation phase comprises three stages: Construction, Commissioning-Training, and Testing.
d. Project Closing: the project Closing phase comprises the Project “Acceptance” milestone (CMS 600) with Project closeout and handover to the client
The Delivery Project Life Cycle
As mentioned previously, this project is an integral component of the client engagement. It starts once the tender has been accepted. Ideally, work on the project would only start once the corresponding contract has been signed. However, in real life, time pressure often requires the delivery project to get under way with a minimum of delay. The Initiation Phase therefore normally starts immediately in order to launch the development project. This is then followed by the phase of developing the technical and project plans, leading to execution and, finally, closure. Each phase is shown in Exhibit 6.
Exhibit 6 – The delivery project life cycle
Initiate Development Project
The project artefact from this phase is the project charter; this defines clearly the level of authority and responsibility of the project manager. This should be compatible with the Contractual Requirements of the Product Scope from the APT as depicted in Exhibit 2. The development of this charter document entails developing a specific and measurable description of the project objectives, as well as the top-level risks and corresponding responses that can be identified at this stage. This information enhances the clarity of the product scope information in the APT and reduces the risk of later misunderstandings – and the resulting claims.
Since, as mentioned previously, this phase frequently starts before all of the contractual stipulations have been finalized, the charter and corresponding APT information must be considered as changeable until the final signature; additional actions to deal with this uncertainty may therefore need to be included in the APT on a conditional or definitive basis. This introduces another important concept into the APT. It will be explained in more detail in the section on risk management. These are the two types of actions that can be found in the APT:
- Definite—actions that must be carried out in relation to the corresponding product components; and
- Contingent—actions that are planned but will only be carried out if a certain event or condition occurs.
Develop technical and project plans
All of the planning is coordinated around the work breakdown structure (WBS). Once the WBS is available, stakeholder, requirements, budget, and risk management can be developed and integrated into the overall project management plan.
The WBS
The Planning Phase is typically the phase in which the conventional WBS comes into its own: the work packages are analysed and broken down as necessary into activities or into formal specifications for external acquisition of the corresponding package to be put out for tender – which will then happen in the following phase (Program execution phase 1, procurement and logistics – Exhibit 6).
These work packages correspond to the non-empty cells of the APT. Ideally, the corresponding WBS should be created automatically in hierarchical form directly from the APT. As explained previously (from APT to WBS), the hierarchical structure can be based either on a deliverables-to-project (DtP) structure in which the WBS is read off based on the rows of the APT, or, conversely, on a project-to-deliverables (PtD) basis in which the row-headings drive the structure: from the example in Exhibit 3, these two approaches would give the following.
For DtP:
| 1.3.0 | External advertisement |
| 2.1.1 | Project wide electrical engineering and, for example, all of the product elements corresponding to non-empty cells in the “Project wide Electrical Engineering” row of the APT |
| 2.2.0 | Buildings |
For PtD:
| A.0 | Project Management |
| B.0 | Engineering Management ... and, for example, all of the project elements would be included that need to be worked on to in engineering, corresponding to non-zero cells in the “engineering management” column of the APT |
| C.0 | Procurement Management |
Stakeholder management
If you list the stakeholders for each of the product scope components and link these to their (project) action owners, you will get a full set of key stakeholders for the corresponding action: the product scope stakeholders will normally have C and/or I (consulted /informed) in the corresponding RACI chart (Project Management Institute, 2012, p. 262, 9.1.2.1), whereas the (project) action owners are the A (action) or the R (responsible). This defines the clear responsibility and interfaces between the parties for the entire project
Requirements management and traceability
The link between actions and contractual obligations can be read directly from the APT. See Exhibit 7 relative to testing and validation.
Budget and cost breakdown structure
Each of the scope actions can be tagged with its cost breakdown structure or category, thereby allowing a roll-up of the cost breakdown per product deliverable as well as for each project deliverable or any other chosen category. The common numbering system is the base information to secure the link between the cost breakdown structure (CBS) and the requirements defined in the contract.
Project risk and change management
Whereas the standard WBS provides, at best, a basis for identifying and analysing individual risks, the APT allows any risk to be traced through its potential effect on contractual elements and on other WBS elements using a similar approach to that outlined in the following for change management. This gives a much better idea of the overall impact that one or more event or condition could have – for better or worse – on the project.
Developing the plans
Once the WBS is available, the planning should follow the standard process defined in all standards of project management and design. During this planning work, some changes to the original WBS are normally found to be necessary. These should be mapped back onto the APT, taking care to ensure that any changes corresponding to contractual items are verified before being agreed; this is easily done by identifying the row or rows affected by the changes for product deliverables, as well as the affected columns so as to check against contractually mandated (or prohibited) activities.
In a similar way, changes to the project must be managed in a controlled manner as described in the following.
Project change management
Godinot (2003) and Lemoine (2012) described how change and interface management are key to maintaining the viability and alignment of a project, which is summarized in the following.
All of the effects of any proposed change can be evaluated from the APT as follows:
i. If the change is to the product scope, look along the corresponding row to see each of the affected actions (project scope). For each of these actions, carry out the next step.
ii. If the change is to the project scope, look down the column to find each of the affected contractual elements (product scope). For each of these changes, go back to step i. and loop around until the set of affected actions and contractual elements is complete.
iii. Analyse the impact (e.g., cost-benefit) of the full chain of effects that has just been identified.
At the technical level, the verification and validation plans for the products and their sub-components must be created. The structure of the APT rows can be used as a basis for a hierarchical approach to testing (e.g., V-model in (KBSt) (Exhibit 7).
Once the plans are complete, the corresponding project management plan can be signed-off and a start made on the execution phase.
Project execution
Except for changes to the plans, such as change requests and risk reassessment, the project management plan is the basis for execution in line with the Delivery Project life cycle (Exhibit 6), with no need to refer back to the APT.
Project execution stage 1: procurement and logistics
Each of the work packages identified in the WBS during the planning stage that will be carried out by external organizations or suppliers needs to be the subject of a formal contract procurement action.
Project execution stage 2: construction
This stage is basically under the control of the subject matter experts for the deliverables – either internal engineering groups or, for example, partners or suppliers. The main role of the project manager during this stage is to track progress against the plans and take appropriate action if any is required.
Project execution stages 3 and 4: commissioning and testing
These are the last stages of the execution phase and must be carried out by parties independent of the developers, in order to maintain objectivity. All of the WBS can be used to support this stage.
Exhibit 7 – The V-model approach to testing
Monitoring progress
Tracking can be carried out by using the detailed WBS and the conventional earned value approach, or on a product-based approach by grouping the work packages according to the product (i.e., the row of the APT) to which they contribute.
Exiting the execution phase
Once all of the activities are complete, including all of the verification and validation as shown in Exhibit 7, the execution phase can be closed – with executive-level approval. The project then needs to be closed.
Handover and project closure
This phase needs to be defined and planned early and incorporated in the implementation plan. It covers two sets of activities:
1. Verification: This entails ensuring that the full set of activities has been carried out and tested.
- The set of actions in any row defines the set of unit tests required at that level of the product breakdown structure.
2. Validation: this entails ensuring that what is delivered is contractually compliant and “fit for purpose.”
- A set of validation procedures must be defined for each of the product scope elements as defined in the contract: a dedicated validation category (column or multi-column hierarchical structure) must be included in the APT.
- The validation list provides the basis for a contract checklist throughout the lifetime of the project, as well as the final contractual acceptance.
Once these activities are complete, transfer of ownership and administrative closeout can be carried out to close the project.
Conclusion
This paper describes a reliable and practical way of structuring the total scope information in such a way that it can be presented to the various stakeholders in an easily understandable form. Meanwhile, it maintains full generality for creating all of the artefacts required for best practice project management through all phases of the project, and managing risk and change in a controlled and fully consistent manner. This approach has proved its value, having been applied successfully to large and complex construction projects in challenging environments.
