Improving ERP Implementations - Part Two

In the last blog in this series, we covered some of the key areas in selecting the right ERP product.  In this second part, we will discuss the implementation methodology.   The first question to take up is “Why should you care what implementation methodology your ERP partner uses?  Isn’t that their business?”  After all, you may be shelling out a small fortune to have your ERP system implemented, so it should be akin to getting your car serviced or a room added onto your house.   Sit back, relax and enjoy as your ERP system is implemented for you.  

If only it were that easy.   Successfully implementing an ERP system requires tight collaboration between the customer and implementing partner and it takes a lot of hard, dedicated effort on both sides.   The relationship could be better envisioned as a partnership rather than strictly a client-vendor arrangement. 

Consider a few of the key areas where your involvement is absolutely necessary:

• Requirements meetings
• Ensuring your business processes and requirements are communicated effectively to your implementation partner
• Providing data from legacy systems
• Obtaining data from third parties (Banks, other IT systems)
• Coordination, scheduling and management of internal project resources
• Attending training sessions

Not only that, you already have a full-time job!   The implementation methodology used may impact not only the quality of the implementation, but your daily work-life for an extended period of time, and so should be given due consideration.  

The two major implementation methodologies in use are:

1. Waterfall
2. Agile

Waterfall – the project is carried out logically in a series of steps.  Once one step is completed, the next is taken up and so on.  For example:

1. Design requirements meetings are held
2. Design specifications are written 
3. Design specifications are approved 
4. Configuration
5. Data conversion
6. Development (customization)
7. User Acceptance Testing  
8. Training
9. Final Data Conversion
10. Go-Live

This is logical and fine and works well in smaller, simple implementations, where there is little to no customization.  It also works fine for industry-specific software systems which very closely fits your business requirements.  It is also fine for straight-forward cloud based software systems which are not customizable.  It is not the best choice for complex ERP implementations as we shall soon see. 

Agile – simply put, it is an incremental and iterative approach to product development.  Work is delivered in periodic segments of time called “sprints”.   For example, a sprint may be defined as two weeks.  At the end of the sprint, it is expected that the work is functional and complete.   From this, new feedback and understandings arise and the next sprint begins.  Thus, each sprint takes the project closer to the end goal.  The process is highly adaptable and anticipates and embraces change.  Therefore, the term “agile” is well-chosen!   Agile requires tight communication between customer and implementing partner and indeed, daily communication is one of its key benefits. 

So, we can see if we are implementing a simple ERP system with little or no customization, Agile doesn’t make sense.  Agile is for product development and we are not doing any development!   If you are implementing an industry specific auto-repair shop system, you will simply use it out-of-the box and Agile doesn’t fit at all!  A simple cloud-based payroll system -  just plug in your employee data and start using it.  Agile not required!

However, in a complex ERP implementation with customization, heavy data conversion, integration with third party systems, and so forth, development is required and Agile is ideal.  Agile is best when complex requirements are not fully known up-front.  At the outset of a project, the customer knows the least about the ERP system and the implementing partner knows the least about the customer’s business.   The likelihood of writing a complete, and correct design specification as the first action in the project is low. Agile allows team members to adapt to change, new revelations come to light and feedback is used to improve to product. 

There are several methodologies which fall under agile (Scrum, Extreme Programming, Crystal, are a few). 

Agile is best for large, complex ERP implementations.  Case closed.  Whoa there!  It may very well be, but it must be applied intelligently.   Agile was originally developed for software product development.  For example, a company creating an ERP software product.  Therefore, its processes are internal to the company developing the product and not customer facing.   An ERP implementation is customer-facing.  The communication gap between the customer and implementing partner must be bridged as the customer will very definitely be involved.  

With Agile, budget and timeline may be difficult to predict as a full design specification is not typically written up-front.  Moreover, specifications and documentation are not highly-valued items in agile.  Because change is embraced by Agile, the scope of the project may increase significantly and the budget blown.  Moreover, with Agile, work is often estimated using obscure, arbitrary values which doesn’t translate well to real-world costs.  

The bottom line is Agile must be adapted for ERP projects in an intelligent and thoughtful manner.  Reading and following a book on Agile and applying the concepts strictly to an ERP project is inviting disaster!

So, if you are going to implement ERP using an Agile implementation methodology, the following guidelines may be of use:  

1. The implementing partner must ensure customer team members understand Agile concepts and terminology.  This is the biggest initial barrier to success.  The customer team and implementation team must understand the concepts and terminology to be used in the implementation process.  The good news is there is probably only a dozen or so common Agile terms that need to be understood.  

2. Initial design meetings to create the initial product requirements list is highly recommended.  Work should be estimated in terms the customer can understand which easily translates to dollars.   This is likely, the good old faithful, hour.  This gives you somewhere to start and will eliminate unnecessary and excessive change downstream provided the designer is competent and has a thorough and deep understanding of the ERP system being implemented.   There is absolutely no substitute for this.  

3. Ideally, the implementing partner has worked out all the kinks out of the Agile process and has adapted it for ERP projects.  The biggest issue you may face with Agile is scope creep – the project scope expanding over budget, so both parties must keep a constant eye on this and use reporting metrics to predict and control the budget.  

4. Use judgement when utilizing agile principles.  Common sense and practicality override agile theory and principles.    

5. Have fun.  Implementing ERP Projects using agile can and should be a fun and rewarding affair.