Why MIS implementation plans fail and what you can do to succeed

Implementing any new management information system (MIS) is a massive undertaking irrespective of the size of the business. If it’s done correctly the benefits easily outweigh the initial pain. But what some people fail to realize is that this pain doesn’t necessarily occur in the implementation phase – often it’s after the project has gone live that the cracks start to appear. In this article, I’m going to discuss the testing phase which occurs immediately after implementation and why it’s so important to include this in your plans.

Why is the testing phase important?

More often than not in our experience we see very smooth and slick implementations that adhere rigidly to their project plan come unstuck after go-live because of inadequate testing. In fact, testing is the most commonly overlooked aspect of any project plan - surprising given the implications, which could include:

1. The end user loses confidence in the print MIS system because of incorrect results and the inability to work with standard business processes.

2. The business as a whole loses confidence in the system - sales complain about problems with inconsistent pricing (especially against previously quoted work), manufacturing moan about incorrect consumption (time or materials), accounts can’t process invoices because of errors earlier in the production cycle and the list goes on…

3. Suppliers query whether orders placed with them are correct, which erodes reputation.

4. Customers start to suspect they’re being quoted over the odds or lose faith that their work won’t be manufactured to their specifications.

The good news is that there are measures that can be built into the project plan to limit the project going awry after go-live. They do take time and can be somewhat laborious, but they're definitely worth the effort.  

In your project plan you should include a well thought out test matrix that reflects the day-to-day operations of your business. Then split the testing phase into modules, and outcomes from within those modules. Because building a testing matrix is not something that many people have experience of, I've put together some points to consider.

Outcomes

Firstly, start with scoping what you want to achieve from testing with stakeholders. Here are some suggestions:

• Time consumption for all resources
• Material consumption (plates/ink/paper/packing/delivery)
• Benchmark against incumbent system
• Documentation and reports.

Define parameters

Secondly, build into your testing matrix the parameters that the system must cope with such as:

• Product type
• Extent
• Size
• Quantity
• Other constraints such as colour.

A first phase testing matrix may look something like the example below (click it to see a larger version), but it also differ considerably – no two businesses are the same. For instance, you may want to capture whether the correct resource is chosen. As long as you’ve consulted with the relevant stakeholders when compiling the testing scope, then oversights should be minimal.

Common scenarios

Finally, brainstorm scenarios with users and then stress test the system to see if it breaks. This could include the following:

• Quantity variants
• Versions/kinds
• Optimize functionality across sheets
• Outwork
• Stock change
• Multi-deliveries
• Copy/revise
• Any specification change to the above.

Using estimates from the first phase of testing could save time when moving on to the scenario phase.

Other things you shouldn't ignore

It’s important to remember when building an MIS that you’re trying to capture all the permutations and idiosyncrasies that have been built up over several years of operation in a small amount of time.

Whilst some working practices will need to be refined and possibly changed to accommodate the new system, there’ll also be other established methods of working that form part of your strengths and effectively amount to your company’s unique selling point. These too need to be captured at the testing phase.

If workarounds are needed, then it’s important to stress these to users before going live. If they’re aware that there are limitations early on in the project, it’s easier to manage expectations than trying to recover credibility when things start failing after going live.

Finally, it’s good practice to involve expert users for each module testing. No matter how much knowledge the project leader may have, there’ll always be an unforeseen scenario that’s an oversight. Involving expert users in the testing phase mitigates any risk and takes a bit of the pressure off the project leader.

Summary of steps to take:

1. Start with scoping what you want to achieve by testing with stakeholders.
2. Build into your testing matrix the parameters that the system must cope with.
3. Construct a first phase testing matrix, making sure you consult with relevant stakeholders and users.
4. Using expert users, stress test the system to see if it breaks.
5. During the testing process, capture details of those processes that contribute to your strengths, as well as those that need refining.
6. Make sure that any limitations of the system are communicated to users as soon as possible.

If you consider the above, and include the testing phase in your plans, you'll be able to minimize some of that initial pain for you and for your staff.