The people who use your IT Systems to deliver Service to your true end-customers are also a key source of Problems, writes Robin Yearsley.
Your business folks are often under tremendous pressure to deliver ongoing results within their business lines. They have no time, little patience and absolutely no sympathy for technology or IT Systems. Therefore when things go wrong (as they sometimes do!) they like to circumvent the usual support processes – like calling the Service Desk to report a fault, waiting for technical assistance and providing valuable information to assist your support services people.
I have painted a rather gloomy picture here already and perhaps that’s a little unfair. Within call center environments, where people spend tens of hours calling customers, users are only too happy when their systems fail – they get to do other work or take an early break! Remember – there business line is effective suffering from downtime and I’m pretty sure their boss won’t be happy with the situation.
So, against this background what are the typical reasons why Problems can occur with “User Error”?
User Education – or rather the lack of it! Often within the project delivery lifecycle, testing and education are some of the first activities to be cut back. This means that due to over-runs in the design, build and (sometimes) testing stages – there’s little time to actually education end-users on their forthcoming new IT system. As well as reducing the businesses ability to actually realise the benefits of the system – it leads to users making mistakes, “tinkering” and finding their own amazing “shortcuts” to get the end results that they require. There is really no substitute for quality education. It helps to prevent end-users circumventing how they are supposed to use their systems. Things you can do here are: maintain linkages with the IT education team, determine just how much education end users have received and make education a mandatory requirement on the business side of your system SLA’s; also ensure a local ‘escalation’ procedure (where education gaps are apparent) to let end users raise questions and receive answers for new queries is known and in place.
Purposeful Documentation – users guides, cheat sheets, ‘what to do if this happens’, ‘where to get help’, ‘what to expect from IT Support’ – are all examples of local documentation that can be carefully placed on or near the end-users desks to prevent “tinkering” and ingenious workarounds being applied. For example one Guy we knew in a customer service function actually created his own set of highly complex report writing tools within Excel, because he didn’t know that the report writing suite was only limited to his manager. He told his manager (to her amazement she didn’t appreciate HOW he was producing these reports) who immediately granted him access to the Report Suite. (Ironically, the Excel version did everything the team needed – so it stayed!!)
The delivered systems “fails to meet specified requirements” – This is more common than you perhaps realize. The system, as delivered manages to get through testing, user approval and is accepted into production – however for some reason the system doesn’t do something that it’s supposed to do. Some the end-user community find an ingenious way around this. In my experience this is usually something relatively complex about importing data and processing it against key dates, or exporting files between systems because the overnight automated routine keeps failing and the system cannot automatically recover. Users finding their own workarounds is fine in the very short term, often only lasting for that particular working day, however this is very temporary. Workarounds like this are often “triggers” for Incidents that are lying there, waiting to happen. To try to overcome this common situation, you must try to determine where the system fails to meet requirements and understand how this will be remedied.
Validation, robustness and ‘self-healing’ – It makes sense that the ‘stronger’ a system is (in terms of handling weird occurrences) then the less likely that you will see Problems with it further downstream. With the advent of object orientated coding methods, the ability of modules to self-correct and maximise the availability of the system is excellent. Take action during the design stages of new systems to ensure that the levels of robustness are where you would expect it to be – when balanced against the required level of systems availability by the business.
Some more ‘top tips’ to bear in mind with Source #5:-
1. Ensure there is really a problem to eliminate – be careful not to expend large amounts of resources on ‘red herrings’!
2. Ensure education is not ‘axed’ – Stand up for quality education. Not only does it help to maximise the benefits of a system – but it prevents Problems too.
3. Ensure systems are ‘fit for purpose’ – Check out the test results, work with user QA groups, get a good ‘feel’ for the forthcoming system before it enters production. Influence the quality of the final solution BEFORE it enters production.
4. Testing should include destructive tests that satisfy curious minds – It’s guaranteed that once a system goes live it will be absolutely hammered with every possible combination of data/keyboard presses and all sorts of eventualities that were never thought of during testing. To this end, some up-front destructive testing should help to find some of the more serious conditions that might occur after go-live. You do destructive testing, right?
5. Implement a ‘super-user’ programme – best of all – maintain an excellent relationship with the business user community. Form partnerships with key folks who act as ‘super users’ for different systems. They will help you to differentiate between real problems and ‘red herrings’ as well as help you get access to the right people and information should a real problem arise.
Tomorrow, we examine the penultimate source of problems #5 – How Production is Executed. In this source we explore how you run your environment and look more closely at internal controls and the effectiveness of your Problem Management process.
Posts
