Methods of Payment

In consulting engagements, paying the piper doesn’t necessarily mean calling the tune. The way the piper is paidthe consulting fee structurematerially affects the obligations of both parties. Moreover, the choice among payment options can significantly influence the way the work gets done, the quality of the outcome and the ultimate satisfaction of the customer.

There used to be only two fee structures: billable hours (time and materials) and fixed price. Today, however, there are also hybrid models that include some features of both, as well as novel arrangements that define a variety of ongoing financial and business relationships between consultants and their customers. Each option has advantages and disadvantages, and the choice of fee model should be carefully weighed against the nature and goals of the project.

Until recently, the majority of IT consulting contracts were based on a billable-hours fee structure, with the consulting firm supplying personnel to define, develop or support a required system. Ideally, such arrangements give customers as-needed access to specialized technical expertise that may not exist in-house. An exclusive CIO survey shows that this is by far the most oft-cited reason (74.4 percent of respondents) for hiring IT consulting help (see “The Strangers in Your Midst”). Renting the consultant’s skill set is more practical and cost-effective than recruiting frequently hard to find permanent employees. The danger, however, is that speedy delivery of the needed solution may not be in the consultant’s best economic interest.

Consequently, making a billable-hours arrangement work requires a set of stringent acceptance criteria and time and budget milestones that can keep the project on target. “A good contract will specify deliverables at specific phases of the project that can be measured and recognized by both sides of the team,” says Carolyn Purcell, executive director of the State of Texas Department of Information Resources. “Those deliverables and milestones are extremely important.”

UOP Inc., a petroleum-processing technology company in Des Plaines, Ill., learned this lesson the hard way. UOP hired Andersen Consulting in May of 1992, expecting to pay $15 million for a new computer system to handle project bids. But by December of the following year, UOP concluded that it had already paid $8 million in billable hours for a system that not only didn’t work but would cost a grand total of $21 million to get up and running.

The reasons for the cost overrun, according to Tobey Marzouk, an attorney based in Washington, D.C., who specializes in software litigation, were a lack of stringent acceptance criteria along with a failure to adequately define project success. “All Andersen was contractually obligated to provide was warm bodies,” says Marzouk. “There was no firm promise that anything useful would actually be produced.”

Another hazard of the billable-hours fee structure is bait-and-switch staffing. The largest consulting firms are particularly guilty of this, according to Marty Glavin, a principal at Nextera Enterprises LLC’s Sigma Consulting Group in Rochester, N.Y., who used to be a senior manager at two of the Big Five firms. “You have a senior partner who does the selling and acts as the lieutenant to the client’s senior management, but then the project gets staffed by a lot of kids right out of school.” To avoid the bait-and-switch syndrome, customers need to tie the fee structure to the actual people who will do the work. A good contract, says Purcell, “[contains] some warranty upfront that the people who do the work are the people who are in the contract and [provides for] a penalty to the vendor if those people aren’t available.”

Because many customers have grown leery of billable hours, some consulting firms now offer contracts with a fixed-price fee structure. One pioneer of this model is Cambridge, Mass.-based Cambridge Technology Partners Inc. “We guarantee the price,” says President and CEO Jim Sims. “If applications are late, we assume the costs.” A key element of Cambridge’s fixed-price contract is the company’s application development methodology, which allows users to see what they’re getting, reducing the likelihood of potentially costly, after-the-fact changes to the system. (See “The Latest in Suits”)

Fixed-price contracts are not a panacea for runaway projects, however. This is especially true if the contract provides for open-ended expenses, according to Karen Boucher, vice president of The Standish Group International Inc., an IT market research firm in Dennis, Mass. Boucher cites a pharmaceutical company that hired a major consulting firm to revamp its customer-information system under a fixed-price contract. Unfortunately, the contract also specified that the customer was responsible for the transportation, room and board for some 20 consultants, who flew first class, stayed in luxury hotels and ate at gourmet restaurants while on assignment. The result: a bill for expenses alone that totaled 120 percent of the original fixed price.

Fixed-price contracts can also be, well, pricey. Sometimes the amount of customization required to adapt a standard application to a customer’s requirements is far less than Customers should always maintain ultimate authority and control.the customer is led to believe. Thus, customers can end up paying too much for what may turn out to be relatively trivial amounts of work. Fixed-price contracts can become even less cost-effective when the consultant doesn’t know exactly what’s needed. Typically, says Marzouk, in such cases “the consultant will inflate the fixed price until it reaches his or her comfort level,” and the project ends up costing far more than it otherwise might have.

Customers sometimes try to hedge their bets by combining the billable-hours and the fixed-price fee structures. One way to do this is to hire the consultant on a time-and-materials basis but have an upper limit on how much can actually be spent. But while setting a price cap might seem like a smart idea, the likelihood of any real cost savings is small, because the consultant will probably make certain that the number of billable hours magically ends up equaling the price cap. “It’s like telling a building contractor that you’d like to spend from $10,000 to $25,000 on a new kitchen,” says Marzouk. “Guess what? You’re going to end up with a kitchen that costs right around $24,999.”

Another hybrid of the billable-hours and fixed-price models can be found in contracts that contain a provision for billable hours should the customer want to add features not included in the fixed-price deal. It is sometimes essential to project success to be flexible and to be able to add features, and a good contract should always include mechanisms for making reasonable changes, especially when the customer lacks the upfront discipline to define the system completely before it is implemented. There is, however, a danger that change requests, even reasonable ones, could turn the engagement into a runaway project. To prevent this, the customer needs to put in place a process to determine what is and what isn’t a reasonable addition, as well as monitor the delivery dates and acceptance criteria of those changes. Without this, even a fixed-price project can spiral out of control and become an open-ended billable-hours engagement.

Some customers have tried to overcome the limitations of traditional fee structures by entering into business partnerships with their consultants, according to Ellen Kitzis, vice president of Dataquest’s IT Services organization. “In a couple of cases, we’re seeing joint ventures where vendor and client both have an economic interest in the success of the project,” explains Kitzis. “In some cases, [they are] creating separate entities that will share profits and losses.” For example, a few years ago, Swiss Bank Corp. and Perot Systems Corp. cut a deal, estimated at $6.25 billion over 25 years, for Perot to manage IT operations at the bank’s investment banking division. The agreement gave Perot Systems a 40 percent share in the software development and sales subsidiary of Swiss Bank. In return, the bank received an option to purchase an approximately 25 percent stake in Perot (see “The Odd Couple,” CIO, May 15, 1996).

Such agreements, however, are relatively rare, says Charles Madigan, co-author of Dangerous Company: The Consulting Powerhouses and the Businesses They Save and Ruin (Times Books, 1997). “Only 2 percent of contracts have risk-sharing,” says Madigan. And even when such contracts are cut, it doesn’t necessarily mean that the customer and consultant will fall into lock step, with each committed to the other’s success. In the Swiss Bank deal, for example, the project was eventually reduced to $2.5 billion over 10 years, with Swiss Bank alleging that Perot Systems overestimated the cost savings to win the contract, according to a report by The Standish Group.

But risk-sharing arrangements aren’t limited to megadeals with stock swaps. Sometimes customers simply hope to recoup some of their development costs by selling the software the consultant developed for them to other companies. However, that’s an unlikely strategy unless the contract specifically gives the customer a financial interest in the software. “The default is for the consultant to own the copyright on the software unless the contract has a written assignment giving the customer rights to it,” says Marzouk. And even then, the customer is unlikely to realize much return. Even if the project results in a generically useful software component, the consultant will tend to structure the eventual product so that the contribution of the initial customer’s project is difficult to isolate. “The client shouldn’t bank on a penny,” Marzouk says.

Rather than worry about making money on the deal, customers should focus on making certain that the deal doesn’t end up costing more than originally anticipated. That’s particularly risky when it comes to the maintenance and repair of any system, regardless of the fee structure. “On the business side, you want everything to be as clear as if it were written by Moses,” says Madigan. “You have to veer away from anything that’s murky.” The worst kind of contract, he says, is one that includes language that, when translated out of legalese, boils down to “We’ll just keep fixing it until it works.” That’s a recipe for cost overruns, because in many cases, contracts specify that the customer must pay for ongoing maintenance of the system. Boucher echoes both Madigan and Marzouk: “A contract should have no loopholes. It should clearly state what happens if the consultant doesn’t do the job correctly or doesn’t deliver what was promised or delivers the product long after the original deadline.”

Boucher also recommends that every project team consist of a mix of employees and consultants, with at least 50 percent of every team staffed by permanent employees. She further recommends that the project leader be a permanent employee that reports directly to the customer’s IT management. Without these controls, she says, “it’s too easy for [the consultants] to lead the project the way that they would like it to go.”

In other words, the fee structure and the contract should give the customer ultimate authority and control over the project.end

Geoffrey James is the author of Success Secrets from Silicon Valley (Times Books, 1998). He can be reached through www.businesswisdom.com.