I have been involved in several rapid-learning projects over the last six months, where IT departments/projects are causing more problems, in terms of impact on Safety, Time, Innovation, Quality and Cost (STIQC), than they are solving. The problems I will speak of are generally being caused by entrenched behaviours, where IT, as a collective, have fallen in love with the solution (e.g. Outlook) and not the problem (e.g. critical Quality Improvement emails being missed on the frontline).
Often, opportunities to create gains, in terms of STIQC, are missed, where the IT default seems to be that the users are the bane of their existence and everything would be fine if end user just did as they were told. One IT recently said to me, “we wouldn’t have the problems if the users would just do it [follow their instructions]”. However, reality is rarely that simple.
Take the following examples:
- An IT department launching a new SharePoint Intranet. A search “findability” test demonstrates to the IT team that there is a problem linked to the transfer of documents from the old Intranet to the new one – mainly, they have not been optimised for the search engine. For example, the search test does not return a key document within the first four pages of search results. The IT team were made aware of this issue three weeks from launch. The recommendation was to slow content transfer, taking a quality over quantity approach, to ensure that relevant documents did not get ‘lost’ – “findability”, in this case, being partially reliant on people to locate documents and therefore vulnerable to information/knowledge loss, where the author or owner becomes unavailable. The decision was to launch without taking any action, deciding that this issue will be tackled later: thousands of documents are transferred, they are not optimised for findability, and impact upon STIQC in a High-Reliability Organisation is not part of the ongoing IT conversation.
- Outlook has a “Clutter” file. Frontline staff are complaining that critical (Quality Improvement) emails are being transferred to “Clutter”. IT blame the frontline – staff have received numerous PowerPoint training presentations from IT, explaining that if they repeatedly delete emails from a sender, the Outlook algorithm will interpret this as a ‘nuisance’ email and move them to Clutter. However, the problem, from the frontline perspective, is that email increases the extrinsic load upon their role – there’s too much of it; they avoid it; then they realise that they have to access it; they are confronted with hundreds of meaningless emails (“Hey guys, Brad is holding a spin class tonight”); they delete all emails, except those from trusted sources (usually line managers). IT say that the problem is that frontline staff are not following the direction given in the training (the users are non-compliant) – open all emails and there won’t be a problem! But by shifting perspective from IT to the front line they would discover that the real issue is with email behaviours – for example, conduct a communication audit and put a stop to all non-essential emails. Instead, IT and users remain in conflict, with the outcome being an ongoing negative impact upon STIQC.
These examples of IT and users in conflict, are, unfortunately, seemingly becoming more and more common.
An operational problem (STIQC) can usually be linked to issues of behaviour, process or structure. The challenge for IT is to reduce conflict by taking the opportunity to fall in love with the problem (the behaviour, structure, process, or combination, causing the issue), not the solution (e.g. Outlook). Until that happens, IT will cause just as many problems as it solves. If you want rapid-learning, you have to seek opportunities to shift perspective and look at what is causing the problem in the first place (process, behaviours and structures).