Even before Simply Red’s Mick Hucknall famously sang about his wish to do ‘The Right Thing’, less musical minds have been considering the meaning of Governance.
My usual description of Governance is rather close to Mick’s song title, in that Governance is “doing the right thing, and being seen to do that right thing”. The right thing for whom? For customers, managers, employees, shareholders, regulatory authorities, managers, users – for all the stakeholders, internal or external.
In a simple sense it’s about ‘showing your working’ in different situations:
- Sourcing Governance: Why did we award that contract to supplier X? Here is the information available on the requirements and the different candidate suppliers and the process we went through.
- Business Case: Why did we choose to go ahead with project Y, or to select option 1 over option 2? Here are the details of the business case including perceived benefits, costs, risks and the information available at the time of the decision.
- Why did we decide NOT to fix problem Z? Here is the information about the problem impact, the cost of the change which might have fixed it, and the remaining life of the system.
Governance is useful in helping us do ‘the right thing’, but it could be said to be even more important when we consider that, in hindsight, we DIDN’T necessarily do the right thing, but at least we have a record of what information we had to base our decision on, the process we went through and who was involved. The last element (who was involved in the decision) might lead us into the unspoken process of ‘Blame Management’, but we should resist that, as that way leads to the ‘dark side’, and instead focus on trying to improve decision making in the future through better information gathering, wider consultation, or a tuned process.
Service management frameworks and standards all attempt to describe Governance, why it is important and how we might achieve ‘good governance’.
The ITIL definition of Governance talks about having the right people, the right processes, and the right people allocated to doing those right processes (through a mapping of roles). ITIL rarely says what the ‘right thing’ is, though, exhorting us to ‘consult the appropriate stakeholders’ (as anyone who has taken an ITIL Intermediate exam will remember will).
COBIT is more defined on the meaning and application of Governance, as indeed it is on most things compared to ITIL. Whereas ITIL suggests we consult the stakeholders to determine the appropriate goals, COBIT says “We’ve done that for you. Here are 17 commonly-specified Enterprise goals and 17 IT-related goals and here is even a mapping between them”. Such goals are also mapped to the 4 usual elements of a Balanced Scorecard, and also to the major stakeholders’ needs of Benefits Realization, Risk Optimization, and Resource Optimization.
One could be forgiven for thinking that COBIT is more like a standard than a framework because it’s structure is so well defined and precise, but a framework it is, and one could add in other goals, processes, mappings to it if the benefit seemed to outweigh the effort. COBIT is actually a very comprehensive framework (certainly in comparison to some others) but all frameworks need to be adapted for particular situations or if a very specialized processes are to be included.
Whatever framework or standard we adopt, it needs to be applied in a sensible way in order to ‘do the right thing’ for our organization. This is what we advise when we are training or consulting for our customers.
Director of Training