Don't be hoodwinked into IT project failure

The vast majority of projects, whether IT or another substantial investment, set off with good intentions, focused on a positive outcome. Most people don't want to think about failure.

However, the software industry or most hi-tech companies assume some projects will fail or not deliver what was expected.

This highlights the risky nature of investing in new areas more than it does any kind of negative connotation, but at the same time gives those sorts of firms a platform for not delivering results from every investment.

Law firms behave somewhat differently. The expectation is that all projects will work, especially IT related ones. As a result, the implications of a failed project are more damaging than in other industries. Yet we see a constant stream of information on failed software projects in law firms.

This information does not come directly from the firms themselves or from vendors, but tends to creep out through investigative journalism and disgruntled ex-employees.

These third-party sources do not undermine the truth, but emphasise the point that firms are not prepared to accept failure on the face of things, and are probably keen to bury stories of failed projects.

If you scour the press you will find a story of a large firm implementing a £5m case management system that, according to the published information, does not work or work well enough.

To those of us dispensing advice to law firms, this is not surprising.

Recently, I advised a charity that had entered into an agreement to buy a software system specific to their industry in line with their requirements.

The value of the initial deal was less than half a million, but once the supplier had started the project, and worked out all the changes they needed to make, they subsequently asked for additional monies in excess of £1m.

Skewed outcomes

More often than not, the requirements element is a major sticking point in these situations. Firms consistently spend too little time and effort putting a requirements specification together, and so when it comes to vetting potential products, it is that much easier for something substandard to pass muster.

Another twist in this is that suppliers often offer to help law firms with their requirements gathering, thus enabling them to skew the outcome significantly. It is surprising how many firms fall into this trap.

Another common scenario is one where a firm undertakes a demo of a system before considering a requirements exercise. This leads to a multitude of difficulties including the belief that a requirements specification is no longer necessary. It's then extremely difficult and sometimes unlikely to analyse other offerings in a competitive way.

The results of a project failure where a system does not match the actual requirements varies from firms dumping products before they are useful to large overspends on getting them to work in the way that the firm does. The latter is all too common.

It serves to embellish the consultant's view that time spent identifying needs and drawing up proper purchase parameters replaces money spent trying to correct problems after a system has been installed.

There is, of course, a practical set of steps to give firms the maximum chance of avoiding this type of stressful and expensive situation.

First, ensure that you have understood your own business case for the system you are looking to purchase.

Next, undertake a comprehensive requirements analysis, and do not be afraid to spend money on external expertise to get this right.

Finally, ensure that the people vetting the products do so against the requirements.

You have much more chance of choosing the right product, more chance of understanding what, if any, changes are required; and assuming you can project manage effectively, more chance of avoiding project failure.

 

FAIL-SAFE Projects often fail because the product is not fit for purpose. Requirements specifications are not undertaken or are too weak. Vendor influence at the start of a process can skew the outcomes. Time spent specifying correctly reduces money spent correcting after the event. Changes to commercial systems need to be decided before purchase.

 

Damian Blackburn is director of legal IT consultancy firm SLFtech