five ways to improve contracting process

8/6/2019 Five Ways to Improve Contracting Process

1/6

Quality Progress/

February 1996 65

OMPANIES THAT USE A CONTRACTING

process to provide customized, large-scale systems or products (e.g., infor-

mation or telecommunication systems)have struggled to adapt the core quality

principles to their businesses. While some havebeen successful, many have run into serious prob-lems. The problems typically stem from trying toforce-fit the use of quality tools. To improve thecontracting process, companies need to focus oneffectively achieving the mission of the contract-ing process rather than on figuring out ways inwhich to use the quality tools.

The contracting process, which is similar tomany product development processes, can befound in a number of industries, including com-puter systems, telecommunication systems, air-

craft and ship building, and construction.Contracting is the process by which customizedsystems are designed and delivered. Often, theterm solution is used to describe a combinationof customized products and services that are soldtogether as a solution to meet customer needs.

As Figure 1 shows, the contracting process isfairly generic. So, too, are its problems: The solu-tion might not match the customers real needs,schedules might be missed, or there could be somany change orders that they become obsoletebefore they are approved. The process often failsto yield customer satisfaction, produces unpre-dictable profits for the contractor, creates stress for

the customer, and ties up more resources for moretime than desired. Out of a number of potentialproblems like these, there are five primary onesthat 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 pro-

ject changes (driven by problems or improve-ments discovered during the project)

Metrics and rewards driving the wrong perfor-mance

Poor up-front definition of customer needs

Since deficiencies in the needs definition

process snowball as they roll further into the pro-ject, improving this process is a critical step towardmore effective projects. The core of the needs defi-nition process is the series of specifications that aredeveloped by the customer and, possibly, by com-peting suppliers.

If contractors were to complete an applicationfor the Malcolm Baldrige National Quality Award,they would probably view their specificationprocess as a plus. After all, arent specifications theresult of working with the customer to define theirrequirements? Ideally, yes. In actuality, the specifi-cations usually define only the technical aspects ofthe solution. They might not address quality

requirements, customer satisfaction requirements,or cost considerations (such as development orlife-cycle cost targets). So the specifications dodescribe customer requirements, but they areincomplete because they describe only one seg-ment of the customer population: the technicalevaluators. More important, because the specifica-tions are developed up front rather than throughoutthe process, they are often inaccurate or incom-plete in retrospect.

Specifications might also be written with theintent to influence the customers requirements.Successful contractors try to minimize competitivebid pressure by working up front with customers to

position themselves as the supplier of choice. Thiscan result in specifications that dont indicate whatthe customers need but rather what the contractorwants to give them.

For example, one of the stated sales strategiesfor at least three contractors is to write the specifi-cations for the customer. They train salespeople toposition this idea as a time- and work-saver for thecustomer and provide salespeople with boilerplatespecifications that favor their own products. In the-ory, this could be harmless if the requirementswere closely matched to customer needs. In prac-tice, however, salespeople tend to use the boiler-

Five Ways to Improve the ContractingProcess

The

relationship

between

contractor and

customer

doesnt have to

be adversarial.

byPete Hybert

C

==

= five5IIII =


2/6

66 Quality Progress/February 1996

plate specifications to shortcut the needs definition process.

Initially, everyone is happy because the process moves morequickly. But the customers eventually discover the mismatchesbetween their needs and what is being developed and have tomake expensive midproject changes.

Specifications are typically not user-friendly documents; theydo not communicate customer needs well, especially to thosewho were not involved in the process of developing them (suchas new members on the project team or people who join theproject downstream). Specifications are typically written inengineering- or legalese and rely on lengthy text with few dia-grams, charts, or bullets to aid communication. Most important,sometimes the contents can be interpreted more than one waybecause 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 prob-lems. It also prevents customers from being held to an earlyview of a requirement that might evolve as the project progress-es. Where interpretations vary, the players must adopt hardballnegotiating tactics, which certainly does not promote customersatisfaction with the project, regardless of the outcome.

Recommendation No. 1: Use a quality functiondeployment approach

Customers and contractors have a common interest in clearlydefining needs in the early stages of a project. A quality func-tion deployment (QFD) approach for defining functionality,quality, and cost requirements can reduce time and errors in thispart of the process.

If the contractors goal is to deliver a system or product thatmeets long-term customer requirements, its mind-set has toshift from deliverables and technical specifications (i.e., Whatis the minimum I owe you?) to customer functionality (i.e.,What work will the customer be doing, and how will this sys-tem or product improve the ease, cost, and quality of thatwork?). For this to happen, the contractor must incorporate theneeds ofall stakeholders in the customers organization.

For example, suppose the customer is a chemical processingplant looking for a control system for a new process. The plantsexecutives are concerned about return on investment, cash flow,and life-cycle costs. Its operations managers are interested inreliability, maintainability, and resources needed to support the

system. The operators, or users, of the system are concerned

with ease of learning, ease of use, and ease of access to refer-ence information. (Too often, the users, including those whosupport and maintain the system, have the least input on itsdesign.) Finally, technical experts are looking for system datafor quality assurance tracking, the ability to adjust the systemfor varying situations, and so forth. There might even be regula-tory needs as well. The needs of all these stakeholders must bemet for the control system to improve the ease, cost, and qualityof their work.

This is where the QFD matrix (often referred to as the houseof quality) and the group consensus process can help. A teamconsisting of key personnel from both the customer and con-tractor organizations should use a consensus approach to devel-op the customer requirements portion of the QFD matrix (i.e.,

collect, sort, and prioritize customer requirements). Manyapproaches for gathering information can be used (e.g., focusgroups or individual interviews), as long as the primary goal isto understand what the customer needs and expectsand not tocreate a perfect QFD matrix.

The value of the QFD approach is that the identified needsare clear, specific, and easily understood. They also truly reflectthe customers requirements because generating the matrixtakes dialogue, clarification, and more than a single iteration(the needs can be reviewed and revised by all of the stakehold-ers before awarding the contract). Although documenting cus-tomer needs with the QFD approach will increase the time frominitial project concept to bidding, it will result in time and dollarsavings downstream because changes and conflicts will be

reduced.Figure 2 illustrates how other QFD elements can be integrat-

ed into the contracting process. Once the customer needs aredefined, they can be translated into technical requirements andlinked to elements of the solution, completing the QFD matrix.Upon award of the contract, the key result measures or solutionelements can be deployed to various team members to ensurethey are not later forgotten. Then, part of each team meeting canbe spent focusing on progress toward meeting customer needs.

Incomplete evaluation criteria for awarding thecontract

One of W. Edwards Demings 14 points for management

Figure 1. A Generic Model of the Contracting Process

Needs definition

Requirementsspecification

Request forproposals

Solution definition

ProposalsFunctional

specification

Solution design

Designspecifications

Solution

development,

testing,

installation,

and

turnover

Solution

support,

service,

and

enhancement

Award Acceptance

FIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIVFIV


3/6

Quality Progress/

February 1996 67

suggests that companies should end the practice of awardingbusiness on the basis of price.1 (Even when customers are notrequired to take the low bid, price is often the primary focalpoint of bid development and negotiation.) Yet, in practice if notin policy, it seems that price still drives many purchasing deci-

sions. One reason is that customers are often unable to definetheir needs sufficiently to compare bids on an apples-to-applesbasis.

Another problem is that although the users, technical experts,and managers need to review the various bids so that they havean opportunity to assess the proposed solutions against theirown criteria, this practice isnt usually followed. Users usuallyhave the most at stake in the decision, but they often have theleast clout in the decision-making process.

Current bidding practices de-emphasize the importance ofcreating alignment between the contractor and customer so thatthey are both working toward the same end. Instead, these prac-tices put the contractor and customer in an adversarial relation-ship 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 forhow far it had cut into the profit margin during the biddingprocess.

Recommendation No. 2: Use a teaming process

Teaming with suppliers has been used in product develop-ment for years. The concept of teaming (or partnering in thenonlegal sense) with suppliers stresses having fewer suppliersand working closely with them so they understand the cus-tomers needs well. This way, both the customer and the suppli-er have a stake in each others success.

In the contracting process, the basic idea is for a customer toselect a supplier (contractor) based on its ability to provide asolution. Then, the customer and contractor can develop theplan for the solution together, prior to or concurrent with pricingthe 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 theteaming process with a contractor that possessed a critical capa-

bility. The partnership evolved from negotiating volume sales

Users

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

Needs definition

Requirementsspecification

Request forproposals

Solution definition

Proposals Functionalspecification

Solution design

Designspecifications

Solution

development,

testing,

installation,

and

turnover

Solution

support,

service,

and

enhancement

Award Acceptance

Technical

Management

Technical

Sales andmarketing

Management

Suppliers

Support

Coremembers

Customers

Internal

Team

Collect, sort, andprioritize needs

Link needsto technical

characteristics

Deployrequirementsand targets

to teammembers

Monitor and address customer needsmet throughout project

To bid



4/6


agreements to sharing on-line ordering and quality data, sharinghigh-level business plans for new products and, finally, toincluding the supplier on a new product development team inthe concept phase. The contractor and the manufacturer haveboth benefited from their partnership. The contractor has

increased its business volume, improved its expertise in high-temperature metal coatings, and developed specific expertise inthe 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 teamingapproach. The contractor could engage in predatory pricingonce it had a lock on the project; the customer could engage inheavy-duty arm twisting on price with the promise of futurerevenues once the supplier has committed resources to the pro-

ject. Although the teaming approach requires mutual trust, itcan reduce the need for costly risk management tactics, such asinflating prices, ducking difficult-to-address customer needsthrough loosely written specifications, or initiating change-order quotas.

Poor planning of the project activitiesDefects in a project plan can often be traced to faulty perfor-

mance 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 cus-tomer requirements are being met or are so detailed that nobodychecks their validity or buys into them.

A worst-case example involved a project to develop a graphi-cal interface for a controls system. The team leader asked thefunctional subteam leaders to put a plan together for their indi-vidual parts of the project. Once all of the plans were turned in,the team leader simply compiled them on his computer and dis-tributed them to all key players. Unfortunately, everyone was

too busy to review the compiled plan for the hand-offs (i.e., thepassing of project information and deliverables from one sub-team to another) that had to occur. The result was that the pro-

ject was more than 12 months late, due to: The stacking of underestimated time frames for testing and

approvals Misperceptions regarding the development of the projectsdesign, prototype, training, and documentation

Poor assumptions about when people would be available towork on the projectIn a related case, a company decided to develop a computer-

ized control system device. The project manager prepared aproject plan based on subteam requirements. Management,however, had already promised a delivery date much earlierthan that given in the teams plan. Not surprisingly, the devicewas delivered six months after the promised delivery date. (Infact, many of the previous product launches at this companywere either late or on time but with reduced product functionali-ty.)

Based on anecdotal evidence from many industries, thesetypes of scenarios are much more common than one wouldexpect.

Recommendation No. 3: Use a group-based integratedplanning approach

If the team members, including customer and contractor per-sonnel from the key functions involved in the project, work as agroup to develop the plan, they are more likely to develop anintegratedproject plan than if the project manager works inde-pendently. An integrated plan includes, at the minimum, suffi-ciently defined team deliverables and hand-offs to allow eachsubteam 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 deci-sions that fit the overall team direction) because they understandthe details and trade-offs within the plan, they have committedto it in front of others, and they have developed the workingrelationships within the team that promote extra effort to makesure deadlines are met. This is probably the first point at whichthe plan should be entered into a computer program.

It could be argued that the group-based integrated planningapproach cannot be used for complex, large-scale projects. Butit could also be argued that, if the plan is so complicated that itcannot be comprehended, it cannot be effectively executedeither. This approach will work on large-scale projects; they justmight require several levels of planning.

Working together in meetings to determine the milestonesand criteria for hand-offs will bring conflicts and difficult deci-sions, but the payoff is immense. For example, one contractorasked a group of five different suppliers (many of which hadoverlapping services and interests) to join the team to help pre-pare a bid for a project. Using the group-based integrated plan-ning approach, a complex bid for more than $1 million of workwas developed during a one-day meeting. In addition, the groupaccomplished some initial team building.

Poor assimilation of necessary midstream projectchanges

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

Product Process Support Product Proce

ss

Product Process Support Produc

t

Product Process Support

Product Process Suppo

rt

Figure 3. The Spiral Model of the Contracting Process

CUSTOMER NEEDS AND GENERAL

APPROACH

Solution

Concept

Design

Develop

and build

Refine



5/6

Quality Progress/

February 1996 69

defined and documented requirements are set in stone or forc-ing finalization earlier in the process than is reasonable, the pro-

ject plan should include intermediate milestones and reassess-ments to better fit the reality of how people come to a commonunderstanding 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 busi-ness strategies during the project and, hence, their requirementsfor the solution. Technology might advance or the new technol-ogy planned for the solution might hit a snag in development. Ifthe project plan has no room for adjustments to deal withunforeseen needs or problems, there is no room to work aroundthose needs or problems.

Several words of caution, however, must be given in regardto 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 teamleader must be alert for all changes and not let big ones slipthrough unnoticed (many big ones look small at first).

Although many contractors consider change orders to begood business, they are a major source of potential cus-tomer dissatisfaction. From the customers perspective, achange order means they have to go back to their managersto sell them on why more funds are needed for the project.Customers often feel taken advantage of because they knowthat margins are typically higher on change-order work thanthe original-project work. They might blame the contractors,thinking that the contractors didnt listen closely enough ordidnt understand their businesses well enough to providewhat they needed, instead of what they asked for.

From the contractors perspective, changes are very expen-sive (and frustrating) to incorporate in process. There is a realcost in productivity and energy associated with documentinga change, identifying its effect on other project areas, andcommunicating the information to everyone who needs toknow. Every change is another opportunity to make a mis-take; it introduces potential errors or discrepancies in the pro-

ject information. Sometimes, the customer wants to changethe solution back to what the contractor originally proposed,even though the customer initially refused it due to cost.

Recommendation No. 4: Change the model

As Figure 1 showed, the typical model used to illustrate thecontracting process is linear. A better representation, however,would be a spiral (see Figure 3). The spiral shows the incremen-tal progress in all areas of the solution and ensures communica-tion among all players in the process. In the product develop-ment world, this approach is sometimes called concurrentengineering, simultaneous engineering, or integrated prod-uct development because the people who produce, maintain,and support the solution begin developing their processes at thesame time as the product is being designed.

Actually, the contracting process can be accurately represent-ed using the typical linear model if a subtle point is well under-stood: The phases refer to activities, not individual functions,with team involvement in all phases. For example, whendesigning a software system, the design specifications shouldstill be created before the final software code, but the softwaredevelopers should be able to review and provide input on thespecifications as they are written to ensure that the coding canbe written efficiently.

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 mini-mize 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 buriedin every task so that milestones are not taken seriously.

Risks pertaining to potential changes should be systematical-ly analyzed and managed.

Accelerated prototypes or demos of critical elements should

be prepared to get feedback on the solution earlier in the pro-ject (e.g., rapid prototyping as used in software develop-ment).Of course, traditional change control and management proce-

dures are also important.

Metrics and rewards driving the wrong performance

There is an old but true business adage, You get what youmeasure. At a macro business level, contractors are rewardedby winning the contract if they underbid, exaggerate deliverycapabilities, underestimate risk, or undersolve the customersproblem to get the price lower than their competitors. They arefurther rewarded with change orders for their ability to arguespecification interpretation issues. At the project level, the sametypes of issues exist.

Recommendation No. 5: Focus metrics on customersatisfaction and quality

Measurement is a key part of the quality discipline. Projectmetrics can be determined up front if the project is gearedtoward a desired business result for the customer (such asreduced cost, more productivity, or improved quality). The peo-ple involved early in the sale of the solution are often involvedin these types of issues, but the people doing its postsale imple-mentation are not. This results in project metrics based onschedule and cost plan vs. actual. At its worst, this can result ina project manager completing a project on time at the plannedmargin but without it meeting the customers needs.

To the customer, the most important consideration is the suit-ability of the end product over the long term. The customermust have a solution that serves its operational purposes and asystem that provides the anticipated paybackor the projectwill be deemed a poor business decision. The right metrics needto be identified and made visible to the team, the customer, andthe contractor.

Metrics for project outputs are typically assessed duringacceptance testing. Metrics on the contracting process itselfsuch as customer satisfaction, disruption of customer opera-tions, and decision-making cycle timeare more often over-looked. Yet, these types of data could serve as an early warningsystem for potential downstream problems. The QFD formatcan be used to help link metrics to requirements.



6/6


A change in mind-set is needed

The five recommendations described here are neither costlynor difficult to implement. An increasing number of contractorsare already using QFD to define product and service features

and quality requirements. The Department of Defense acquisi-tion process includes a number of quality-related provisions(especially risk assessment and management provisions andprovisions for evolving requirements) to improve the effective-

ness 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 mind-set. At issue is the trust between the customer, the contractor,and suppliers. Since contracting has historically been adversari-

al, it is unrealistic to expect companies to trust each other with-out first establishing a relationship. This relationship can be cre-ated by: Paying the contractor for the end deliverable andthe consult-

ing work needed to effectively define the customers needs

What did you think about this article?

Quality Progress needs your feed-back. On the postage-paid reader ser-vice card inserted toward the back ofthis magazine, please circle the numberthat corresponds with your opinion ofthe preceding article.

Excellent Circle #341

Good Circle #342

Fair Circle #343

Poor Circle #344

up front Creating a mutually beneficial partner-

ship between the contractor and cus-tomer

Developing well-integrated projectplans that are aligned with the businessgoals of the contractor, customer, andsuppliers

Developing project plans that mini-

mize the pain of change and accountfor in-process learning Setting up project and process metrics

that focus on customer satisfaction andqualityAlthough establishing trust and adapt-

ing quality principles to fit a contractingenvironment are not easy tasks, there arecertainly rewards to those that invest inthe effort.

References

1. W. Edwards Deming, Out of the Crisis(Cambridge, MA: Massachusetts Institute ofTechnology, 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, amanagement consulting services firm inNaperville, IL. He received a masters degreein instructional systems design from NorthernIllinois University in DeKalb. Hybert is amember of ASQC.


five ways to improve contracting process

Documents