What you’ll get out of this episode

You’ll learn about modular contracts (contracts as connected building blocks)...

...as a technique for making your contracts more productive. Modular contracts can solve a range of problems associated with traditional contract structures especially mid- to high-complexity agreements, by:

making things bite-sized so easier to read and work with;
directing the right content to the right business functions;
allowing multiple templates to be rationalised into a single one;
enabling fast customisation without collateral damage;
sequencing negotiations to secure business priorities and avoid bottlenecks.

The backstory

Old MacDonald had a farm. On that farm, he had a Dog. The Dog lived in its custom accommodation called a kennel, right in front of the farm house. Old MacDonald then started to acquire other animals to build up his farm: Hen, Cow, Horse etc. As each animal was added, it became an intrinsic part of the farm.

Rather than lumping all the animals in one big smelly barn, like many of his neighbours did, Old MacDonald was keen to create an attractive modern farm that was accessible to visitors and easy to manage. So he set aside purpose-built accommodation for each animal, neatly arranged around the farm and connected by a pretty network of gravel paths. When visitors came, they could find their way around easily and see the animals they wanted to see most, in whatever order they preferred. Old MacDonald found it easy to expand his farm and add or limit access to specific animal pens, without creating havoc for the rest of the farm.

The modular contract technique described in this article was developed in real projects, where there was a need to simplify complex agreements and make it easier for business users to create and negotiate them.

What modular contracts are

A modular contract works like Old MacDonald’s farm. It is a way of organising contracts into component parts that has certain advantages over traditional monolithic contracts.

You don’t have to use the term “modules” (I know it sounds a bit tech). Let’s call them Dog, Hen, Cow, Horse, Peacock and Fox.

Modular contracts work as relationship building blocks. Each module has a life of its own, but once additional modules are added, they snap together to form a complete whole:

Modular agreements are an excellent enabler for simplification, template rationalisation and self-serve. The legal team can deploy a single template, from which the business user can select or exclude blocks of content without having to make any adjustments to the rest of the agreement. A modular structure can also be used to move deals forward by dividing up and prioritising the building blocks, without resorting to the uncertainties of LOIs and MoUs.

What modular contracts are not

A modular contract is more than an agreement with schedules (it’s not a barn with adjacent sheds). Neither is it a framework like a master agreement (it’s not a farming development with sub-leased allotments, or a Soviet-style collective farm). It’s more closely interwoven than a set of related agreements like in an M&A transaction (I can come up with amusing analogies here but I’ll let you be creative). Modular contracts have a different purpose to frameworks like master agreements, but the two approaches can be used together to simplify complex structures.

Advantages

Modular contracts can give you some or all of these benefits:

fast customisation (pick-and-choose the modules you want) without having to amend any clauses, cross-references or numbering;
sequence negotiations, for example sign commercial terms to enable a supplier to make initial investments while continuing to negotiate the full supply terms;
easily set up different rules for each module, for example have a commercial module with a fixed duration that gets negotiated periodically, but evergreen general terms of business;
improve consistency and simplify nomenclature, avoiding the usual confusion of schedules, annexes and appendices;
avoid distorted hierarchies where key content (and the people who own it) are treated as appendages of secondary or tertiary importance.

How to make a contract modular

Step 1: divide up the farm

Divide up your template, focusing on relevance and how different users and functions interact with parts of the document. Here’s a scheme for a development agreement as an example:

I encourage a flat rather than hierarchical arrangement (the stuff you’d normally hide away in schedules should be modules in their own right, rather than appendages to modules).

Step 2: arrange the layout of the farm

Arrange the parts in an order that works best, giving priority to what will interest your visitors most (the business and outcomes stuff), with legal risk, generic or optional content at the back. You can apply some structuring magic within each module, for example split modules into legal and technical/commercial parts, or call out key terms upfront in each module.

Step 3: paths and signposts

You will need language which explains that this is a modular agreement and describes the relationship between the modules including what happens when other modules are signed or terminated. Depending on how you intend to use the agreement, you may need to place (or reference) this language at the top of each module. (Hit me up if you want to see some examples).

Step 4: feeding times

Each module can set the rules of how it operates, for example is it fixed term or evergreen or automatically renewable; the timeframe for negotiating other mandatory modules; what happens if other modules terminate or expire.

Here is a procurement agreement example. It’s evergreen but with a front-end commercial module that gets negotiated periodically, so you don’t have to renegotiate the whole set each time:

Step 5: visitors programme and emergency exits

Two key issues to think about: managing pick-and-choose modules, and insurance mechanisms if you are using the modules to sequence negotiations. This is classic lawyering stuff so I’ll touch on it only lightly.

If you let users pick and choose modules, then the user should not have to change, add or remove clauses in other parts of the agreement. Say you have a development agreement with an optional IP licence module; consequences of early termination like revocation of licensed rights, should be in that IP module rather than in your main termination provisions. This way, only relevant content get included, and nothing needs to be added or changed whether you use the license module or not.

If you use the modular structure to sequence negotiations, you’ll need to protect against the risk of negotiation bottlenecks. One insurance mechanism is a set of short-form provisions in your key terms so you always have a legal fall-back. A safer way is give the parties a timeframe to agree and sign key modules, failing which the whole agreement terminates.

And finally…

As with any contract design project, you need to get your stakeholders on board from the start and make sure you have a clear idea of your purpose and outcomes - and follow a structured design methodology (an example from the formidable Verity White here).

Don’t limit yourself to complex agreements - I have found it works really well with simple agreements, so try it out!

Further resources

For complimentary ideas, take a look at Radiant Law’s guide for structuring templates, the IACCM pattern library, and check out my other blogs in this series.

If you want help or suggestions, email me at denis@potemkin.legal. I’d love to hear your thoughts on this method, and any other contract challenges you’d like me to address.

Images credits

Thanks to Carl Holdermass from the Noun Project for the animal wireframes!

Better contracts, Episode 2: Make it modular (the one with Old MacDonald)