Reasons for ERP Software project delays

ERP Implementation

ERP Implementation

Evidence suggests that majority of ERP software projects are delayed or doomed by cost overturns.  Even when ERP projects are completed on time or within budget, users often complain that the software they have paid for does not meet their expectations in terms of quality, or features or both.

In other words, a great deal of software that is developed never gains user acceptance.  No respectable field of engineering has comparable failure.  That would be a catastrophe, and construction and automotive engineers would not make a living!

  • Why does the distinguished software industry have such an abysmal track record? A big part of the answer is ‘scope definition’, a phenomenon that causes users to be highly inconsistent and unpredictable, about what they wish their software to do. Experienced software engineers often say that users are notorious for their inability to clearly articulate their expectations from software. As a result, it is alarmingly common for the development (construction) of software applications to begin with insufficient requirements and ambiguous specifications.
  • ERP project is taken as ‘by-the-way’ project whereas in true sense it should be the only priority during implementation phase.
  • And because software is intangible (impossible to see and touch) while it is under development (unlike other forms of construction such as bridges and cars), it is commonplace for needs to keep evolving as the software gets built. With every round of change and clarification. The scope of the project changes (as earlier assumptions are negated and new ones introduced). And timelines are pushed out to accommodate new expectations. This is analogous to building a house for which the architectural design keeps shifting with the changing priorities of the owners. Human experience suggests that moving-targets do not lend themselves to happy outcomes. And so it is with the timelines and budgets of numerous ERP projects.
  • Untreatable as it may seem on the surface, scope creep (changes) is an eminently treatable problem. For example, world-class ERP organizations now employ the use case method to manage user requirements. Instead of asking users what features they want in their software, the user case method guides them to describe their current and future processes and behaviors in terms of stories and scripts (much like playwrights write plays) that are stuffed with actors, actions and entity. It turns out that humans are fundamentally better at narration than specification, and the requirements that originate from this method are decidedly more robust.
  • Further, the software implementation and development process has itself become less linear and more cyclical. These days, large ERP projects are broken down into a series of short, burst sprints that last between 30-60 days each.  Sometime, module wise implementation helps building up confidence.
  • Only a small set of requirements are addressed in each sprint, and no changes in scope are permitted while a sprint is progress. Finally, users themselves play an active role in software evolution. As each iterative cycle draws to a close, representative users (or focus groups) interact with the ‘live’ (albeit partially complete) system, and provide critical feedback. The feedback is analyzed, course corrections engineered, and scope creep managed in a controlled fashion.
  • Software engineers are devising early warning systems that will allow them to predict well in advance how serious the downstream effects of unmanaged scope creep can be. An innovative measure that is gaining currency is the requirements clarity indicator, a metric that allows a panel of software experts to review a set of project requirements early in the life-cycle and determine how well the stakeholders even understand what they want from their stability indicator. Low scores on requirements clarity or requirement stability ought to be sufficient to assume that a project is headed for serious trouble.
  • In conclusion, scope creep remains a major threat to the success of every software project.

However, its impact can be minimized by leveraging best practices that are part of the emerging repertoire of leading IT organizations. Good software engineering is all about deciphering what users need, and not getting distracted by what they demand. It is also about managing scope creep intelligently. Use cases, iterative sprints, task group feedback, as well as indicators that measure requirements clarity and stability allow modern software engineers to do just that.

Above write-up is based on Jyoti Zaveri’s experience of software development and software projects implementation experience.

ERP Lecture in Germany

ERP Lecture in Germany by Zaveri

International Faculty

I am glad to inform you that I was invited to give a lecture on the subject of ERP in Germany.  It was a great experience to discuss with German students.

Here are the glimpse of the ERP lecture:

The presentation that I used for my lecture at the university is also published on this blog.  Here is the link  https://dnserp.wordpress.com/erp-presentation-32-erp-modules

I will appreciate your feedback.  If you Like it Share it.

Replacing ERP Software?

Are you planning to change your ERP vendor?

ERP Implementation tips

ERP Implementation tips

Replacing system management software is like visiting a medical clinic for injection, painful but necessary.  First, try to get upgraded version if any, from your existing ERP vendor.  Probably this means more investment, but worth considering.  Once you rule out this option, and decide to look for new ERP software, consider the following points:

  1. Once again define the new requirements, this time make a function wise list.  For instance, accounts, material, sales, and so on.  It is important to do the ABC analysis, A essential list, and C is wish list.  Remember if everything is A, you will have to pay for the customization, so let go of some point as wish list.  Share the list with the new ERP vendors, and try to match.  Here the trusting the new ERP partner is important that you want the truth.
  2.   Do some business process improvements.  Do not (do not, no this is not a spelling mistake, just to emphasise) automate without improving your existing methods.  Chances are you will automate the mistakes; this means ERP will do mistakes faster.  This exercise is called BPR (business process re-engineering).  All the problems with the existing system are in fact opportunities for improvement.  Ensure that you are aware of the issues, and that the new ERP software system will help resolve them.  Learn more about BPR here  http://www.dnserp.com/b__p__r_.htm.
    Do some BPR before ERP

    Do some BPR before ERP

  3. Stay focused in defining the scope.  Module wise write down master, transactions, and reports.  Again, do ABC analysis of the same.  See sample scope given here http://www.dnserp.com/dns_scope.htm.  FAQ: Can I change the scope?  Ans: Yes, but after discussing with the ERP supplier and before starting to implement.
  4. Select your task force.  Motivate them, yes allocate a budget.  Offer incentive.  Involve key people at the start.  Write important milestones.
  5. Size of the ERP company is not that important, small or big, what is important is how important it is for them to make your ERP a success.
  6. Arrange for a demo with your own inputs and try to match the report – at this stage without customization.  About eighty percent of your requirements should be met.  So prepare your own data to input for the demo run.
  7. Brainstorm with your senior management to identify potential reasons of failure, and take steps to guard the same to reduce risk.
  8. Assign one (or better two) main ERP coordinator/s, dedicated resource/s.  Consult domain expert and other consultants such as tax, ISO, 6-sigma, etc.  Ensure their valuable time is available.  Study http://www.dnserp.com/implement_erp.htm.
  9. While evaluating make sure the implementer/s are also interviewed and their time is committed.
  10. ERP implementer and ERP coordinator team should have project management skill.  Ask ERP vendor to show their track record of other similar size ERP success story, I mean show the document that was used to track ERP project management in the past.

Hope you will find this ERP tips useful and will share with others, by using the social icons given below.  Let us know your comments, add point that we might have missed out, your feed back will be appreciated. 

%d bloggers like this: