Quality in the design-procure-construct industry, OR quality > six sigma
As a project manager you have heard a lot about quality. At the forefront of the quality discussion is the concept of “Six Sigma.” You can be a “Six Sigma Blackbelt,” subscribe to “Six Sigma Forum Magazine,” go to the annual “Six Sigma Conference.” You can buy books full of charts and graphs promising that EVEN YOU can achieve Six Sigma quality.
However, Six Sigma is a statistical tool and, according to basic statistics, it takes a minimum sample size of 22 to obtain a statistically significant measure of variability. Thus, using Six Sigma to measure the quality of your Design-Procure-Construct (DPC) projects requires a minimum of 22 projects. Assuming five years to complete a project, it will take 110 years to gather enough data to calculate compliance with Six Sigma. At least by then your 401K ought to be in pretty good shape!
So, if Six Sigma isn't the answer in the DPC industry, what is? This paper will answer that question. Examples from projects within the Corporate Construction Program at Sandia National Laboratories (Sandia) in Albuquerque, New Mexico, will be utilized to illustrate concepts and processes.
Why Quality > Six Sigma
“Six Sigma,” as it is used in statistical measurements, refers to the capability of a process to produce items within specification. To achieve Six Sigma quality, a process can produce no more than 3.4 defective widgets per million. Not bad, as they say, for government work! Thus Six Sigma, as a statistical tool, applies very nicely when you are producing thousands or millions of identical widgets. However, this is not what DPC is about. Rarely does a project manager in DPC produce more than one of a kind of anything.
Now, before we throw the Six Sigma baby out with the bath water, let's allow for a broader definition of the term. The quality movement had its roots in manufacturing, and statistical process control the way. Over time, “Six Sigma” became a catchall phrase to represent the broader application of quality concepts in all industries. I prefer to move away from the use of Six Sigma to represent quality in DPC. It's misleading when you only get one shot at doing something right. Thus, for DPC, quality is greater than Six Sigma.
I have two prerequisites to this discussion of quality:
1. The context: My job is a world of planning, designing, and constructing facilities projects at Sandia National Laboratories. Sandia is a $1.75B/yr Department of Energy funded R&D laboratory focusing on national security. My projects at Sandia include office buildings, laboratories, control centers, processing facilities, communications systems, infrastructure, etc. The concepts in this paper can be applied to any DPC context but will need to be tailored appropriately.
2. This discussion is for the working project manager, not high-level program managers or executives. That is to say, the decision as to whether a project is the right thing to do (whether it aligns with the organization's strategic objectives, whether it is cost effective, etc.) has already been made. The project manager's job is to implement, and to implement well.
If You Know Two Things About Quality, You Know All There Is to Know
What kind of a statement is that? Two things? It can't be that easy! Ah…but it is. If you know the following two things about quality, you know all there is to know.
1. Quality is customer satisfaction.
2. Quality is process efficiency.
George Eckes, a primary consultant to General Electric for quality initiatives, calls these two concepts effectiveness and efficiency. Eckes defines effectiveness as “…the degree to which an organization meets and preferably exceeds a customer's needs and requirements.” He states that efficiency refers to “…the resources consumed in attempting to become effective” (Eckes, 2001, p. 15).
The Customer-Supplier Value Chain
All businesses exist because of customers. It doesn't matter whether your business is for-profit, non-profit, government, product, or service…businesses serve customers. What is a customer?
The Project Management Institute defines a customer as “the individual or organization who will use the project product” (PMI, 1996, p. 15). Eckes defines the customer as the “…recipient of the product or service” (Eckes, 2001, p. 50). There are two categories of customers:
1. External—The end user of the product/service, often the one who pays the bills.
2. Internal—Any entity in the organization that receives an intermediate product/service in the process of delivering the end product/service to the external customer.
Exhibit 1 illustrates what is commonly known as the Customer-Supplier Value Chain. All projects are a series of steps through the value chain. At each step, workers/team members are both suppliers to and customers of each other. The goal of the chain is to integrate customer satisfaction into each step of the process. End-user (external customer) satisfaction will be a result of achieving internal customer satisfaction in each step of the value chain.
In DPC, customer satisfaction is achieved through:
- Requirements management.
- Conformance to requirements.
According to Webster's Dictionary, a requirement is “something essential to the existence or occurrence of something else.” Requirements precede and drive solutions. If requirements are not correct, the solution will not be correct. Phillip Crosby says, “Requirements are the details of the business that result in customers receiving what they have been led to expect” (Crosby, 1996, p. 24). Requirements management occurs in three steps: Requirements planning, requirements implementation, and change management.
Requirements planning refers to the identification and documentation of all the requirements that drive a project. Exhibit 2 illustrates what I call the Pyramid of Requirements. At the top of the pyramid are the end-user (external customer) requirements including cost, schedule, and scope. In DPC the end user describes the scope in terms of what the facility will do (functional capabilities)—i.e., provide office space, store materials, support operations, refine crude oil into products, etc. These functional capabilities are definable and measurable. The end user will likely also have requirements for aesthetics. Though more difficult, aesthetics can also be defined and measured.
Below the end-user requirements in the pyramid are additional requirements driven by other project stakeholders. The Project Management Institute defines stakeholders as individuals and organizations who are actively involved in the project, or whose interests may be positively or negatively affected as a result of project execution or successful project completion (PMI, 1996, p. 15). Note that by this definition end-user customers are also stakeholders.
For requirements to be valid and manageable they must:
• Be owned
• Add value (or prevent loss)
• Be able to survive challenge
• Be identified (up to date, documented, communicated)
• Be achievable.
These characteristics are the requirements for requirements.
Requirements owners are responsible for defining and managing requirements and reviewing the project for conformance to requirements. Owners must be subject matter experts (SMEs) or have SME support. An owner may be an end-user customer or other stakeholder, or can be a delegate of either. There can be multiple owners for a given requirement but they must speak with one voice.
Requirements add value when they are consistent with external customer requirements. A reflection of added value is that the customer is willing to pay for the requirement. Preventing loss is equally important as adding value. Contracts and specifications are full of requirements designed to prevent financial loss or inferior construction. Regulatory requirements add value by protecting workers, the public, the environment, etc.
Project teams should routinely challenge requirements. Invalid requirements waste resources. If planning requirements are wrong, a project team may do a great job of building the wrong thing. Requirements have a way of taking on a life of their own, of being self-perpetuating even when no longer valid. It has often surprised me how a simple challenge can cause a very expensive requirement to tumble.
The need for requirements to be identified and achievable speaks for itself. The caution here is that many requirements are often implied or expected, without being stated. It is up to the project team and SMEs to flush out and document all requirements.
Requirements are implemented via the workflow shown in Exhibit 3. The workflow is a customer-supplier value chain. As illustrated, requirements expand from high-level planning statements to detailed designs. The workflow follows an iterative process where requirements drive solutions, which become the requirements for the next step.
For major projects at Sandia, the first set of requirements in the workflow is captured in a Conceptual Design Plan (CDP). This is a brief report, 20–50 pages long. The report documents the project requirements (the business problem to be solved) and proposes a high-level description of the solution (project) needed to meet the requirements.
As reflected by the influence curve in Exhibit 3, the CDP is the most critical statement of requirements in the project. Further requirements flow from this document. Project quality (customer satisfaction) depends more on the accuracy, validity, and interpretation of these requirements than on any other documents in the process. The importance of concurrence in these requirements among project stakeholders at this stage cannot be overemphasized.
The next step in the process at Sandia is the development of a Conceptual Design Report (CDR). The final product of this phase is a proposed project with a well-defined scope, cost, and schedule. As the project proceeds forward, the CDR “solution” becomes the requirements for the design phase. The workflow process repeats itself for the design and construction phases.
Within each of the phases of the workflow there might be several iterations of the requirements-solutions-requirements process. At Sandia the design phase typically includes programming, schematic design, design development, and construction documents, each as a separate iteration of the process.
Note in Exhibit 3 the relative importance of other stakeholder (non-user) requirements through the workflow. Many stakeholder requirements are common to all projects, well documented, and fairly static. As such they do not drive initial planning solutions. There are exceptions to this, an example being nuclear facilities. In general, the influence of other stakeholder requirements is smaller initially and grows through the workflow.
Your workflow process may have different deliverables, different steps, and more or fewer iterations. The fundamental process of requirements-solutions-requirements is the same. The key to quality in implementation is assuring that the requirements for requirements are maintained at each step.
Requirements Change Management
DPC projects take time. At Sandia a large project can take 5–10 years to go from planning to completion. Requirements change over time. Technology changes, laws change, markets change, management changes, the world changes. The only constant in life and business is change. In order to satisfy the customer, you must manage change.
As with requirements, changes must have an owner, must add value, must stand up to challenge, etc. The requirements owner is often the initiator of changes (example: technology change). When not the initiator, the owner must be consulted in managing the change. A requirement for a budget or schedule change will likely require input from multiple requirements owners.
Referring to Exhibit 3, the cost of change follows the A curve. While change is almost always painful, it is the least painful in the early phases of a project. I have seen CDRs, even entire designs, scrapped because of requirements changes. While time and money were lost, much less was lost compared to the cost of continuing through the process with wrong requirements.
Change processes should be as formal or informal as necessary. At Sandia, change control occurs at several levels based on a project plan. At the highest level the U.S. Congress must approve the change. A Change Control Management Team manages changes at the lower levels. Thresholds that determine who can authorize a change are identified in the project plan. Changes at all levels are documented.
Conformance to Requirements
According to Crosby, quality is conformance to requirements. In Crosby's words, “Once the planners and designers have designed what delights the customer, they need to insist that everyone else conform to the requirements so the customer gets what's promised” (Crosby, 1996, pp. 14, 24).
The necessity of conforming to requirements the first time sets the DPC industry apart from others. Though plans and designs can be redone, construction only happens once. We don't get to run a test batch. We can't inspect the product and throw away defective units. If the end product is defective, it's already too late to adjust the processes.
In DPC conformance to requirements requires three actions:
1. Communication. Exhibit 3 shows two-way communication between requirements owners and solution providers. Communication starts with conveying all planning documents and other stakeholder requirements to the solution providers. Communication must then continue between owners and providers for clarification, collaboration, and feedback.
2. Implementation by solution providers. Solution providers must have the training and tools to be able to understand requirements and develop solutions that comply.
3. Assurance of conformance (inspection). The arrow pointing left in Exhibit 3 represents this step. Requirements owners review solutions for compliance. These reviews are implemented via planning reviews, design reviews, field inspection, submittal review, etc. The result of inspection is correction of non-compliance.
As noted before, as work flows through the process, solutions become requirements. Thus, solution providers become requirements owners. As owners, the solution providers are now the inspectors of downstream activities and deliverables. This is similar to the customer supplier value chain, Exhibit 1, whereby roles change as work flows through the process.
It is accepted “quality doctrine” that prevention is cheaper than inspection and correction. Eckes states that “the act of inspection does not add to the quality of the product” (Eckes, 2001, p. 3). Yet, inspection is pretty much the norm in DPC. The issue is risk. At Sandia, near 100% inspection is the norm in most phases of work. Requirements at Sandia are often very unique from other organizations, and suppliers are not familiar with them. Thus, the risk of non-conformance is high. Sandia has nuclear reactors and other types of facilities where consequences of non-conformance can be disastrous. The risks of non-conformance are mitigated by inspection. A risk assessment should be performed on any DPC project, and the level of inspection should be commensurate with the risks.
So far I have discussed the first ingredient of quality, customer satisfaction. The second ingredient of quality is process efficiency. Process efficiency focuses on the internal operations of the organization providing the product or service. A process is a series of steps and activities that take inputs, add value, and produce an output. The DPC workflow (Exhibit 3) is a process with many sub-processes. Process efficiency refers to how well resources are used to produce an output. Based on informal surveys of seminar attendees, Eckes concluded that most business processes are only about 50% efficient (Eckes, 2001, p. 15). That's not very good!
Process efficiency is achieved by process design and improvement, and by doing things right the first time.
Process Design and Improvement
Project teams work with two types of processes: those they can influence and those they cannot. Processes that the team cannot influence include corporate enabling processes such as human resources, procurement, legal, finance, etc. Others that cannot be influenced may include those that support multiple projects and simply cannot exist in unique forms for each project. Hopefully these processes are subject to review by the corporate quality program.
For those processes that can be influenced, some are only exercised once for the project. Planning and design only happen once (ideally). Construction procurement and construction happen once. Thus, design of these one-time-through processes is critical. Process design is the responsibility of the project team in coordination with process workers and stakeholders. Process design must take place far enough in advance of implementation to make sure that everyone involved in the process is trained and equipped appropriately.
Process design must take into account unique aspects of the project (complexity, technology, funding, etc.) and different project priorities (cost vs. schedule vs. scope). To maximize process efficiency the project team should leverage lessons learned from other projects.
Other processes that the project team can influence will include those that are exercised repeatedly through the project. Examples include design reviews, estimate updates, invoice approval, reporting, etc. As with one-time-through processes, the design of these processes should be adjusted as needed for unique aspects and priorities of the project.
For processes that are exercised repeatedly through the project, the principles of process improvement (measure, analyze, improve, control) should be applied to reduce cycle time, delete steps that don't add value, streamline activities, reduce costs, etc. It is important that the project team assess which processes have the largest impact on the project and focus on those processes, as process improvement itself consumes resources.
Do It Right the First Time
Crosby defines the Price of Non-Conformance (PONC) as the cost of doing things wrong and having to correct them. Crosby estimates that service and administrative organizations waste 40% or more of costs on waste and rework (Crosby, 1996, p. 25).
Kerzner addresses the cost of quality as the cost of conformance plus the cost of non-conformance (Kerzner, 1998, p. 1058). As illustrated in Exhibit 4, the cost of conformance includes prevention and inspection. Prevention includes requirements management and conformance to requirements. It also includes training, quality planning, process design, etc. Inspection identifies non-conforming work. The cost of non-conformance includes waste and rework. In DPC this includes redoing planning and design documents, corrective construction actions, warranty callbacks, etc.
As noted earlier, inspection does not add to the quality of the product. Rather, it identifies non-conformance and prevents defective solutions and requirements from continuing on through the process. The cost of non-conformance follows the A curve in Exhibit 3. Inspection is more important in the early project phases than in later phases. Thus, “do it right the first time” can be supplemented with “do it right early.”
Doing it right the first time by investing in prevention results in a “return on quality.” This is shown in Exhibit 4. As illustrated, additional investment in prevention results in reduced reliance on inspection, reduced rework, and reduced waste. Doing it right the first time will also support customer satisfaction by enabling schedules to be met and minimizing the customer's frustration in being involved in rework.
Process efficiency is a necessity in a competitive environment. All organizations are competing for revenue or funding. Customers of both for-profit and non-profit organizations will always look for the best quality at the lowest cost. Inefficient organizations cannot compete and will go out of business.
The Tools of Quality
The tools of quality for DPC are found in A Guide to the Project Management Body of Knowledge (PMBOK® Guide). These tools are the nine knowledge areas of integration management, scope management, etc. The International Standards Organization (ISO) has published Standard 10006, Guidelines To Quality in Project Management. If you compare the ISO standard to the PMBOK® Guide you will see that the PMBOK® Guide addresses all the information presented in the ISO standard, and in significantly more detail. Thus, if you master the tools in the PMBOK® Guide and apply them to customer satisfaction and operational efficiency, you will achieve quality in your DPC project.
Quality in DPC is not a statistical measure. The one-time nature of DPC requires us to consider other measures of variation. Those measures are customer satisfaction and process efficiency. Customer satisfaction means requirements management and conformance to requirements.
Harold Kerzner wrote that quality assurance is the area where the project manager can have the greatest impact on the project (Kerzner, 1998, p. 1057). Crosby asserts that quality is the best single way to make a profit (Crosby, 1996, p. 19). The project manager and the project team must never view quality as an add-on, an extra something to do. They must view it as a means of achieving project (business) results. Remember the old adage: an ounce of prevention is worth a pound of cure. Quality is an investment in prevention with returns measured in customer satisfaction and reduced costs.
Crosby, Phillip. 1996. Quality is Still Free. New York: McGraw-Hill.
Eckes, George. 2001. The Six Sigma Revolution. New York: John Wiley & Sons Inc.
Kerzner, Harold. 1998. Project Management. A Systems Approach to Planning, Scheduling and Controlling. New York. John Wiley & Sons.
International Organization for Standardization (ISO). Guidelines to Quality in Project Management. 1st ed. ISO 10006:1997(E).
Project Management Institute (PMI) Standards Committee. 1996. A Guide to the Project Management Body of Knowledge (PMBOK® Guide). Upper Darby, PA: PMI.
Proceedings of the Project Management Institute Annual Seminars & Symposium
October 3–10, 2002 • San Antonio, Texas, USA