Minimum Viable Contract
Contracting the terms in a business relationship involves a bizarre dynamic: the more you regulate, the more you have to regulate. It often starts with working out a limited number of situations, but soon the conversation becomes more detailed. This can descend to a level where all sorts of theoretical scenarios and risks are outlined, many of which are unlikely to ever occur. And then it’s also decided how parties should act in the event of such scenarios.
This practice raises the question of whether it can be done with a bit less. What needs to be documented at a minimum to commence a business partnership? And is it possible to then grow, for example, in scope and complexity?
What is already covered?
Under Dutch law, a lot is already covered at its core. The legislator has provided that business transactions and service agreements need to address matters such as warranties, liability, (intellectual) property, (in)direct damages, and payments. Much of this is thus enshrined in legislation, and there is ample case law available. Basic principles also exist regarding good corporate governance and care for employees.
It’s a paradox: by making fewer specific agreements, this general legislation becomes more significant. My contention is that less elaboration leads to better agreements.
What should we explicitly document?
Of course, there is still plenty to regulate and document. Legislation is generic, and the focus of a contract should (and, in my opinion, must) be entirely on the specific collaboration at hand. It is good to have agreement on several topics and to document them. Here’s what, in my opinion, should be addressed:
- Why – I echo Simon Sinek: “It starts with why.” It is essential to discuss in advance the intentions and objectives of both parties. Why are we entering into this relationship? When things get complicated down the road, this serves as a basis to fall back on.
- Scope – What are we going to do together and what are we not going to do together? Not by listing exhaustive activities but by explicitly discussing the outcomes and interfaces. This should also include agreements on how results and performance will be measured and reported.
- Commercial terms – it’s important to clarify what needs to be paid for a project or service. The starting point is that there should be no debate over the first invoice. Do both parties understand what is included in it (=> scope) and the amounts associated with it?
- Risks – It’s always good to jointly assess the risks of an activity. The goal should be to assign responsibility to the party best capable of mitigating risk, rather than (as often happens) shifting risks to the supplier under commercial pressure, resulting in standard additional costs.
- Governance – What meetings do we have, and who has authority on behalf of both parties for which topics? How do we discuss matters where parties disagree or that are not (yet) covered in the contract? How do we make changes to the contract?
- Exit – What should we do if we want or need to terminate the relationship? This applies both when both parties want it and especially when one party wants it. At any point, it should be crystal clear what the process is and what the (financial) impact is if the relationship ends.
What problem does this solve?
Creating a detailed contract requires a significant upfront investment. Often, it also involves a serious lead time that, in my opinion, could be better spent building trust together (see also => Minimum Viable Relationship). Additionally, starting the project or service earlier also yields results sooner, and the Net Present Value of such acceleration cannot be underestimated. Not least, starting earlier also provides insights sooner, allowing for course corrections.
Course corrections may mean that things need to be added or adjusted in the contract. A good contract is a living document that is periodically evaluated. The need for later adjustments says nothing about the quality of the contract at the outset.
Albert Einstein provided a beautiful definition of ‘minimum viable’ long before the term became popular as part of Agile Software Development. Einstein said about scientific models: “A model should be as simple as possible, but not simpler than that.”
The same applies to a Minimum Viable Contract: it should be as concise as possible, but not more concise than that. I am open to discussions on efforts to strike this balance.
A Dutch version of this article was posted on the website of Sourcing Nederland.
