A large part of a lawyer’s role is helping companies manage legal risk, without slowing things down too much. That means focussing on what matters, but leaving everything else alone.
We’ve spoken before about what that means for creating contract mark-ups.
In this post I want to focus on non-negotiable agreements, e.g when you’re dealing with a larger counterparty or a government customer. In that case, we often create a Red/Amber/Green (RAG) report listing out various issues.
There are lots of frustrations with RAG reports.
The business often feels that RAG reports are growing in length and are a bit pointless, whereas legal teams feel that RAG reports are often ignored and not acted upon.
As a result, they’re not achieving the goal, which is to enable the business to mitigate (or at least be very aware of) the biggest drivers of commercial risk.
Why are RAG reports ignored?
RAG reports that are ignored are often too long (flag too many issues, and some will be irrelevant), contain too much legalese and are sometimes written in a condescending way. Finally, they often contain no practical suggestion in terms of how to solve the problems that are flagged.
The reason for the length is that there’s a baked-in incentive for legal teams to cover all risks quite extensively, to avoid a finger being pointed if something goes wrong.
This is not irrational. After all, if a legal risk materialises, a finger often is pointed at legal. And then being able to show the risk was flagged in a RAG is the only internal protection legal has..
But this is a problem, because all companies need to accept some form of risk. The ideal legal advice focusses on the main drivers of tangible commercial risk, not all theoretical legal risk.
So how to resolve this?
Standardise RAGs
One way to solve this is to have a session with the business where the last 5 RAG reports are taken, and we discuss in the round which risks are the big ones, and which ones are a bit theoretical and will always be accepted.
I find that using a risk matrix like this one is helpful to guide the discussion. If you have historic claims data then that’s worth bringing to the meeting too, as it pinpoints where real loss is currently happening.
The ideal outcome of the meeting is an internal agreement that from now on, only the material risks will be included in RAG reports (i.e. fewer headings). Explicitly document which risk headings will no longer be included in RAG reports, and get all stakeholders to agree on that.
The ideal RAG report tone
Aside from the question of which points are included, the other part is how points are raised. The main culprits are too much legalese in describing the problem, and no practical suggestions to mitigate the risk.
Here’s an example, focussed on negotiating a fixed fee consulting contract (as consultant):
Traditional RAG: "No variation mechanism included to adjust the fee depending on scope changes, this presents a financial risk. This is unacceptable and we recommend this is rejected."
More commercial RAG: "This is a fixed fee contract, where if the work ends up being more complicated we might not be able to charge for that. In the past that has led to us running projects like this at a loss. Given I understand we can’t negotiate the contract wording itself, can we perhaps adjust our pricing structure to cover this risk?"
The second one is much more likely to enable the business to understand the issue and try to do something about it.
How to get your team to adopt this
Ways I’ve gone about this:
RAG Playbooks: For frequently flagged risks, literally spell out how to explain each risk to the business in a RAG playbook. (Tip: you can use our tool LexPlay for this, then your team can just hit ‘insert’ on each common RAG description).
More training: for irregular issues, there’s no substitute to your team actually learning the principles: what does ‘good bedside manner’ look like, how to draft shorter advice, etc. Here’s a post on that, and you can use screen recording videos to save time.
In summary
Aside from helping the business in a big way, creating shorter RAGs also saves your team time. So fixing RAGs truly is a win/win.
Thanks for being here,
Daniel