Subscribe
About

Twelve tips to avoid software project failure

Denis Bensch, CIO, FlowCentric Technologies.
Denis Bensch, CIO, FlowCentric Technologies.

Business leaders are tired of software implementations that do more harm than good. Many have been burned by big ticket solutions which, even if the technical implementation has gone relatively smoothly, ie, the ‘go-live’ comes in more or less on time and budget – the changes it heralds just don’t stick and the solution doesn’t deliver on its promises.

It’s not only expensive and complex software projects that fail. According to the Standish Group's 2020 CHAOS report, two-thirds of all software projects fail.

But it’s the legion of ERP disasters that usually grab attention as they often result in the loss of millions of dollars and disruption to business operations. Up to 50% of ERP implementations fail the first time around, with 64% of ERP projects going over budget and 30% taking longer than expected.

Denis Bensch, CIO, FlowCentric Technologies, says there are many different ways in which a software project can be deemed a failure. It can, for example, manifest as one in which the implementation is cancelled during its development – often because the company runs out of time or money.

“If the company can’t afford to finish the implementation, they won’t see the full benefits. Similarly, if they are pushed for time and go live too soon, the system could fail to perform or fail to gain user adoption,” he says.

Often, the project is completed but ends up being under-utilised, usually because its features and functions don’t deliver what the business needs or was promised.

And sometimes, failure can occur for reasons beyond the control of the company or the implementor, such as natural or economic disasters such as or 2012's Hurricane Sandy or the COVID-19 pandemic.

Whatever the reason for the failure, the result is inevitably the same – financial and organisational losses.

According to Bensch, the 12 most common reasons for software implementation failures include:

1. Lack of support from top management

Top management must be committed and willing to change the organisation’s culture, including users' habits, in support of the implementation. If sufficient, knowledgeable, decision-empowered users and managers are not dedicated to the project from the beginning, it is unlikely to succeed. Problems can also arise due to turnover in the executive ranks, leading to miscommunication, altered strategies or lack of buy-in from new executives.

“Consultants don’t know the business or the processes and culture well enough to go it alone when it comes to implementing meaningful systems,” Bensch says.

2. No internal champion

A software champion, who may or may not be a member of the top management team, but who feels strongly about the benefits the software will deliver to the company, is key to successfully making changes that stick and maintaining enthusiasm within the business.

3. Software doesn’t fit the needs or culture of the business

This is frequently the result of poor understanding of either the software or the business needs – or both. It often occurs when a comprehensive functional specification (the document that specifies the functions that the system must perform) is not fully reviewed and approved by the relevant parties. Far too many business leaders rely on consultants to tell them what the software can do for their business rather. Instead, they should trust their own understanding of their organisation and use that knowledge to specify what the business needs.

“You don’t need to be an expert on software to be an expert on your business,” Bensch says.

4. Goals are not clearly defined

When the right people are not involved in identifying the goals, or the approach to achieving these goals, the specifications are unlikely to match the company’s requirements. There is also a risk that the messages were “lost in translation” between the client and the implementor; this is why the functional specification document is so critical, it will bring to light any misunderstandings before the implementation begins.

5. Unrealistic timeline

If a timeline for going live is too short, it could mean that not all due diligence and testing is completed, and the software may go live before it is ready or stable.

6. Inability to integrate with existing systems

Integration is key to the longevity of the software solution. Technology and businesses change, and without options, existing systems may need to be replaced. Whereas integration with additional software and/or devices can extend the software’s lifespan.

7. Limited usability testing

When a solution is difficult to use – the result of a challenging interface or simply because it isn’t fit for purpose – this will lead to lack of adoption. Think, for example, of a field mechanic with gloved or greasy hands who is expected to log equipment inspections using a stylus to fill out forms that are better displayed on a desktop computer.

8. Lack of training and change management.

Training and change management do not happen organically. There needs to be a plan for both, which is factored into the roll-out timeline. Having too large a gap between training and using the system can negatively impact enthusiasm for the new system. Additionally, if the timeline is too short, there may not be enough time to inform users of the impending changes or to train them.

9. Unnecessary complexity

Some software systems are complex and the company simply doesn’t need all the bells and whistles, yet is required to pay for this. This results in the system being under-utilised.

10. Poor out-of-the-box fit

The company is either forced to shape its business around the way the software operates or invest in often expensive and laborious customisation to make it fit.

11. Over budget, slow implementation

The company cannot afford to finish the expected implementation because it is more expensive than officially budgeted or is taking too long to go live. If the implementation isn’t finished within the expected timeframe, the business may be forced to use temporary fixes, which often become permanent fixtures in the IT landscape.

12. Lack of support

Lack of support can limit functional use and cause great frustration. Companies may find themselves paying for support from a foreign entity (and be at the mercy of their time zones and fluctuating currencies) or be left trying to figure out how to fix the problem by themselves.

Bottom line

“The bottom line is that due diligence is absolutely critical to the success of any software project. This must be done before any purchase and implementation decisions are made to determine whether the software investment will be useful and useable for the foreseeable future.

“At the same time, it’s important to remember that software isn’t forever. While it may be difficult to predict future events – for example, a natural disaster and the impact this could have on business practices – it is important to at least get some understanding of what the minimum life of the software should be in order to help justify the costs and effort involved,” Bensch concludes. 

Share