Why do IT (or BPM) projects fail?

Last month, we read an article in IT Pro with the headline ‘Failed NHS IT system will cost £7 million to stabilise’. As we read more, it became apparent that 14,600 patient discharge summaries had not been sent to GP's due to an error with a records management system.

As an IT consultancy that works with many NHS Trusts and clinical trial organisations, our first thought was "how did this happen?". Shortly afterwards, we decided to write a blog on how to avoid IT project failure.

At a time when many organisations are undertaking digital transformation projects, why do many IT or BPM projects fail to provide the expected benefits. At ePC, we do not believe they fail (you’d expect us to say that, right?) but, over the years, we have identified a number of red flags that need to be addressed early for projects to be successful.

These red flags can be found during both the planning - and build – phase of an IT project.

Planning an IT project

Was the NHS project destined to fail from the start? Many IT projects will fail to achieve their objectives if the following reasons cannot be overcome.

Poorly written requirements

This one is a particular irritant for Alan, our Technical Director. In fact, it annoys him so much, he wrote to PC Pro Magazine to vent his frustrations.

In his letter, he lamented vendors being given lists of requirements and asked to put a tick against the ones they could do. He went on to say that if a vendor ticked the right boxes and it progressed, more often than not they found out the list of features was created by teams without any real understanding of what technology can offer or how best it can be used to meet the business objectives.

Often, entire departments are created to run tender processes. However, they sit between the users, who know the business requirements, and the vendor who understands how to achieve the objectives with their technology. Unless procurement can simultaneously understand the business and technology, how can they be best placed to ensure the right solution is bought?

Our recommendation is to engage with a few vendors at the outset, rather than ask vendors to simply complete a checklist.

Business process management software (BPMS) is great at taking complex rules and defining processes with them, however those rules have to be outlined and created.

Don’t fret if you haven’t got this written down yet as BPM vendors like ePC can help you identify the processes and map out the steps, rules and users.

Trying to implement company-wide change too soon

We often find successful implementations start with the ‘low hanging fruit’ or smaller departmental processes. This not only delivers a quicker win but also reduces risk and allows for a more agile approach during the early stages of adoption. An example of this approach is Rentokil Initial, the global pest control and hygiene services provider, who automated their capital expenditure request approval process first and subsequently rolled out the technology to additional business functions.

Trying to implement organisation-wide BPM is much harder as there are competing requirements (and personalities!) and the project quickly become too big. Similarly, introducing an overnight change to your day-to-day operations is likely to result in problems with users failing to adopt technology as part of their normal working behaviour. If you introduce BPM incrementally, you empower to early adopters to act as champions and transfer knowledge as the roll-out continues.

Not involving vendors at the earliest possible opportunity

Alan concluded his letter to PC Pro Magazine by suggesting customers engage with vendors early to plan a better solution.

That's sound advice as, if you’re planning to implement an IT project, it is always best to discuss your requirements as soon as possible. Often labelled ‘early market engagement’ in the public sector, it helps both the company and vendors to:

• Understand your requirements better
• Impart knowledge on the technical solutions available
• Understand how much the work could cost
• Understand how long the work could take
• Identify and mitigate any potential pitfalls sooner
• Write a better business case for spending controls or internal approval

Building an IT project

The planning phase has concluded. You identified a single process to act as a pilot and consulted vendors early. Crucially, the project specification is comprehensive and outlines what is required, how long it will take and what the cost will be.

However, the project is still vulnerable and alarm bells should start ringing if the project is experiencing any of the following.

Poor communication

A lack of communication between internal teams and stakeholders is often the root cause of IT failures with organisational culture blamed.

This can easily be avoided if you establish teams with roles and responsibilities and clear lines of communication. Typically, the person responsible for communication is the project manager. This person should foster knowledge sharing and information exchange.

But it is not just about using well-meaning communication techniques; one of the best things you can do to prevent communication issues is to reduce the number of participants communicating. The vendor should offer a single point of contact and unless absolutely necessary, so should you. With the responsibility of being the single point of contact needs to come the autonomy to get the job done. This way they can contact the relevant sub-teams as needed, rather than bringing them into every planning discussion.

Weak project management

The project manager (and one or two other stakeholders) are key to the success (or failure) of a project. If these people leave the business, or move to another business area, the project invariably suffers the consequences.

Our most successful customers have a process champion who, as we saw earlier, champions the first process as a “proof of concept” by breaking the workflow up into small, bite-sized chunks and introducing them by department or user group. More often than not, these “champions” are business users, involved with the day-to-day of the processes, rather than business analysts or IT people. Although support from IT will be important, it is the front-line users that are using the process, not IT, so they are often best placed to ensure the implementation is a success.

Finally, a good BPM vendor will work with the client to ensure information is forthcoming or actions are completed to meet timescales. They will also not be afraid to challenge the ‘status quo’ and tell the client if something is a bad idea.

Limited (or no) user acceptance testing

If a project is behind schedule, time booked for user acceptance testing (UAT) is often reduced or cancelled. With only 37% of teams in the UK completing projects on time, the potential exists for post-live problems due to limited UAT.

Our typical approach is to have a defined period of development followed by at least two rounds of testing, with any fixes and additional development scheduled in between.

Not establishing metrics to monitor, refine and improve the processes

From the outset, you should give serious thought to the results you are currently achieving - and what you want your digital transformation project to achieve. However, many organisations do not think about the improvements they will see, and subsequently fail to measure whether or not they are achieving them.

Some examples of key metrics include:

• Are projects being accomplished faster?
• Did you eliminate time-consuming steps?
• How many active processes are there at any one time?
• How long does the longest and shortest of processes take?
• How long does the average process take?

BPM solutions like BP Logix Process Director allow users to present key metrics in flexible reports, graphs and dashboards - without the assistance of IT.

Conclusion

Digital projects are happening at pace and high-profile examples of IT failures, like the NHS IT system, may become more common in the future. Involving vendors early, assembling the right team, focusing on smaller processes and testing extensively will give you a much better chance of success.

If you're currently planning (or building) a digital application and recognise one or more of the above, it might be advisable to consider an alternative solution or supplier.

If you want to learn more about ePC and our services, please contact us.