So the project has gone belly-up, what now? – An ERP insights post

Back in May of 2015, I published “When ERP projects go wrong” which was the 3rd in my ERP insights series. This was by far the most read of my posts, suggesting that it struck a chord with the Owners, Directors and CEO’s in the Small & Medium Enterprise (SME) space I write for. Having identified what, I believe to be the common causes of the problem, logic suggests that I should now turn my attention to the recovery process.

Here’s a recap of the 5 common causes of a rogue ERP project:

1. Lack of clarity of the objective
2. Lack of ownership
3. Lack of proper resourcing
4. Scope creep
5. Ineffective change management

In defining your Implementation Project Recovery Plan, there are some basic steps that will help you get the outcome you need.

Step 1 – What went wrong?

This is going to be painful so get used to that idea from the beginning. In determining where the project went off the rails it will be necessary to look at the facts objectively and dispassionately. It is entirely possible that you, or one of your trusted staff has dropped the ball. If that is what has happened, it needs to be recognised and rectified and egos may well be collateral damage along the way. Be sensitive but also decisive.

Often in the SME space, during the project establishment phase we see the same risks emerge;

• There is no business case or benefits realisation plan for the project.
• There is little understanding of the roles and responsibilities of the internal project team and most importantly the roles and responsibilities of the internal project manager.

There is often a misconception that because they are paying the vendor for project management, the vendor has full control over the success of the project. In reality the vendor’s project manager has little or no control over the project activity carried out by your staff.

Regardless of what you identify as the root cause or causes (it is unlikely to be only one) for the project to go off the rails, there will always be one additional item on the recovery plan and that is the rebuilding of trust in the solution and the project.

Step 2 – Do you have the right team?

Having identified what went wrong, the next step is to ensure that you have the right team in place to remedy the situation. The harsh reality is that you are in this position because of a management failure in the project. Loosely translated that means:

• the wrong person was running the project, or
• they were not given sufficient authority to execute the plan, or
• there was insufficient senior sponsorship to make it happen, or
• in the worst case, there was no internal Project Manager.

Doing the same things with the same people will deliver the same result, this time with more destruction of motivation and good-will for change. You will need clarity on:

• Who owns the project within your company?
• Do they fully understand that they own it?
• Do they have the authority to own it?
• Does everyone else know that they own it?
• What does the Vendor think about the project? Remember, they are no happier about it failing than you are. Do you know what their proposed solution is?
• Have you used the Vendor enough?
• Have you been overly dependent on the Vendor?
• Do you have all the required skills available?
• If not, where can you acquire them in such a way that you retain them going forward.

Be ready to back your people who need to be supported and change the people who need to be changed.

Step 3 – Focus on the outcome

It is time to review the goals of the project, or at least the first phase. I am personally not an advocate of a big-bang approach to a project like an ERP implementation. Few companies in the SME space have the spare capacity to dedicate sufficient internal resources to go from not much to everything in one step, yet many attempt it. Break the project down into logical and discrete phases that can be implemented in sequence, delivering an outcome as each phase is completed. While good process is very important it is only the means to the end. Your goal is the outcome; not the process.

Step 4 – Scope and deadlines

There are four variables in any project, Scope, Timeframe, Resources and Quality. If one or more of them are fixed for any reason, then you need flexibility on the remaining elements to ensure success. Add to this the fact that scope creep is the most significant single source of ERP projects going over time and over budget and you start to see the importance of actively managing the project, and not just the scope.

Some questions to ask include:

• Has the project scope changed since the project was commenced?
• Have all those changes been documented and costed?
• Is there an approved business case supporting each variation?
• Do the variations address critical business issues, or are they driven by resistance to change?
• What are the essential elements for a Phase 1 completion and what can go into a subsequent phase?
• How much time do you really need to complete Phase 1?
• What is the cost and impact of getting it wrong?

There is an important psychology to seeing goals being achieved and the more wins you can line up on the way to achieving an outcome the more motivated your team will be.

Step 5 – Other considerations

Others in our industry have suggested that the suitability of the software should also be reviewed at this point. In rare situations this may be necessary but generally this will just divert you from focusing on the real issues which are most scope and/or project management related.

If, however you have reasonable grounds to believe that the software you have selected is genuinely not fit for purpose then you need to work this out sooner rather than later. If you come to this conclusion, your problems started back in the selection process so it may be of value to also read my article on the 5 most common ERP selection errors made.

The root cause will come down to one of:

• Your selection process failed to identify all the critical business processes that were essential to how your company operates; or
• Your chosen vendor has glossed over some aspect of their solution where their functionality was not as you had anticipated.

In saying this, I also know that how a function is performed is as important as the fact the function can be performed by the software. It is entirely possible that your chosen software does what you want done, just not in the way you want it done. In this case the vendor has not been deceptive, but you are still not getting what you want or need. The choices here will boil down to either a willingness to do some business process reengineering, a willingness to customise the software, or a decision to start again, with all that entails. For my money, the preferred option should always be to exhaust process reform, before you look to customise or replace software.  In reality, you will do some of both.

Final thoughts

Most SMEs and many larger companies are not experienced in running projects. It is just not something they need to do on a regular basis and certainly not with this much at stake.  An investment in the services of a skilled internal Project Manager is rarely a waste of money. It will often cost you more to skimp in this area and then have to recover afterwards.

Remember the two great enemies of a successful project. Scope creep and resistance to change, they will bite you every time and they can both be mitigated by effective Project Management.