So What Next…?

Time and time again, I come across businesses that find themselves struggling with their operations after a new system implementation or upgrade.  The project begins with a reasonable objective, to improve the status quo and utilise the implementation of a new system to deliver it.  A working group gets together, creates a wish list, and two or three vendors are selected to showcase how their solution platform will do the best to deliver such wish list.

Unfortunately, failed system implementations are far from rare, and their aftermath can be extremely disruptive to an organisation.  Many of these implementations run over budget, run behind schedule, fail to deliver the expected benefits, and result in employee burnout.

When implementing a new system, there are three key elements that should be clearly identified before a vendor is awarded a contact.

1. It is critical to understand your end-to-end processes and the gaps
2. The timeframe and budget available to implement
3. The capabilities and limitations of your resources and of your new system.

This information should be documented, mapped and be available when validating the vendor’s pitch to deliver the desired outcomes.

So, this is great information to know in hindsight, though what do you do when you are going through the aftermath of a failed implementation…?

By this point you are well aware the implementation did not go to plan – and understanding why it wasn’t successful is your first step in the rehabilitation process.  To do this successfully, you need to step back, and assess the following areas with a clear mind as emotions will cloud your judgement.  In some circumstance, an external partner is best to objectively perform this assessment.

Step One – Identify underperformance in your planning

There are numerous reasons for a failed implementation, though these can be categorised in six main assessment areas.

• Business Case – Did your business case provide the right level of justification for undertaking the implementation? Were there alternate options, and were they explored thoroughly?  Did the benefits, costs and risks clearly identified?
• Business Process and Requirements – Were your business processes clearly identified and documented? What gaps and process opportunities were discovered?  Were the business requirements realistic?
• Technology – What portion of the brief was met by the solution’s standard functionality vs customisation? Did the brief take into account other systems and autonomous integration?  Is your infrastructure suitable?  Did you choose the correct vendor or solution platform?
• Implementation – Communication, planning and transparency are key – what messages and insights were delivered throughout the project? A manager of a section is not always the right subject matter expert. Did you identify who was the expert or process owner?  Did you consult with the right stakeholders?  How did you manage your migration of data?  How much testing did you perform and what did the results tell you?
• Resource Management – Did you have the right people in your project team? Did the project team have the right knowledge or experience to deliver the implementation? Not all businesses have the right talent to deliver such project, often external resources are necessary to achieve the right outcome.
• Change Enablement – Did the project have success obtaining end-user buy-in? How much training and support was provided to your stakeholders?

Once you have identified underperformances in your assessment, only then, by understanding the root causes, recommendations and solutions can be established to form a recovery plan.

Step Two – Identify teething issues or more severe underlying problems

Any change or implementation will experience some issues whether being large or small that will impact an organisation.  It is critical to understand if the business is facing teething issues (short term) or more long-term issues where action to prioritise accordingly is required.  The best option to achieve this goal is to compile a document with a complete analysis, and the recommended direction to move forward, backed up by quantifiable data or metrics.

Assess the short-term (teething issues) and long-term effects on the organisation by looking into each department, business unit or function, and their business processes that are affected by the new system.  This method will enable the organisation to uncover evidence of any bottle necks or operational pain points.  It is very important to keep clear headed as you are going through this process, as the decisions to be made require an evidence-based approach.

Step Three – Learn and Execute

You have reached a point where key findings, evidence and recommendations have been identified and documented.  All of these elements will help inform the organisation which option will yield the best result.  So, what are your options? In this circumstance there are only two, based on the data collected, the organisation can now determine whether the new system can be salvaged or in the worst-case scenario, it should be scrapped.  In some cases, the implementation has failed so spectacularly, where the investment to scrap and start again is the lesser of two evils.   These implementations are in the minority and commonly begin to fail early on, mainly where problems may not have been obvious at time though become apparent once the system goes live.

In most cases, failed implementations can be salvaged, and the assessment will assist the organisation to group the issues into two categories – low hanging fruit and complex issues.  The first category are quick fixes that will alleviate current disruption and improve productivity with minimal effort.  The latter category will have issues that will take longer to rectify and also incur higher costs.

Prioritise your recommendations and also focus on your business processes and organisational change management.  Delivering the low hanging fruit will create momentum that will assist in the implementation of more long-term solutions as time and resources allow.  Throughout this process it is important to learn from the original implementation.  Revisit the list of mistakes often throughout the recovery process.

It can be a long and demanding road to recover from a failed implementation, though it is vital process to recover normality and be able to achieve your original goal – improve the status quo.  Being honest about what made your initial project fail is critical, and don’t be afraid to make internal business process changes in order to leverage the system’s functionality.  But above all, ensure that you are learning from past mistakes to avoid repeating them.