As far as I am aware no-one has ever died or gotten seriously injured from a failed ERP project, so maybe my analogy probably isn’t absolutely accurate, but let me explain my point. In my 20 years plus of implementing ERP systems, I have seen my fair share of failed and successful projects. The reason why I compare failed ERP projects to airplane crashes is that very often more than one thing needs to go wrong for a disaster to occur. One problem is not going to noise-dive the project, but two of them may; three certainly will. So what are the problems, I am talking about? In the following text, I will reiterate some of the problems, I have seen in the past. There are certainly more problems and issues out there, but these seem to challenge many projects. So here goes…
Misrepresentation is a concept in contract law referring to a false statement of fact made by one party to another party, which has the effect of inducing that party into the contract.
The above quote is the definition of misrepresentation on Wikipedia. Basically, a lot of ERP projects get sold on false promises both in terms of product capability and the systems integrators’ consulting capability and industry insight. I think we can all think of a few projects where misrepresentation played a part in the project failure, but the good question is; how do we avoid it? The answer does not seem to lie with the “independent” advisor and RFx. I do certainly not have a clear answer to this, but I would strongly encourage prospective buyers to
- thoroughly investigate the references given by the systems integrator.
- take independent references through one’s own network (if possible).
- conduct some proof-of-concept workshops with the preferred systems integrator to ascertain their product knowledge and the suitability of the product.
- hire people with the professional skills to buy the services you need.
What Did We Agree?
Once the right product and the right systems integrator have been selected, it is time to set up the agreement. I cannot count the number of times I have seen projects started without a project charter, without an agreed scope and without documented criteria on which the project can be signed-off. Why anyone would want to start the project before it has been agreed how to end it, beats me. Often, people think that we can get the agreement done sometime soon, but in my experience one thing leads to another and the further you get into the project, the less likely you are to get the agreement sorted out. The remedy with the problem is simple: do not start the project until the agreement has been signed and sealed!
Lust for Action!
Many times in my career, I have been asked the following question from prospective clients: “when can we start configuring the system; we need to get our hands on the software”. If major buildings were built with this approach, we might have high-rise tower blocks come down more often (as they seem to do in Hong Kong every once in a while). In my view, the last thing you should do, is start cracking on with the software. Instead, plan your project carefully, set your objectives, agree your architectural principles and then you are ready – not to start cracking, but start doing prototypes and proof-of-concept workshops to validate your plan, objectives and principles. Once that is done, you have a solution blueprint. From the solution blueprint, development and deployment should be easy-peasy mechanical stuff and not the great adventure of exploration that many ERP projects seem to turn into.
Inadequate budgets are not a reason in itself, why projects fail. After all, all you have to do is raise the budget, but this is where the catch is. This problem, to a degree, points back to my earlier point on misrepresentation. If a client only has a limited budget and the systems integrator deliberately “undersells” the true cost of implementation, you are asking for trouble. Maybe the client is working to an internal business case that only makes sense, if the promised cost is not exceeded, maybe the person you are dealing with has his or her bonus on the line, maybe the trust between client and systems integrator is lost (for good), if the you go way over budget. No matter the reason, if you go massively over budget, the project is (most of times) deemed a failure. As a client, you should ask other people in your network what their ERP projects have costs, or use any other source of independent advise on the true cost of ERP projects.
Lack of Leadership
In many projects, the leaders from both sides take part in the kick-off and then disappear for quite some time. The best projects I have worked on have always had direct attention from the leadership team. This ensures that the project gets the focus and attention it needs and deserves. I have always found it interesting if a leadership team are not taking a keen interest in a project with a potential high impact on most of the things a company does. Get senior management involved and get them to understand that their strategies and targets are a risk, if the project is not successful.
Sticking to Principles
Being a solution architect myself, I might be slightly biased here, but I have seen quite a number of projects result in miserable solutions because we did not stick to our architectural principles. The key objective of the solution architect is to design an overarching architecture that delivers a solution that works across business units, process and system boundaries. The solution delivered should also be maintainable in future, so often compromising on architectural principles is only a short-term fix to meet an (artificial) deadline. I often ask, if TCO is only important in the sales phase…?
Unwilling to Take Ownership
I have, I am sorry to say, seen a lot of clients unwilling to take ownership of their own implementations. Once the agreement has been signed, they turn to the systems integrator and say: “OK, so get on with it and tell what we need to do – it is your problem now”. In my experience, implementations only succeed, if the client is willing to accept their share of the risk and responsibility and act as if their company depended on it; it actually does!
RISK RISK RISK
Lastly, people in projects worry a lot about plans, requirements, features, servers etc. In fact what they should be worrying about is RISK. If a project manager manages his or her project by focusing on risk identification and mitigation I am pretty sure, that the steering group would feel well-informed and able to act in time before issues became real problems. Try it – it might work! The risk assessment is the simplest tool in the project management toolbox, but it makes such a difference when used by a professional.
As I started this blog post by saying, each one of the above problems, may not turn a project into a failure, but I am pretty sure two of them together would. Do you recognise these problems and are you able to avoid them? After 20 years, I think I can finally say, that I have the experience to recognise the symptoms when I see them, but being part of the systems integrator-client-project fabric, avoiding them is quite a lot harder. Here’s to hoping…