The Post Office recently hit the headlines again after admitting that IT training and support failings may have resulted in some users of its Horizon system being wrongly accused of false accounting.
After undergoing a forensic accounting investigation, it now seems doubtful that human error on the part of the system’s users can account for all of the discrepancies mentioned.
The story serves to highlight the fact that the majority of IT implementations experience issues and, more often than not, the provider refuses to acknowledge that there is a problem with the system – instead blaming it on user error.
This post specifically addresses some of the issues surrounding the implementation of IT systems and how you should approach problems as and when they arise.
Lessons Learned from the Post Office’s IT System Problems
As the Post Office story has demonstrated, when any new IT service is implemented, the need for governance, comprehensive training and support is vital.
Whilst it is still uncertain whether the Post Office scenario was the result of a training issue rather than a system issue, CEO Paula Vennells has admitted that the independent review has raised questions about the comprehensiveness and effectiveness of the training that sub-postmasters received when the Horizon software was rolled out in 2000.
So what can we learn from this situation? During an implementation of any size the training costs associated with gaining proficiency on new systems are always closely scrutinised, but this should not result in frugality when it comes to best practice.
All users should be able to utilise the system to its fullest and be aware of the benefits associated with using the new system. We find that having in-house ‘champions’ of any new system is a great way to achieve this. Experienced staff members fully-versed in using the new technology can act as a positive influence within departments and assist in harmonious transitions and effective changeovers. Slashing training budgets has a double whammy effect – the business does not maximise on the benefits the system is capable of driving, and the user is in the dark as to how the system will directly make their job easier.
6 Steps to Take if Your IT Goes Wrong
Long before the issues with the Post Office’s Horizon system were highlighted in the news, its users were reporting problems and issues to the internal help desks. Some sub-postmasters claimed to be baffled by the discrepancies between what the computer claimed they should have in their tills and their actual takings for the day. The cases of several sub-postmasters like Jo Hamilton who was forced to pay back £36,000 or face prosecution accentuated the need for an extensive investigation into how so many experienced, long-serving employees were apparently making such huge mistakes.
The forensic investigation at the Post Office has in fact revealed defects in the system that may have affected up to 76 of its branches. What this demonstrates is the all-too-common scenario of a refusal to accept system error over human error. If, for example, a user encounters an issue and contacts the service provider or help desk and are told by perceived ‘experts’ that it must be due to something they are doing incorrectly, they are usually not questioned. When that same issue is reported time and again it is prudent to question the validity of information and take steps to build a better picture of the issue based on technical evidence.
Taking this into account, these issues provide opportunity to take a high level overview of the six key steps you should take to resolve problematic IT provisions, as follows:
Step 1: Build Your Technical Evidence
When dealing with problematic systems or, for that matter, outsourced services of any kind it is vital that you have as much evidence to hand as possible. The evidence won’t always be perfect but should be balanced and detailed enough to provide a good overview. Any evidence from screen prints, reports, program logs, fault logs or third party logs should be included so an overall idea of the system’s functionality and behaviour may be examined.
Step 2: Check Your Contract
Check what information is actually scheduled in your contract. Are all of the schedules (i.e. requirements, expectations, implementation plans, etc…) specifically referenced in the contract or are you assuming they are implied into the contract? In the sub-postmasters’ case they were forced to ‘make good any losses’ due to a clause in their contract. Sometimes these clauses seem so onerous that the reader may conclude, “They can’t really mean that. I’m sure it will be fine…” Please do beware – it is your responsibility to check contracts thoroughly and highlight any dubious obligations assigned to you.
Step 3: Clarify Your Obligations and Responsibilities
This process will help you draw a line of demarcation around who was responsible for each part of the implementation and its management. A crucial step in understanding where things went wrong is to ascertain which party is responsible for the key processes within an agreement. Now is the time to consider the participation your own people had in managing the implementation. Be mindful that where the contract is silent on responsibilities in this respect, then expert responsibilities can be implied into your provider’s duties to you.
Step 4: Define Your Objectives
It is important that you clarify the exact resolution you want. Is it a better working relationship? Or perhaps you want to leave the contract early? You should consider the outcome carefully and logically so your decision is objective.
Step 5: Be Aware of Other General Considerations
Your decision will have a wide-reaching impact so it is vital to consider all the implications. For example, have you had your expectations and contract terms validated externally? Are you certain you are not undermining your contractual position during the process? At this point it’s recommended that you obtain an outside view of your situation to ensure your perception of events holds weight.
Step 6: Schedule a List of Points to Discuss with Your Supplier
In order to start rebuilding your relationship or resolve problems you need a clear picture of what you want to say before a meeting is arranged. Start by creating a basic chronology of events from inception to the present. For each event explain what has gone wrong, ensure you have evidence to support it and make clear your objective in raising that specific point. Also create a timescale for rectifying issues and rebuilding your relationship.
Will the Post Office’s New Initiatives Address Future IT System Issues?
The outcome of the Post Office review has seen plans emerge to roll out three new initiatives to address any future concerns or issues sub-postmasters may have. They are:
- A Branch User Forum where sub-postmasters can raise issues regarding the Horizon system
- A working party to review complaints made about Horizon
- A review chaired by an independent figure.
We feel that these initiatives are useful and could provide a blueprint for resolving problematic IT services going forward.
Many system manufacturers host and support user group forums and we advise users to seek them out. Not only do they provide a place to raise issues, but also a place where users can work together to solve problems and suggest solutions. By joining, voice enhancement requests become consolidated and allow pro-active input into product roadmaps. Working parties are useful as they will ensure effective reporting and trend analysis can be proactively monitored and root causes analysed. Often the 80/20 rule is found to apply. 80% of the support calls/complaints relate to the same root cause, which once fixed results in further time gains for the support function to resolve other remaining issues.
Finally, an independent chair that is removed from any bias or issues relating to commercial or contractual underpinnings is essential in maintaining a clear and pragmatic dispute resolution process.
Photo Credit: iStock
