In a milestone-driven business, deliverables are the backbone of an outsourcing contract. When the company receives first draft of story, the first pass of concept art, the deliverable triggers payment. Yet are there times when the deliverable-based contract actually works against the flexibility needed in the development process?
Experience shows that in a collaborative environment, deliverables don’t always deliver. Once, a contract writer came in for a two-day meeting with the company. We worked in collaboration to develop an initial story premise. For all intents and purposes, his work was done. However, since his contract required a deliverable, he was compelled to write out the story which we had already established, forcing him to act as a glorified secretary. I won’t even mention the time he collaborated on a storyline we didn’t go forward with, through no fault of his own.
Both situations could have been avoided with a contract not based solely on deliverables. The company could have created a contract including a deliverable with an option for what is called “specific performance.” Specific performance could include any service of value, such as attending meetings with designers. If the meeting did not go forward, the deliverable method would kick in. If the company elected, however, they could pay upon the specific performance of attending the meeting. When working in a collaborative environment, flexibility is key. This method would speed up the development process so no one is waiting for deliverables that are no longer relevant.
When is a deliverable not a deliverable? When you elect specific performance instead.