Listening to a radio broadcast today about the risk associated with technology we heard a senior manager apologising for the poor quality of service provided to his organisation’s customers. This was due, he claimed, to: “Problems with the new computer system”.
It’s weird isn’t it, that more than half a century after computer technology (IT Systems) were first introduced into commercial organisations that we are still blaming computer systems for what are fundamentally human problems. Maybe we are blaming ‘computer systems’ in the hope that the listener – who by and large won’t be an IT Professional – will shake their head wisely and agree that technology is a baffling, and sometimes uncontrollable, thing.
But if we look at the problem from a risk based reviewer’s perspective, and from the many published reports on ‘Problems with new systems’ we keep finding references to: “Poorly articulated, documented and managed change support and change management regimes” and “Errors not being identified, communicated and cleared through formal working practices” and, again, “Systems becoming unstable, following incomplete testing, leading to fragile working environments and frustrated users and consumers.”
There are well known best practices such as ITIL, developed especially for the management of IT services from a user perspective. And there is ISO 20000, that further uses ITIL as a springboard to generate an international standard for IT Service Management. A read of these would at least provide a clue to the direction to be taken and what ‘good practice’ might look like. And, none of the good practices is impossible to attain, all that’s required is concentration on process and sequence and not making arbitrary decisions to bypass critical control steps.
So if we know what the underpinning problems are – why don’t we fix those first, by applying the solutions that are available? Or, is speed of implementation seen as more important than satisfied users, customers and consumers?
I wonder how many project business cases include performance indicators that can be measured both before and after the project concludes?
I wonder how many projects have success factors defined in relatively unmeasurable qualitative terms (such as ‘better information for customers’)?
If we don’t have metrics that we can compare, or success factors that are measurable, then how do we know if we’ve succeeded or failed?
So, I wonder how many projects are never properly reviewed post completion because we all know that their conclusion is inconclusive?
We live in a world where we use the phrase: “lessons learnt” over and over again – but if we were that good at learning lessons, wouldn’t there be fewer project failures and wouldn’t there be a greater drive to improve the measurability of project outputs and outcomes?
Just a thought.
Internal Auditors operate inside the organisation – hence the name: “Internal Auditor”. And Internal Audit teams set out to be independent, objective assurance and consulting activities designed to add value and improve organisations’ operations. The first internal audit teams operated a long time ago – in the early 1900s – followed by the formation of a professional institute in 1941. See
The Institute of Internal Auditors.
Today Internal Auditors help an organisation accomplish its objectives by bringing a systematic, disciplined approach to evaluate and improve the effectiveness of risk management, control, and governance processes. But the past was often different – in the early days internal audit teams were more aligned to ‘checking and approval functions’ as evidenced by records of audit teams from the 1950s where they describe ‘approving certain large value payment cheques’. The real change came with the growth of the number of transactions executed by organisations – whereby the audit team could no longer check each individual transaction. The caused the auditor’s role to change to examining overarching control structures rather than individual transactions. And the final shift to the current state of play took place around the 1990s when Risk Management finally matured and the auditors role shifted from a focus purely on control, to an examination of the balance between risk and control.
The Internal Auditor has finally come of age. It’s now widely acknowledged that it’s management’s role to determine risk, it’s management’s role to pair adequate, effective and efficient controls against evaluated risks that are beyond the organisation’s articulated risk appetite. And it’s Internal Audit’s role to see whether management are doing this effectively.
So it’s goodbye to the Internal Auditor as the inspector, and hello to your new trusted business advisor.