The program director handed me a thick document. "Could you guys look at this contract and give us a thumbs-up?"
"What's it for?"
"We're going with another service desk vendor. We need to sign this contract Friday."
It was Tuesday afternoon. "All my people are busy on other projects. Why the rush now?"
"We need it by Friday to make the deadline." (Whose?) "Just look at the technical stuff."
"We'll do what we can."
Wednesday, after some Quality Coffee and Fireside Time with his 120-plus pages, I returned it to the still-anxious director.
Bear bad news first. "Won't work. Don't sign Friday."
"What? Why? We've been working this out for more than two months."
"Look, sorry." In addition to several glaring contractual oversights (fodder for another post), the contract omitted a critical data requirement. The vendor's system had no way to know who was calling the help desk. Responsibility for the data exchange had been left out.
We went over the other details together. Not a good day, but not terrible. At least we caught it.
The Real Problem
Getting lost in requirement and design details almost always works to an outsourcing vendor's advantage. Design elements not explicitly spelled out in the contract become change orders.
Even at an agreed-to rate change orders cost a premium. They stretch out the contract because the customer has already bought in and fears losing the investment. They're the icing on the cake.
Change orders also drive the in-house staff crazy. Wasn't the vendor supposed to take care of this problem? Why are we doing our work and their work too? Wasn't this supposed to save money?
Meanwhile, if the project is in implementation phase, good reason exists to miss the start-up deadline and press for the "on-time delivery" performance bonus. After all, the customer ordered the change; it isn't the vendor's glitch that made the project late.
The process design must be as complete as possible before contracting. It's especially hard when outsourcing services because the service boundaries may be loosely defined. The services drive the data and reporting requirements. Get these right before thinking about the details of, say, file transfer mechanisms.
Fixing the Design
Separate the contract into at least two pieces: legal boiler plate, and specifications, requirements, and design components. The boilerplate should reference the other document(s) as part of the binding contract.
Put the business and technical people to work on the design specs and the legal people to work on the boilerplate. Even if the final contract must be a single, unified document, the right folks will be looking at the right pieces instead of getting distracted by irrelevant work.
Go over the processes and hand-offs to find what information goes to whom, and who calls when. If it's within the team's skill set, I strongly recommend making a high-level UML Sequence Diagram to show these hand-offs. Flow charts can quickly become confusing and they obscure responsibilities.
Be sure the contract indicates who "owns" what pieces, of course. But also specify acceptance criteria on both sides, if possible.
The service desk project delayed three weeks until a new contract with the necessary changes went through.