CLM – Contract Lifecyle Management or a Career Limiting Move – Part One
The Association of Corporate Counsel 2021 survey of Chief Legal Officers (CLO) has recently been released and gives us some indications of what corporate clients actually want to buy in terms of legal tech over the next two years. The very top ranking at 67% is contract management.
This certainly accords with the Hyperscale Group experience – we have been instructed on a number of mandates in this space both globally and in the UK. For many years in house legal teams have wanted to “show value” and contract management is key to this. It goes to both the top and bottom line. Every penny of income and expenditure is governed by contracts. If in house teams optimise this process the benefits they can bring to their organisations are enormous. If you have a turnover of £30bn per annum a 1% improvement equates to £300mil, which by any measure helps to demonstrate a legal function’s contribution. 1% is almost certainly very conservative when you listen to the challenges of some clients.
Notwithstanding the potential when we go into organisations, we often see a graveyard of failed contract management projects. All too frequently people don’t think they have a system or realise the number of systems they have and often these are suboptimal, with poor levels of adoption. The people or consultants who have put these systems in place have “left the premises”. In fairness, these projects can deliver huge rewards but the potential to get them wrong is high, and people don’t tend to hang around to live with their mistakes.
In this article, we will set out 10 key rules to abide by:
This sounds obvious but we have seldom come across technology projects where the objective is so key and where it is vital to success.
The problem is that contract management can mean very different things to different people. Sometimes this is based on the perception of a siloed need or what people have seen previously; sometimes it’s based on what people imagine such a system will do. Different teams have a different field of vision and struggle with different pain points. It is vital to get everyone on the same page. Recently we saw two lawyers come into a meeting with a documented objective and specification which they both believed. Within 5 minutes it became apparent that one wanted a simple database to store contracts, whereas the other wanted a sophisticated AI data extraction and predictive analytics tool. Their objective and specification said neither of these, and we already knew the IT Department wanted something else. There was no malice from anyone; they simply had different perceptions and views of what great would look like. To bring an effective solution involves listening and spending time with people to educate them about what is realistically possible, what other organisations are doing and the limitations of the products. Often there is a view that there will be one fantastic product that they want to get their hands on, but there are pros and cons of every product and seldom is there one that ticks every box. To state the obvious business-focussed objectives which reference results and outputs rather than feature-based objectives tend to set these projects up for success.
Contract Management is a slightly strange area where often years have gone by between attempted implementations. Frequently organisations can be dissatisfied with their contract management, but it is seen as such a large area to tackle whilst there are other priorities that nothing is done. What then can happen is that one person tries to improve things and a range of stakeholders suddenly appear from nowhere.
We have mapped at least 10 categories of stakeholder in any organisation. They each have very legitimate and different views on what is needed, and each has its own legacy and pain points. Thankfully, we are often able to get people onto the same page but without care, turf wars can break out and there can be lobbying to rekindle unsuitable platforms. It is one of those areas where we need to remember the expression “sphere of vision and experience”, everyone will have a different view and need, and everyone is correct.
The winning strategy is to listen, understand and harmonise and not to browbeat anyone into submission, but at the same time to avoid the “Homer Simpson’s car” scenario, where requirement after requirement is added to the list. Everyone needs to avoid confusing action with progress. “Doing is easy” but doing the right things is a lot harder. The latter involves much greater levels of engagement.
Sometimes we see people who are really invested in particular technologies. There is a need to understand and support them on their journey and to acknowledge that even though having a single system or process may sound great, in reality, that may not be the best result. In the end, it may be about compromise: one person’s views or ego cannot be allowed to stand in the way of £300m of savings. Every working day amounts to a run rate of £1.1mil of lost opportunity.
3. Operating Model
Any project inevitably requires us to stand back and work out what work needs to be done by whom, how to optimise processes, engagement and demand management models, self-service and gateways, as well as the use of lower-cost centres and ALSPs. It takes us into the territory of working out long term operational objectives, when negotiating a contract with a key customer what information do you need to achieve the best commercial outcome? If this requires AI and data analytics where will your contracts be stored? Will you have one operating model or will it be streamed into several swim lanes, each with different process owners and technologies? Most projects involve organisational change and the more workflow that is introduced the greater potential to deskill. If there is to be change then to deliver success will almost certainly need great organisational change, communication and change management.
I am not saying these projects need to be complex, they don’t. I am saying that almost all of these projects involve flexing or completely changing the operating model and who does what work. Contract Management is not about point solutions and simply buying a system. It needs thought and intelligent discussion to succeed and deliver the full potential for an organisation.
In looking at operating platforms it is key to understand both the needs and the target architecture necessary to meet the needs of multiple stakeholders. Some areas may need “database” type functionality, others may have core systems that help them but lack automation or incoming playbook functionality. Others may be perfect cases for no-code systems which can easily be configured with gateways, dashboards and strong API’s to link with other systems. The latter is particularly important, for instance, to take data feeds from ERP systems into playbook systems in order to assist in reviewing incoming documents. This is not an area where “one size fits all” and more than one system may provide an appropriate solution providing you have a common data structure, people are clear what work is done in what way, and you have amalgamated dashboards and reporting.
Whatever structure you adopt, long term it is desirable to be able to access final versions of all contracts in a structured fashion and machine-readable format to enable the intelligent use of AI. Even if you feel you don’t need this now you will in the future.
One typical challenge with CLM projects is data and volumes. Ideally, when looking at these projects you have a clear view of what volumes of what contracts you have of what type and in every jurisdiction. You will have a good perspective on the risk profile of each. The above will inform your business plan and ROI. It will also help you determine your optimal operational model. Sadly, most corporates do not have this data or if they do it is in disparate systems. There are lots of issues that flow from this. Proceeding in ignorance is a big mistake and can be like flying a plane in fog across a mountain range without instruments. Often it is possible to mitigate this. In the short-term sample analysis and cross-referencing from finance system/departmental data can help, but if not it is vital that the steps you take and the systems you implement do provide this information at a key milestone in the future. Dashboard design is key. Berating your client for simply not having the data is unhelpful; you need to be part of the solution.
Sadly, all too often legacy is an afterthought. There can be three principal issues:
a) people think about solutions to deal with their current issues and do not address their minds to the rich seams of information and data already held;
b) even if they do think about this area they underestimate things and are not aware of the huge amounts of information already held by their businesses in different historical systems and discover this as the project proceeds;
c) projects become too big to deal with. There is a huge difference between implementing a point solution and putting in place a new enterprise system that meets the organisation’s entire needs and at the same time migrates and cleanses all legacy data. Often people don’t have the appetite or budget to deal with this and so compromise is forced upon them.
Part 2 of this article will be issued later this week.