Think Differently, Raise Your Game

Strap in. This is the first in a series of short articles on innovation in the legal, contracting, and commercial space. I want to thank my colleague and guru on CLM systems, Patricia Callejon, for her contribution to this piece. Today, believe it or not, we are talking about the role of storytelling in contract lifecycle management.

Successful Contract Lifecycle Management – the Stories We Could Tell

In the world of business, storytelling is usually associated with sales activity. In the legal industry, there is somewhat of an unsavory air about the practice – frivolous, bereft of rigor, or both. Yet it is fundamental to human culture and is increasingly recognized as a central tool in organizational leadership. If you don’t believe me, just consult on that topic with the greatest publisher of stories the world has ever known: Google.

But there is another angle to consider. Storytelling is something that leaders and organizations do automatically, whether or not they realize it. Sometimes those stories get in the way of progress and good practice. In this article we look at three unhelpful stories that are commonly told in the context of contract lifecycle support.

Story 1: “There’s an App for That”

If you are a connoisseur of clichés, you may know that technology does not usually fix organizational inefficiency on its own. Retired computer enthusiast Bill Gates once said (or repeated) that the “first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency.”

We all know this. And yet technology has become synonymous with innovation in the legal world. At every industry innovation event, a chorus-line of machine acronyms appears on stage: AI (artificial intelligence), RPA (robotic process automation), CLMS (contract lifecycle management system). We hear that many GCs and Chief Legal Officers now feel under pressure to create their legal department’s own technology roadmap, even though they do not quite know which tech applications are going to drive which improvements.

Let’s not misunderstand the story here – technology is a powerful tool. I’m using it right now to write to you. But technology cannot be isolated from the processes that surround it. Inefficiency in, inefficiency out. A fixation on the app – AI, RPA or whatever – risks overlooking half the story that needs to be understood before embarking on an innovation project. This tendency to fixate on the technology has many consequences:

  • The implementation plan ends up being half-baked.
  • The project budget balloons when design meets reality.
  • The user community becomes cynical, fatigued, or just disillusioned when their shiny new toy fails to meet their expectations.

If you are holding a legal technology application in one hand, the other should be holding the process plans. They should be equally heavy.

Story 2: “The More Functionality, the Better”

All-in-one technology platforms have a certain attraction. But that should not be confused with all-you-can-eat (or AYCE, for the acronym collectors hiding in the dark out there). When you want to eat a nice meal, you go to a good restaurant. With all due respect to the hillock-on-a-plate buffet vendors, nobody goes to an AYCE establishment for a quality dining experience.

Of course, the allure of product Max Function is not hard to understand. Buyers have a desire to future-proof the implementation, which an encyclopedic list of tool capabilities hints at. Inevitably, there is the practical temptation of a one-stop shop. But there is also the reality of technology deployments: unplanned scope creep. Some tech vendors use more colorful language. “The buyer becomes power-crazed,” says one sales rep currently languishing in rehab. Over a vitamin mocktail, he tells me, “The client starts with a clearly defined scope that focuses on immediate needs.” He takes a deep breath. “Then they move the goalposts. As stakeholders and users identify the range of possibilities, they start adding new functional requirements.”

The mindset required for LegalTech implementations should be characterized by strategic patience, a willingness to iterate and a focus on measurable business outcomes that can be delivered in a realistic – but ideally, prompt – timeframe. The application will need to be refined and built out over time – implementation cannot be an all-or-nothing, big bang exercise.

And never underestimate the value of delivering quick wins with legal optimization projects. Properly implementing just a few impactful tool capabilities is a far better story than the one about a distant fairy-tale land where every imaginable possibility is within reach.

Story 3: “Change Management is an Important Workstream”

No. Oh no, change management is far more than that. Change management cuts across every area of implementation where people, tech and process intersect, and it affects the likely success of the technical rollout, the program governance, and the executive leadership of the whole project. At the risk of sounding like a yoga instructor, change management is very much a holistic exercise rather than a discrete activity.

I realize that I’m being a little controversial here. Every project plan I’ve ever seen in this industry shows change management as a specific workstream, and to be fair it is hard to represent holistic execution visually without resorting to clouds or Venn diagrams that damage your eyesight. But hear me out.

There is a storyline that says change management is a specific undertaking focused on “people stuff”. The story goes further: corporate management challenges fall broadly into two categories: “hard” ones that are technical in nature (like configuring an IT system), and “soft” ones that are focused on people or HR (like, say, encouraging in-house lawyers to record their time). This dichotomy emerged in management theory during the 1950s and is about as valid today as the idea that women in business should stick to secretarial roles.

Surprisingly, there is relatively little proper science behind much of what is taught about change management. But there has been some research, which does illustrate the weakness of the “people stuff” storyline. One study looked at a big IT-driven transformation project which was running 4 to 6 months behind schedule. Initially, the project leadership blamed the delay on a technical issue: the data that had to be loaded into the new tool were of insufficient volume and quality to drive the reporting system that would in turn launch the second phase of process optimization. But the reason for the poor data was that the user community were not properly interacting with the tool – neglecting to input information when required or doing so incorrectly. This was revealed to be a people problem.

The problem was escalated to executive leadership, whose fury at the avoidable delay to a $50m program turned into some serious “engagement” with the line managers. And here we see that the problem may have been governance, all along. Had top-down engagement been proactive and effective, users would have been loading the data into the system correctly from day one.
Change management is not an important workstream. It is the entire project.

More Innovation Shorts to follow. Next time – What We Have Learned About AI.