Implementing any new management information system 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.
More often than not 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 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.
Firstly, start with scoping what you want to achieve from testing with stakeholders. Here are some suggestions:
Secondly, build into your testing matrix the parameters that the system must cope with such as:
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.
Finally, brainstorm scenarios with users and then stress test the system to see if it breaks. This could include the following:
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.
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.
Good luck and check back soon to read part 2 of this article where I'll be talking about what else you can do to ensure a successful implementation.