Simple contracts are quick and cheap to draft and negotiate. But if our contract is too simple then we risk project failure. How do we draft the simplest possible contract?
1. Time is actually money (in this context at least)
Everything should be made as simple as possible, but not simpler
– Albert Einstein (attrib.)
The feedback that I received in relation to my article on “Agile” contracts was fantastic. And when I say fantastic, I mean half the comments were very positive, and the other half of the respondents thought that I had taken leave of my senses. Because the problem with “Agile” is that it is often used as an excuse not to project manage at all, or draft any form of contract at all.
So how do we draft the simplest possible contract that is also fit for purpose?
2. The larger and risker the project, the more project management and detailed contract structure we require
We need to project manage, including by agreeing up front what the customer is buying. But our contracts should be as short as possible, because the longer the contract, the longer it will take to negotiate. And in spite of what the poets say, time is in fact money - in this case at least.
In other words, simple contracts are relatively quick and cheap to draft and negotiate, but not all contracts should be short and simple. Because if our contract is too simple, then we risk project failure.
3. Use time and materials contracts for simple projects, and fixed price contracts for everything else
There are two contracting models:
- Time and materials contracts: where the supplier provides their people at a fixed daily rate (or hourly or monthly rate), but the supplier does not guarantee in the contract that their people will produce any particular outcome. We use time and materials contracts for projects that are low value and not complex (or risky).
- Fixed price contracts: where the supplier only gets paid if the supplier achieves specific outcomes. We use fixed price contracts for projects where it is worth the time to develop detailed specifications.
4. Don’t over-engineer or under-engineer the contract
The top left and bottom right quadrants in our table above show what happens if we “over-engineer” our contracts by using time and materials contracts for large complex projects, or “under-engineer” our contracts by using fixed price contracts for projects that are low value and not complex (or risky).
We don’t:
- Over-engineer by using fixed price contracts for projects that are low value and not complex (or risky), as the time invested in contract negotiations is not worth the return. For example, it makes no sense to pay more to negotiate the contract than its value (e.g. if we invest $1m to draft and negotiate a contract with a value of $10,000), unless what we are buying is critical to the business, or if the supplier providing inadequate services might cause damage to the business.
- Under-engineer by using time and materials contracts for large critical projects, as if we do not agree up-front what the supplier will provide to the customer, the customer risks massive cost blow outs, as the supplier will take no risk if there is a disconnect between what the customer thought that they were buying and what the supplier actually provides. The supplier will take no risk, and if the customer is not happy with the outcome of the project, the supplier will just charge more to complete the project.
5. Fixed price contract tools: modularising, catalogues, and Agile contracts
It takes a significant amount of time to negotiate a large, fixed price contract. Therefore, once we have chosen a fixed price contract, there are three tools that we can use to simplify the contract drafting process, and to make implementing the contract as simple as possible:
- “Modularised” contracts: are contracts that are split into smaller “chunks” or milestones with specific deliverables, customer acceptance tests, and payment gateways once each deliverable is delivered to the customer and accepted by the customer. As discussed in my “Agile” contracts article, some phases of the contract (separated by milestones) may be time and materials phases, and others may be fixed price.
- Catalogues: contemplate the customer purchasing a (relatively) large number of “widgets” that are well defined in the contract. For example, if the customer signs a contract to purchase a large number of laptops on an ad-hoc basis, it is worth spending the time to negotiate a contract that specifies exactly what the customer will be getting (e.g. laptop specifications, service levels, delivery times, etc.). Catalogues can work for any type of well defined service or deliverable that the customer may purchase in bulk over time. Catalogues can even work for business process outsourcing services and similar deliverables.
- “Agile” contracts: are modular contracts with fixed deliverables and phases, that allow the customer and supplier to use an Agile process for some or all of the contract phases, but still requires the supplier to produce “fixed” deliverables. The key is to ensure that our business team does noes not ask for an “Agile” contract with no milestones or deliverables specified in the contract. That’s just another way of proposing using a time and materials contract for a large critical project.
In summary, we can still keep our contracts simple. But it is a mistake to use simple time and materials contracts for large (or otherwise critical) projects.
This post originally appeared at iainmclaren.com. These opinions are mine. They are not necessarily those of my employer. Thanks to Alex Nathan for working with me to create the above matrix, and for reviewing drafts of this post.