Bringing ‘success’ to an ERP project appears as much of an art today, as it used to be over a decade ago. Success of very few initiatives perhaps have dependencies on as many parameters, as an ERP project. Everyone on the customer side, as well as the consulting company side, would claim to ‘know’ what it takes, and be ‘experienced’, and yet none of the ERP projects go precisely as per the initial plan.

User’s knowledge of their business processes, the changes they want to bring-in, occasional quest to go through a Business Process Re-engineering exercise, expectations from the product, consulting company’s ability to capture the domain and client side business processes, their ability to document and articulate what they have understood – to the customer and to their own teams, complexities of country specific localizations, the herculean task of getting clean data from the customer, ‘comprehensive’ system testing, the never ending arguments on ‘Change Request’ vs ‘in-Scope’, team member changes on either sides, the ever deficient user training and the challenges of ‘Change Management’ jointly present an extremely complex mix of factors – that do not have any simple, or a single point solution. Inter-dependence of the customer and consulting teams often brings friction, and emotions run high. All this ultimately impacts the project timelines and costs – both for the customer and the consulting company.

Rarely has an ERP project succeeded or failed simply because the customer chose to deploy a product A rather than B – as long as he chose from amongst a set of world-class products. It is the Implementation Methodology, customer side readiness, consulting company’s experience, and the overall project management rigor – that impact the various parameters that ultimately determine project success.

The most important phase of an ERP implementation is the ‘Business Process Study’ – also called the FRD. Look up any project – and this would turn out to be the weakest spot. Commencing immediately after the project kick-off – this phase falls in what is called the ‘honeymoon’ period. BPS discussions become hard to keep comprehensive and precise. ‘Implicit requirements’ often fail to surface. And the ‘users’ are required to visualize the system by reading (usually poorly written) BPS/ FRD documents – something they are not trained for. It’s no wonder therefore that FRD signoff get invariably delayed, and you always have an extremely apprehensive customer at this stage. If the project is fixed-cost – both sides start having a sense of being on the losing side.

‘Prototyping’ – immediately after the BPS – immensely helps in addressing many of these challenges. What a prototype must comprise of, and what does it not have to have, is always a topic of debate. To me the answer lies in – being clear about the objectives of a prototype. A prototype is intended to help the customer key users visualize the system they will finally get. It therefore covers the UI, Navigation and Report layouts. Freeze on these 3 – and you have won more than half the battle. In my opinion – a prototype is critical to get a customer sign-off on. The BPS/ FRD sign-off, in conjunction with a prototype signoff, is far more valuable.

And yet, project after project, one would see ‘prototyping’ getting compromised. The activity of prototyping brings to fore the intense ‘thought process and designing’ that the consultants and key users both keep pushing for a later day (or rather avoiding). We hear all sorts of excuses – insufficient time, effort not budgeted for, can be done only after customization, can’t signoff unless we see it work etc. – and project after project goes through the familiar cycle of exceeded budgets, exceeded timelines and yet the final outcome not meeting the customer business needs.

Prototyping is certainly not the panacea to all that ails a typical ERP implementation, but this one thing has the potential of giving project success the maximum thrust.