IIII =

5 =five
Poor up-front definition of customer needs
Since deficiencies in the needs definition process snowball as they roll further into the project, improving this process is a critical step toward more effective projects. The core of the needs definition process is the series of specifications that are developed by the customer and, possibly, by competing suppliers. If contractors were to complete an application for the Malcolm Baldrige National Quality Award, they would probably view their specification process as a plus. After all, arent specifications the result of working with the customer to define their requirements? Ideally, yes. In actuality, the specifications usually define only the technical aspects of the solution. They might not address quality requirements, customer satisfaction requirements, or cost considerations (such as development or life-cycle cost targets). So the specifications do describe customer requirements, but they are incomplete because they describe only one segment of the customer population: the technical evaluators. More important, because the specifications are developed up front rather than throughout the process, they are often inaccurate or incomplete in retrospect. Specifications might also be written with the intent to influence the customers requirements. Successful contractors try to minimize competitive bid pressure by working up front with customers to position themselves as the supplier of choice. This can result in specifications that dont indicate what the customers need but rather what the contractor wants to give them. For example, one of the stated sales strategies for at least three contractors is to write the specifications for the customer. They train salespeople to position this idea as a time- and work-saver for the customer and provide salespeople with boilerplate specifications that favor their own products. In theory, this could be harmless if the requirements were closely matched to customer needs. In practice, however, salespeople tend to use the boilerQuality Progress February 1996

Five Ways to Improve the Contracting Process

process to provide customized, largescale systems or products (e.g., information or telecommunication systems) have struggled to adapt the core quality principles to their businesses. While some have been successful, many have run into serious problems. The problems typically stem from trying to force-fit the use of quality tools. To improve the contracting process, companies need to focus on effectively achieving the mission of the contracting process rather than on figuring out ways in which to use the quality tools. The contracting process, which is similar to many product development processes, can be found in a number of industries, including computer systems, telecommunication systems, aircraft and ship building, and construction. Contracting is the process by which customized systems are designed and delivered. Often, the term solution is used to describe a combination of customized products and services that are sold together as a solution to meet customer needs. As Figure 1 shows, the contracting process is fairly generic. So, too, are its problems: The solution might not match the customers real needs, schedules might be missed, or there could be so many change orders that they become obsolete before they are approved. The process often fails to yield customer satisfaction, produces unpredictable profits for the contractor, creates stress for the customer, and ties up more resources for more time than desired. Out of a number of potential problems like these, there are five primary ones that a quality-based approach can help solve: Poor up-front definition of customer needs Incomplete evaluation criteria for awarding the contract (an overemphasis on price) Poor planning of the project activities Poor assimilation of necessary midstream project changes (driven by problems or improvements discovered during the project) Metrics and rewards driving the wrong performance

OMPANIES THAT USE A CONTRACTING

The relationship between contractor and customer doesnt have to be adversarial.

by Pete Hybert

65

F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I

Figure 1. A Generic Model of the Contracting Process

Award Acceptance

Needs definition

Solution definition

Solution design

Solution development, testing,

Solution support, service, and enhancement

Requirements specification

Request for proposals

Proposals

Functional specification

Design specifications

installation, and turnover

plate specifications to shortcut the needs definition process. Initially, everyone is happy because the process moves more quickly. But the customers eventually discover the mismatches between their needs and what is being developed and have to make expensive midproject changes. Specifications are typically not user-friendly documents; they do not communicate customer needs well, especially to those who were not involved in the process of developing them (such as new members on the project team or people who join the project downstream). Specifications are typically written in engineering- or legalese and rely on lengthy text with few diagrams, charts, or bullets to aid communication. Most important, sometimes the contents can be interpreted more than one way because the players involved in the project want it that way! Ambiguity prevents contractors from being held accountable for delivering solutions that dont quite solve customers problems. It also prevents customers from being held to an early view of a requirement that might evolve as the project progresses. Where interpretations vary, the players must adopt hardball negotiating tactics, which certainly does not promote customer satisfaction with the project, regardless of the outcome.

Recommendation No. 1: Use a quality function deployment approach

Customers and contractors have a common interest in clearly defining needs in the early stages of a project. A quality function deployment (QFD) approach for defining functionality, quality, and cost requirements can reduce time and errors in this part of the process. If the contractors goal is to deliver a system or product that meets long-term customer requirements, its mind-set has to shift from deliverables and technical specifications (i.e., What is the minimum I owe you?) to customer functionality (i.e., What work will the customer be doing, and how will this system or product improve the ease, cost, and quality of that work?). For this to happen, the contractor must incorporate the needs of all stakeholders in the customers organization. For example, suppose the customer is a chemical processing plant looking for a control system for a new process. The plants executives are concerned about return on investment, cash flow, and life-cycle costs. Its operations managers are interested in reliability, maintainability, and resources needed to support the
66
Quality Progress February 1996

system. The operators, or users, of the system are concerned with ease of learning, ease of use, and ease of access to reference information. (Too often, the users, including those who support and maintain the system, have the least input on its design.) Finally, technical experts are looking for system data for quality assurance tracking, the ability to adjust the system for varying situations, and so forth. There might even be regulatory needs as well. The needs of all these stakeholders must be met for the control system to improve the ease, cost, and quality of their work. This is where the QFD matrix (often referred to as the house of quality) and the group consensus process can help. A team consisting of key personnel from both the customer and contractor organizations should use a consensus approach to develop the customer requirements portion of the QFD matrix (i.e., collect, sort, and prioritize customer requirements). Many approaches for gathering information can be used (e.g., focus groups or individual interviews), as long as the primary goal is to understand what the customer needs and expectsand not to create a perfect QFD matrix. The value of the QFD approach is that the identified needs are clear, specific, and easily understood. They also truly reflect the customers requirements because generating the matrix takes dialogue, clarification, and more than a single iteration (the needs can be reviewed and revised by all of the stakeholders before awarding the contract). Although documenting customer needs with the QFD approach will increase the time from initial project concept to bidding, it will result in time and dollar savings downstream because changes and conflicts will be reduced. Figure 2 illustrates how other QFD elements can be integrated into the contracting process. Once the customer needs are defined, they can be translated into technical requirements and linked to elements of the solution, completing the QFD matrix. Upon award of the contract, the key result measures or solution elements can be deployed to various team members to ensure they are not later forgotten. Then, part of each team meeting can be spent focusing on progress toward meeting customer needs.

Incomplete evaluation criteria for awarding the contract

One of W. Edwards Demings 14 points for management

F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I

suggests that companies should end the practice of awarding business on the basis of price.1 (Even when customers are not required to take the low bid, price is often the primary focal point of bid development and negotiation.) Yet, in practice if not in policy, it seems that price still drives many purchasing decisions. One reason is that customers are often unable to define their needs sufficiently to compare bids on an apples-to-apples basis. Another problem is that although the users, technical experts, and managers need to review the various bids so that they have an opportunity to assess the proposed solutions against their own criteria, this practice isnt usually followed. Users usually have the most at stake in the decision, but they often have the least clout in the decision-making process. Current bidding practices de-emphasize the importance of creating alignment between the contractor and customer so that they are both working toward the same end. Instead, these practices put the contractor and customer in an adversarial relationship and might even put one party in a position where it needs to take drastic measures to recover. For example, one contractor

set change-order quotas for project team leaders to make up for how far it had cut into the profit margin during the bidding process.

Recommendation No. 2: Use a teaming process

Teaming with suppliers has been used in product development for years. The concept of teaming (or partnering in the nonlegal sense) with suppliers stresses having fewer suppliers and working closely with them so they understand the customers needs well. This way, both the customer and the supplier have a stake in each others success. In the contracting process, the basic idea is for a customer to select a supplier (contractor) based on its ability to provide a solution. Then, the customer and contractor can develop the plan for the solution together, prior to or concurrent with pricing the project. (The plan for the solution is called a project plan, which covers everything after the award of the contract.) For example, an industrial turbine manufacturer began the teaming process with a contractor that possessed a critical capability. The partnership evolved from negotiating volume sales

Figure 2. How QFD Can Be Integrated Into the Contracting Process

Award Acceptance

Needs definition

Solution definition

Solution design

Solution development, testing,

Solution support, service, and enhancement

Requirements specification

Request for proposals

Proposals

Functional specification

Design specifications

installation, and turnover

Customers
Users Technical Management

To bid

Internal
Technical Sales and marketing Management

Collect, sort, and prioritize needs

Link needs to technical characteristics

Deploy requirements and targets to team members

Monitor and address customer needs met throughout project

Team
Suppliers Support Core members

Quality Progress February 1996

67

F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I

Figure 3. The Spiral Model of the Contracting Process CUSTOMER NEEDS AND GENERAL APPROACH
Concept

P rod

uct Process Support Product Proc

es s

Design

P ro d uc

t Process Support Produ

ct

Develop
Pr o d u ct
Process Support

and build

P roduct Process Support

too busy to review the compiled plan for the hand-offs (i.e., the passing of project information and deliverables from one subteam to another) that had to occur. The result was that the project was more than 12 months late, due to: The stacking of underestimated time frames for testing and approvals Misperceptions regarding the development of the projects design, prototype, training, and documentation Poor assumptions about when people would be available to work on the project In a related case, a company decided to develop a computerized control system device. The project manager prepared a project plan based on subteam requirements. Management, however, had already promised a delivery date much earlier than that given in the teams plan. Not surprisingly, the device was delivered six months after the promised delivery date. (In fact, many of the previous product launches at this company were either late or on time but with reduced product functionality.) Based on anecdotal evidence from many industries, these types of scenarios are much more common than one would expect.

Solution

Refine

Recommendation No. 3: Use a group-based integrated planning approach

If the team members, including customer and contractor personnel from the key functions involved in the project, work as a group to develop the plan, they are more likely to develop an integrated project plan than if the project manager works independently. An integrated plan includes, at the minimum, sufficiently defined team deliverables and hand-offs to allow each subteam a reasonable comfort level. Once the baseline project plan is developed, team members are in a better position to work the plan (i.e., make local decisions that fit the overall team direction) because they understand the details and trade-offs within the plan, they have committed to it in front of others, and they have developed the working relationships within the team that promote extra effort to make sure deadlines are met. This is probably the first point at which the plan should be entered into a computer program. It could be argued that the group-based integrated planning approach cannot be used for complex, large-scale projects. But it could also be argued that, if the plan is so complicated that it cannot be comprehended, it cannot be effectively executed either. This approach will work on large-scale projects; they just might require several levels of planning. Working together in meetings to determine the milestones and criteria for hand-offs will bring conflicts and difficult decisions, but the payoff is immense. For example, one contractor asked a group of five different suppliers (many of which had overlapping services and interests) to join the team to help prepare a bid for a project. Using the group-based integrated planning approach, a complex bid for more than $1 million of work was developed during a one-day meeting. In addition, the group accomplished some initial team building.

agreements to sharing on-line ordering and quality data, sharing high-level business plans for new products and, finally, to including the supplier on a new product development team in the concept phase. The contractor and the manufacturer have both benefited from their partnership. The contractor has increased its business volume, improved its expertise in hightemperature metal coatings, and developed specific expertise in the turbine industry. The manufacturer now has higher-quality, lower-cost parts and a better end product. Of course, there are also risks for both parties in the teaming approach. The contractor could engage in predatory pricing once it had a lock on the project; the customer could engage in heavy-duty arm twisting on price with the promise of future revenues once the supplier has committed resources to the project. Although the teaming approach requires mutual trust, it can reduce the need for costly risk management tactics, such as inflating prices, ducking difficult-to-address customer needs through loosely written specifications, or initiating changeorder quotas.

Poor planning of the project activities

Defects in a project plan can often be traced to faulty performance in early process steps. If the needs are poorly defined, the tasks required to meet those needs will be vague or wrong. Typically, project plans either lack the detail to prove that customer requirements are being met or are so detailed that nobody checks their validity or buys into them. A worst-case example involved a project to develop a graphical interface for a controls system. The team leader asked the functional subteam leaders to put a plan together for their individual parts of the project. Once all of the plans were turned in, the team leader simply compiled them on his computer and distributed them to all key players. Unfortunately, everyone was
68
Quality Progress February 1996

Poor assimilation of necessary midstream project changes

When using a group-based integrated planning approach, the contracting process must allow for the extra dialogue and for modifications to the original plan. Rather than thinking that the

F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I

defined and documented requirements are set in stone or forcing finalization earlier in the process than is reasonable, the project plan should include intermediate milestones and reassessments to better fit the reality of how people come to a common understanding of needs, contract deliverables, and so forth. Most plans display the bias that change is an anomaly when, in fact, change is inevitable. Customers might change their business strategies during the project and, hence, their requirements for the solution. Technology might advance or the new technology planned for the solution might hit a snag in development. If the project plan has no room for adjustments to deal with unforeseen needs or problems, there is no room to work around those needs or problems. Several words of caution, however, must be given in regard to making changes to the project plan: While the cost of small in-process changes can be absorbed, big ones can significantly increase the project cost. The team leader must be alert for all changes and not let big ones slip through unnoticed (many big ones look small at first). Although many contractors consider change orders to be good business, they are a major source of potential customer dissatisfaction. From the customers perspective, a change order means they have to go back to their managers to sell them on why more funds are needed for the project. Customers often feel taken advantage of because they know that margins are typically higher on change-order work than the original-project work. They might blame the contractors, thinking that the contractors didnt listen closely enough or didnt understand their businesses well enough to provide what they needed, instead of what they asked for. From the contractors perspective, changes are very expensive (and frustrating) to incorporate in process. There is a real cost in productivity and energy associated with documenting a change, identifying its effect on other project areas, and communicating the information to everyone who needs to know. Every change is another opportunity to make a mistake; it introduces potential errors or discrepancies in the project information. Sometimes, the customer wants to change the solution back to what the contractor originally proposed, even though the customer initially refused it due to cost.

Most project plans display the bias that change is an anomaly when, in fact, change is inevitable.
The project plan should incorporate several features to minimize the pain of change and to account for in-process learning: Cushions should be allowed in schedules and budgets, but these cushions must be managed by the team and not buried in every task so that milestones are not taken seriously. Risks pertaining to potential changes should be systematically analyzed and managed. Accelerated prototypes or demos of critical elements should be prepared to get feedback on the solution earlier in the project (e.g., rapid prototyping as used in software development). Of course, traditional change control and management procedures are also important.

Metrics and rewards driving the wrong performance

There is an old but true business adage, You get what you measure. At a macro business level, contractors are rewarded by winning the contract if they underbid, exaggerate delivery capabilities, underestimate risk, or undersolve the customers problem to get the price lower than their competitors. They are further rewarded with change orders for their ability to argue specification interpretation issues. At the project level, the same types of issues exist.

Recommendation No. 5: Focus metrics on customer satisfaction and quality

Measurement is a key part of the quality discipline. Project metrics can be determined up front if the project is geared toward a desired business result for the customer (such as reduced cost, more productivity, or improved quality). The people involved early in the sale of the solution are often involved in these types of issues, but the people doing its postsale implementation are not. This results in project metrics based on schedule and cost plan vs. actual. At its worst, this can result in a project manager completing a project on time at the planned margin but without it meeting the customers needs. To the customer, the most important consideration is the suitability of the end product over the long term. The customer must have a solution that serves its operational purposes and a system that provides the anticipated paybackor the project will be deemed a poor business decision. The right metrics need to be identified and made visible to the team, the customer, and the contractor. Metrics for project outputs are typically assessed during acceptance testing. Metrics on the contracting process itself such as customer satisfaction, disruption of customer operations, and decision-making cycle timeare more often overlooked. Yet, these types of data could serve as an early warning system for potential downstream problems. The QFD format can be used to help link metrics to requirements.
Quality Progress February 1996

Recommendation No. 4: Change the model

As Figure 1 showed, the typical model used to illustrate the contracting process is linear. A better representation, however, would be a spiral (see Figure 3). The spiral shows the incremental progress in all areas of the solution and ensures communication among all players in the process. In the product development world, this approach is sometimes called concurrent engineering, simultaneous engineering, or integrated product development because the people who produce, maintain, and support the solution begin developing their processes at the same time as the product is being designed. Actually, the contracting process can be accurately represented using the typical linear model if a subtle point is well understood: The phases refer to activities, not individual functions, with team involvement in all phases. For example, when designing a software system, the design specifications should still be created before the final software code, but the software developers should be able to review and provide input on the specifications as they are written to ensure that the coding can be written efficiently.

69

F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I F V I

A change in mind-set is needed

The five recommendations described here are neither costly nor difficult to implement. An increasing number of contractors are already using QFD to define product and service features and quality requirements. The Department of Defense acquisition process includes a number of quality-related provisions (especially risk assessment and management provisions and provisions for evolving requirements) to improve the effectiveness of its contracting process.2 Throughout the business world,

experienced project managers are learning to create sound, well-integrated plans. Improving the contracting process requires a change in mindset. At issue is the trust between the customer, the contractor, and suppliers. Since contracting has historically been adversarial, it is unrealistic to expect companies to trust each other without first establishing a relationship. This relationship can be created by: Paying the contractor for the end deliverable and the consulting work needed to effectively define the customers needs up front Creating a mutually beneficial partnership between the contractor and customer Developing well-integrated project plans that are aligned with the business goals of the contractor, customer, and suppliers Developing project plans that minimize the pain of change and account for in-process learning Setting up project and process metrics that focus on customer satisfaction and quality Although establishing trust and adapting quality principles to fit a contracting environment are not easy tasks, there are certainly rewards to those that invest in the effort.

References
1. W. Edwards Deming, Out of the Crisis (Cambridge, MA: Massachusetts Institute of Technology, Center for Advanced Engineering Study, 1986). 2. DOD 5000.2 Defense Acquisition Management Policies and Procedures, Jan. 23, 1991. Pete Hybert is a senior associate at SWI, a management consulting services firm in Naperville, IL. He received a masters degree in instructional systems design from Northern Illinois University in DeKalb. Hybert is a member of ASQC.

What did you think about this article?

Quality Progress needs your feedback. On the postage-paid reader service card inserted toward the back of this magazine, please circle the number that corresponds with your opinion of the preceding article. Excellent Good Fair Poor Circle #341 Circle #342 Circle #343 Circle #344

70

Quality Progress February 1996