•   Evidence suggests that majority of ERP software projects fail, doomed by cost and time 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 automobile 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.  In company, the ERP coordinator was asked (by the Executive Director himself), to go to Kolhapur to get the Diwali Greetings printed.  So, his priorities are different.

•  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. 

•   Even with advanced techniques and best practices at our disposal, scope creep can at best be contained, not eliminated. In fact, scope creep is as natural to software engineering as bad weather is to seafaring. It is a professional hazard that professionals in the field must learn how to manage. As the IT professional is maturing. 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 lifecycle 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 our experience of software development and software projects implementation experience and an article published in the Economic Times.

Why ERP Fails - Download this slide show to learn all about ERP implementation

WHY ERP Projects Fail - The top reasons

Why limit customization?  

Tips on ERP implementation

Download  this .pdf file - 'Why ERP Project is delayed'

Click to learn about POC (Proof of Concept).

BPR Business Process Reengineering