Mind the gap: why business analysis is not technical analysis

Change management is a term that rings hollow in the legal technology sphere. Despite the importance awarded to such initiatives, they are not only executed with remarkable inconsistency, they also often fail, as many technology programs fall short of delivering meaningful business transformation and return on investment. 

Why? The cause potentially lies in conflating technical analysis with business analysis. These are different disciplines, yet organisations treat them as interchangeable. Arguably, this is a fundamental error that undermines transformation efforts and prevents law firms from unlocking the full benefits of the technology they’ve purchased.

A Make-or-Break Step

Now that a significant number of law firms run many of their key systems in the cloud rather than on-premises, ‘the technical bits’ of those systems typically just work. There might be a small degree of configuration involved, but for the most part, and data migrations notwithstanding, the ‘technology aspect’ has been tamed. 

Given the technical bits are mostly all sorted out, the focus has turned to figuring out how to get people to execute with the technology and deliver meaningful results. However, this is difficult to do if a firm hasn’t conducted a rigorous business analysis around their technology purchases, right at the outset. 

This business analysis should ask fundamental questions like: What are we actually hoping to achieve with this new technology we’re purchasing? Are we trying to drive revenue? Reduce costs? Come up with new service offerings? Something else? For that matter, who are the key stakeholders that this impacts? What workflows are changing?

Firms need to start here. Then, they should look at where the business sits today, and where they want it to be in terms of the goals identified. Examining the difference between those two states is a gap analysis – and once that gap analysis is done, firms can start executing against their goals. 

Without that upfront business analysis, though, change management efforts will fall flat on their face.

The bigger picture matters

While stakeholder analysis and workflow analysis are key parts of any business analysis, there are a couple other essential components: key performance indicators (KPIs) and an overarching goal. 

The importance of KPIs is fairly straightforward – developing KPIs can let members of the firm know whether they are moving towards their identified goal or not, which greatly aids the change management process. 

The importance of an overarching goal is less immediately intuitive – but without this crucial ingredient, successful technology adoption can be hit-or-miss, because people don't have any larger context for how this piece of technology and the workflows it enables is going to help the business.

Take the example of a document management system that has a feature that securely sends documents to the clients of the law firm. The alternative to using this tool is to simply email the client the document as an attachment – but that method of transmission creates serious potential security vulnerabilities for the firm and the client.

Presenting the lawyer with additional context of how this technological capability connects to a larger business imperative helps make adoption of that feature more compelling. This starts by explaining this feature isn’t just a matter of convenience or an easier way to send a file: it safeguards the entire firm and the reputation of the firm. 

Then, connect this technological capability to a specific overarching goal: perhaps the firm has identified that as part of their security posture mandate for the upcoming year, they need 100 percent accountability for all documents that are shared outside of their walls and a way of ensuring any document sent outside of their system is being received by its intended recipient and no one else. This larger overarching goal makes it clear to the end user why they need to adopt the technology.

The bottom line? If users don’t think that the technology or suggested workflow is important to the firm as a whole, their behaviors won't change. It’s up to firms to ‘connect the dots’ for them and spell out why it matters at an organisational level.

Technology lens vs. business lens

A quick word here on selecting technology. It’s not uncommon for a technology committee within a law firm to nominate a technology platform for adoption. More often than not, though, they’re looking at the system through a technological lens: does the system have a certain feature? Is it available in the cloud? Does it tick the box on certain security requirements?

In my experience, those committee members are mainly focused on the technological requirements and their associated legal obligations, and how new technologies will improve user experience and drive productivity. To be clear, the committee’s role is vital to a thriving legal operation. Their output and guidance typically fall short of business analysis, however. 

Without proper business analysis, even committee-approved technology adoption can stall out, and change management efforts can fail. Once that happens, it's extraordinarily difficult to ‘hit the reset button’ and try to reintroduce the technology — users already have a fixed impression of the technology in their minds, and it’s not a favourable one.

This is a situation where an ounce of prevention (in the form of upfront business analysis) is more than worth a pound of cure.

Don’t fear the data

What about metrics? Should law firms be paying attention to things like usage numbers around the newly deployed technology?

Not necessarily. Success with technology isn’t about compelling people to use each and every feature or hitting some arbitrary usage metrics. What really matters is whether the software is delivering on its purpose. Is it fulfilling the business goals that drove its purchase in the first place? Metrics like user logins, file uploads, or file downloads may look good on paper, but they don't guarantee business results. 

Far better to look at other numbers – and a significant challenge here lies in helping employees embrace data to help guide the way. There are some legal professionals that are highly skilled at working with data, and there are some professionals who put it in the same category as kryptonite: they don’t want to be anywhere near it. They loathe the idea of being data-driven. 

The biggest challenge they have to overcome is a mindset one. They think they have to be a master statistician to be data-driven, and that’s just not the case. ‘Collecting data’ is just collecting evidence and presenting it in a way that other people can digest. 

So, go forth and identify indicators of success and then collect the evidence. Are processes faster? Is the business improving? Are revenues up? Without diagnosis backed by data, you’re simply guessing—and that’s a risk no organisation can afford.

The key takeaway here is while success with technology might start with a clear business purpose, there needs to be a willingness to embrace and analyze the facts as the technology is introduced to the organisation. Only then can you truly bridge the gap between potential and results.

So what impedes business analysis in some legal operations? Simply put, most people don’t understand what it is and how it drives success, and they don’t know where to start. Quite often, they would rather implement the tech and hope for the best. 

Understand the Difference

Legal professionals are busy people. In most law firms, the Chief Information Officer (CIO) wants to focus on technology, and the lawyers want to focus on lawyering, which is fully understandable. However, when it comes to introducing new technology into the firm, there needs to be business analysis, not just technical analysis. 

For firms of any size, understanding the difference between the two is a critical step that helps put their technology adoption on a path to success and ultimately delivers the business outcomes they seek. Relying on technical analysis alone is a recipe for disappointment.