IT Governance Definition
A definition of governance is a good place to start. Oxford dictionary describes it as
“. the act, manner or function of governing.”
Governing is defined in part as
“.regulating the proceedings of a corporation.”
Gartner define Governance as
“Assignment of decision rights & the accountability framework to encourage desirable behaviour in the use of IT”
In plain English, IT Governance is the rules and regulations under which an IT department functions. It is a mechanism, put in place to ensure compliance with those rules and regulations.
Project Governance is a subset of IT Governance. Project Governance is the rules and regulations under which an IT project functions. As with IT Governance, it covers the mechanisms put in place to ensure compliance with those standards.
Governance is very much the flavour of the month in 2003. Many organisations are starting to address the situation and it is useful to understand why. Here are a number of factors causing this sudden attention.
There is a lingering feeling in many organisations that Y2K was a con. Millions were spent for no appreciable result. There were no major catastrophes and still organisations bunkered down for a year or more preparing for the supposed problems. Business feels uneasy. There is more pressure coming to put rules in place for the management of IT so that if another Y2K comes along, it will happen under the same set of guidelines.
Following Enron and others in the US, HIH and OneTel in Australia, and many other collapses, there is a general drive to bring accountability to organisations. This is flowing through all areas, but IT is a particularly attractive target. Many corporate collapses were at least partially the fault of failed IT systems or projects.
Dot Com Collapse
All those IT startups that failed, gave the impression that IT was still a bit of the wild west. If corporate IT was involved with some of the dot coms they were bound to have some of the mud stick. This has caused a push to make IT more accountable.
It is not all coming from outside IT. CIOs are increasingly seeking a way to draw up terms of reference for working within the organisation. Governance can help define the role of IT.
How to define Governance
Many organisations struggle to define governance within their own four walls. All sorts of things get dragged into the governance framework with the result that, what should be something less than ten pages, becomes a book.
Defining IT Role & Responsibilities
The starting point to define governance is to define the role and responsibilities of the IT area. If the document goes over a page, it is probably too detailed. Over two pages is far too granular for the definition of governance.
- Role means a person who is the one accountable and the way the organisation is structure
- Responsibilities mean the role must be doing something. The “doing something” implies there is a methodology or process for doing whatever is being done.
These are the two key elements of governance. “People & Structure” and “Process”.
At a department level within IT, there should be a definition of what each area is responsible for. When rolled up this structure, they should cover the responsibilities of the IT area as a whole. By defining R&Rs, then rolling them up as part of a structure, it will become clear where gaps exist, or activities outside the scope of IT are being performed. It also shows the poor fits in the organisation.
Whilst it is generally a good principle to only have one person accountable, in defining governance this is not always practical. Organisation structures change and evolve. People come and go. A Help Desk Manager today, may be part of the Desktop Services Group tomorrow. For the purpose of defining governance, it is sometimes better to define at a group level.
This is not a one way street. Many non-IT areas of the organisation can be part of governance. For example, it may be the responsibility of business areas to produce a business case prior to a project gaining approval to start. Users should have an obligation to provide requirements for a new system. One organisation I knew put in their governance document that no new project would be touched by IT until the business produced a business process model of the current area.
Part of the people side is also the communication process. How do people talk over the IT fence? This implies the establishment of formal communication forums where interaction can take place. These may be Business IT committees, Group IT Steering Committees, User Forums, User Groups, Quality Groups etc. There should be a number of forums that have clear objectives and don’t overlap.
There are several aspects in process that need to be covered in the governance document. Effectively we are establishing the rules under which the department operates.
The first is the standard processes or methodologies the organisation has adopted. One would expect IT departments to be the leaders in business process modeling of their own standard processes. This is often not true. In order to create a governance framework, there must be some understanding and documentation of operational procedures. For example, how the organisation runs the mainframe, employs contractors, purchases hardware, charges customers etc.
All these should be visible in the roles and responsibilities of the area, and need to be documented at some level. If a proper business process model has been created, the governance can refer to that model. If not, governance may have to refer to some high level criteria. For example, it might define that all new software will go through acceptance testing by the system administration area prior to being deployed.
Typically people think of the development cycle begins when a project starts. Governance should cover the evaluation of ideas, justification, approval and prioritisation of projects. This is where considerable gray area usually exists between business and IT. An agreed process is critical.
From project start, there are areas that should be included in the governance. For example, there may be a standard project methodology, or test methodology, or approval process. Compliance with these should form part of project governance. Use of particular techniques may be included. Language and architecture can be part of governance.
Release and Change Management Methodologies
If the organisation has adopted ITIL these areas are probably well structured. They do however form part of governance. It might be as simple as saying all release management will follow the ITIL standards adopted for the organisation.
Service to Customers
In this area of governance we cover the methodologies used in such areas as Help Desk, Maintenance, SLAs, Desktop Support, availability etc.
One area that always needs attention is the area of tools. Tools can be tools for Release management, configuration management and change control, database tools, software development tools, modeling tools, monitoring tools etc. If allowed, these can proliferate and incompatibility leads to inefficiency. Governance should also dictate what tools to use in the organisation.
Whilst IT standards may be comprehensive, they do not belong in detail within the governance document. For example, part of governance may be that all systems must be supported through a Service Level Agreement (SLA). The governance document is not the place to define the SLA. The governance document may refer to a more detailed document but should merely state that there should be an SLA for every system, and it should comply with the standard for SLA’s defined in …
There are usually standards in the organisation and complying with these standards becomes part of the governance procedure. It also drives the development of standards. If they don’t exist, governance will identify the lack of a suitable standard in a particular area.
Mechanism for Compliance
Governance may refer to particular standards or procedures, but the purpose of governance is to ensure they are followed. A government cannot just pass laws. It needs to ensure people obey the law. There needs to be a mechanism in place to monitor compliance. This can be as formal as an IT Audit function, to as informal as periodic reviews. One way or another, metrics must be collected to ensure the goals set in the governance document are being met.
The following model helps define the structure of a governance document.
Governance applies through:
|Governance applies through
- Defined responsibilities
- Purpose or each forum or communication tool
- Authority to make decisions� Participants who should contribute
- Compliance with standard processes
- Use of standard documentation
- Reference documents for the consistent use of IT
- Tools to support projects
- Tools to support operational areas
- Collection and analysis of metrics
- Audits of projects
The delivery of governance above will provide the following benefits:
- Standardised process and procedures to better manage the IT environment
- Maximise return on IT investment
- More effective IT because of a closer alignment with the business
- Alignment with corporate objectives
- Consistency with IT Strategy & Policy
- Accountability and transparency in decision making that impacts on IT.
Copyright Project Perfect