In the commercial printing industry, where precision, efficiency, and cost control are essential, how do you manage complex workflows, track high-volume jobs, and consistently meet customer demands?...
Implementing any new management information system (MIS) is a large 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 going live that cracks can appear.
In this article, we’re going to discuss the testing phase, offer some suggestions on what you should include in your project plan, and some other things you shouldn't ignore.
Contents
Why is the testing phase important?
More often than not, we see very smooth and slick implementations that adhere rigidly to their project plan come unstuck after going live because of inadequate testing. Testing is the most commonly overlooked aspect of any project plan - surprising given the implications, which could include:
- The end user loses confidence in the print MIS system because of incorrect results and the inability to work with standard business processes.
- The business as a whole loses confidence in the system - sales complain about problems with inconsistent pricing (especially against previously quoted work), manufacturing complains about incorrect consumption (time or materials), accounts can’t process invoices because of errors earlier in the production cycle... and the list goes on.
- Suppliers query whether orders placed with them are correct, which erodes reputation.
- Customers start to suspect they’re being quoted over the odds or lose faith that their work won’t be manufactured to their specifications.
Developing a project plan
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 can take time and can be somewhat laborious, but they're 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.
1. 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 the incumbent system
- Documentation and reports
2. 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 color
A first-phase testing matrix may look something like the example below, but it also differs 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 oversight should be minimal.
3. 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 changes 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
- Start with scoping what you want to achieve by testing with stakeholders
- Build into your testing matrix the parameters that the system must cope with
- Construct a first-phase testing matrix, making sure you consult with relevant stakeholders and users
- Using expert users, stress test the system to see if it breaks
- During the testing process, capture details of those processes that contribute to your strengths, as well as those that need refining
- 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 your staff.
