The challenge of implementing management software

By Mathieu Boisvert

ERP, SAP, CRM, DMS? Implementing these management software packages can be complex. Here's our approach to simplifying the process.

You've probably heard an anecdote where the implementation of management software (ERP, SAP, CRM, DMS, etc.) turned out to be longer or more costly than expected. Or of implementations where the end result didn't live up to expectations.

The complexity of implementing such systems is often underestimated. The problem generally lies not in the choice of platform, but rather in aligning the customer's processes with those of the software. Indeed, even with a quality product and the good will of the supplier, if the customer's processes are not sufficiently close to those of the system, the project becomes unpredictable.

Take, for example, the Phoenix system, designed to manage the payroll of Canada's federal employees. With 85,000 business rules to cover, and despite several years of preliminary analysis, it's hard to imagine that the full complexity of the project could have been anticipated.

That's why the real risks involved in implementing management software are not time and cost overruns, but project feasibility and the delivery of expected benefits. And unfortunately, upstream process analysis is not enough to reduce these types of risks, not least because :

There is a significant gap between documented processes and reality on the ground.
Knowledge of current system processing and calculations is often incomplete or forgotten.
Few experienced people can remember all the business rules in place.
The supplier's generically designed software does not take into account all the specific needs of each customer.
Requirements frequently change over the course of an implementation, which can take several months or even years.

We find that people are not sufficiently educated in empirical project management. It's a pity, because some customers would benefit from it. In a nutshell, an empirical approach is as follows:

This is our current way of doing things (manual or computerized).
Here are the desired benefits of the new system (e.g. processing speed, reduced effort, data reliability, better decision-making, etc.).
Here are the most frequent use cases in our operations: can we take one and demonstrate how the new system behaves?
OR
Here are the use cases that need to be improved or introduced: can we take one of them and demonstrate how the new system supports them?
Reassess the project's feasibility and benefits based on the results of step 3.
Resume step 3 with the next most revealing topic.

If the choice of subjects is well executed in step 3, then the implementation should tend more and more towards the right system. Or, if not, the project will offer the option of stopping early, because the customer's most important expectations are not being met.

With a well-executed empirical approach, we should therefore feel increasing confidence in the implementation, have options to adjust or stop, and have confidence in what's to come, rather than end-of-project anxiety when there are insufficient resources of time and money to turn the project around.