Five reasons for ERP Project Delay

Time and cost overruns are the bane of ERP implementations. As per the 2018 ERP Report by Panorama Consulting, 64% of the projects had budget overruns and 79% of the projects were not delivered within schedule. 

In this post I look at schedule overruns. Some of the reasons reported by the customers include Training Issues, Priority Conflicts (I guess ERP implementation was not the top priority for the users), Resource Constraints, Vendor did not deliver in a timely manner, Data Issues, Organizational Issues, Technical Issues, Expanded Project Scope and Unrealistic Project Timeline.

I have implemented many ERP projects. In a recent project meeting, customer asked me a simple question. Based on your experience, what are the reasons for project delay and how will you address them? 

This was an interesting questions. No doubt they have read the report and know the points that I mentioned above. They were expecting my perspective (based on my ERP experience in different roles) on the reasons for the delay. They were probably expecting operational reasons for project delay.

I told them that projects slippage happens over days and hours rather than weeks and months. Couple of days delay in the tasks on the Critical Path can add to the project delay. I told them that there are five reasons why a project gets delayed.

Non-availability of Tools and Templates: A project is built on a set of tools and templates. Templates include the functional design template, the technical design template, test scripts template, issue log template, data conversion templates etc. Tools may include data loader, SQL Loader, data upload and extraction programs etc to name a few. In some cases there may be multiple templates that meet the requirements. For example in Oracle Cloud ERP, there are two different templates to load Customer Master. 

In an ideal project all these tools and templates have to be collated, reviewed by the customer and frozen at the beginning. That doesn't happen. Consultant scrambles to find the template only when the deliverables are due. While the deliverable material may be ready, it gets delayed due to non-availability of templates. 

The reluctance of the consultant to seek help from Product Vendor: I have seen this happen in many implementations. Consultant assumes that any issue encountered is due to some mistake on his part. He is scared that if he seek help, his ignorance may be exposed. Finally when they seek the help from the vendor, they will find that it was a product bug and a patch is available to solve the issue. The delay happens as the consultant experiments and explores the solution to the issue on his own without seeking help. 

Giving equal priority to all requirements: As I mentioned in the post on 4 Layers of Requirements, all requirements are not same. Some of them are important, but mechanical in nature. For example, getting a program to load data into application is, while important, is more of a mechanical exercise. That is not the case with a requirement to configure a complex taxation requirement. The delay happens when consultant do not close the requirements that are mechanical in nature and hence time focus required to analyze and solve complex requirement gets reduced. Customer will not accept the deliverable unless their critical requirements are completely resolved. 

This happens from customer side also. In one of my projects, we spent considerable time on what the customer user told was an 'important requirement'. Since this was a complex requirement, the team spent considerable time to find a solution. On detailed analysis it was found that the number of transactions of that nature were just one per month. We quickly deprioritized this requirement. It is surprising how many times the consultant do not ask the 'volume' question

Lack of closure: Closure is the act of receiving final formal customer acceptance for a deliverable. Many consultants are weak in this area. They consider their task 'closed' when they sent the deliverables to the customer. Having sent that, they fail to follow up with the customer. When they do follow up, they will be presented with a set of customer comments and suggestions. Incorporating these and getting final closure from customer takes time leading to project delay.  

Documentation Paradox: Many consultants think that documentation is an additional task that delays the closure and hence the project. The truth is the opposite. A comprehensive documentation allows the team to move forward. It gets the customer involved early thus getting valuable perspectives. It helps in attrition management and reduces delay in Knowledge Transfer to a new team member. It allows a common view point between the customer and the implementation team enabling them to move together faster etc...

These are my five perspectives. What more can you think of?

 

About the Author

Ramaswamy Krishnamurti (Ram) is a Senior Freelance ERP Project Manager and Solution Architect with over 21 years of experience in all areas of ERP Implementation starting from Product Selection, Vendor Evaluation an Selection, Presales, Implementation, Upgrade and Support and Stabilization. A graduate in Mechanical Engineering from Calicut University in Kerala, India, Ram did his MBA from Kolkata University and Post Graduate Diploma from the prestigious IIM Bangalore.

He has implemented more than 25 highly successful ERP implementations. He has worked on Scala, Peoplesoft, Oracle EBS (11i and R12) and Oracle Fusion Cloud in various roles including CIO, Program Manager, Delivery Manager, Project Manager, Solution Architect, Functional Lead and Consultant. One thing common among all these roles is an average customer satisfaction rating of more than 90% over his over 20 years of ERP Implementation expertise.

In a career spanning more than 30 years, Ram worked in Manufacturing, Academia and ERP Implementation. He has implemented ERP Solution in all business areas including Procurement, Inventory, Manufacturing, Costing, Order Fulfillment, Financials and Budgeting. He has also worked as a CIO of a Food Product Company and has experienced ERP from both sides of the spectrum. Having done many implementations in India, Ram knows India Localization like the back of his hand.

He loves ERP Implementation and the value that it can add to a customer business and the smile on the face of a delighted customer.

He is currently looking out for opportunities. You can download his latest CV from his LinkedIn Profile www.linkedin.com/in/vkramaswamy. He can be contacted on LinkedIn, Email (vkrama01@gmail.com) and Phone (+919880179317)

Work with him for a perfect, on-time ERP Implementation.