Supporting ITIL v3 with COBIT 4.1

The IT Governance Institute (ITGI) and ISACA, formally known as the Information Systems Audit and Control Association, recently delivered a new publication – ‘COBIT User Guide for Service Managers’. This is the first in a series of publications aimed at providing specific, role-based guidance on COBIT (Control Objectives for Information and related Technology) usage and builds on ISACA/ITGI’s previous COBIT to IT Infrastructure Library (ITIL) mapping documents, the latest being ‘Aligning COBIT 4.1, ITIL v3 and ISO/IEC 27002 for Business Benefit’. Both documents are available for download on the ISACA Web site – – the mapping document is free whilst there is a charge to non-members for the Service Manager Guide.

The Service Manager Guide and mapping document both recognise that there is often confusion between the ITIL and COBIT frameworks, and their adoption and utilisation within a corporate IT Function. An often posed question is ‘Do you use ITIL or COBIT?’, whereas ‘Do you use ITIL and COBIT?’ is more appropriate. It is therefore important for organisations to understand how ITIL and COBIT both ‘overlap’ and differ, and specifically how the latter can be used to support a corporate ITIL implementation.

Whilst ITIL and COBIT were created from different perspectives and by different entities, the Office of Government Commerce (OGC) and ISACA/ITGI respectively, there is substantial commonality. Importantly, it should be recognised that both COBIT and ITIL provide guidance on a range of good (or best) practices for IT Service Management (ITSM).

ITIL can be described as a set of books documenting best practice for ITSM, providing guidance on the provision of quality IT services and the facilities needed to support them. Whereas, the ISACA/ITGI description of COBIT is of supporting IT governance through a framework that helps ensure that: IT is aligned with the business, IT enables the business and maximises benefits, IT resources are used responsibly, and IT risks are managed appropriately. The ethos of COBIT therefore has many similarities with ITIL’s remit for ITSM – ‘aligning IT services to the current and future needs of the business and its clients, to improve the quality of the IT services delivered, and to reduce the long-term cost of service provision’.

Organisations need to understand that ITIL has never been (nor was intended to be) a complete, out-of-the-box solution and does not have to stand alone; in fact, an organisation may struggle to effectively implement ITIL without some form of IT governance framework. Whilst ITIL provides best practices on planning, designing, and implementing effective ITSM capabilities, the addition of COBIT guidance and tools can help an organisation ensure that its ITSM effort is better aligned with the business, and its governance and internal control requirements. A point not to be overlooked here is that IT governance does not only improve internal control but can also be a key facilitator in aligning IT goals with those of the enterprise – a key pillar of ITIL’s raison d’être.

So ITIL and COBIT are complementary rather than competing. COBIT is a framework of policies, processes, procedures, and metrics that can give governance-related direction to IT operations and associated ITIL processes. Importantly, COBIT can help guide an organisation in what should be covered in processes and procedures (whereas ITIL provides guidance on how the processes or procedures should be designed).

Following the logical flow of the COBIT User Guide for Service Managers, COBIT can enhance ITIL-based activity in the following areas: the definition of business and IT objectives and how they relate to each other; the translation of these objectives into usable goals and metrics; the assessment of ITSM process maturity; the enhancement of ITIL processes, particularly in terms of internal control; ITSM-role accountabilities; and the provision of assurance to both internal and external assessors.

Objective and Metric Definition

IT cannot be truly business-aligned without a comprehensive understanding of the enterprise’s strategic objectives and how they affect, and are affected by, existing and future IT service provision. ITIL provides guidance in this area in both the Service Strategy and Service Design books, but COBIT goes one step further. For example, where ITIL provides information on how to define a ‘goal tree’, COBIT offers a generic set of business and IT goals for the user to build upon in creating an enterprise-specific mapping to the IT and ITSM processes needed to deliver against corporate objectives.

This should then be built upon to establish business-aligned IT objectives. COBIT provides a structure to facilitate this, recommending that IT goals are set at three levels: for IT overall, for IT processes, and for the activities within IT processes. By using COBIT’s goal-definition process an organisation is able to create a performance measurement framework that not only ascertains performance outcomes against the desired goals but also offers a basis upon which to drive performance improvement activity. It has the additional ability to ensure that ITIL-based Continual Service Improvement is focused on appropriate processes and activities to deliver the greatest positive impact in respect of business goals.

Process Maturity Assessment

COBIT recognises that different IT organisations are at differing levels of IT and ITSM process maturity; not only from a holistic perspective but also at an individual process level. It provides a maturity model for each IT process, enabling management to benchmark the organisation’s activities against good practices – identifying deficiencies and areas for improvement.

Process Design

ITSM processes should always be tailored to the organisational needs of the enterprise, and hence organisations also need to take an ‘adopt and adapt’ approach with COBIT and ITIL good practices – such that they are both practical and in tune with corporate objectives. In doing this an organisation will notice, if they haven’t already, that ITIL provides guidance on how processes and procedures should be designed whereas COBIT helps to define what should be included within them. Even if an organisation is not designing ITSM processes from scratch, alternatively adopting and adapting from consultant-provided best practices say, it is still worth checking existing process control points against COBIT to ensure the adequacy of internal controls and highlight control-based activities for future corporate compliance initiatives.

Role Accountability

For each IT process, COBIT defines a generic Responsible, Accountable, Consulted, and Informed (RACI) chart, a management model used to help define roles and responsibilities. Each RACI chart highlights the key activities in the process and the responsibilities of individual roles (or role types) to provide an essential element of IT governance. The COBIT RACI charts should be tailored to organisational ITSM processes and roles to supplement existing, probably less-focused, role or job descriptions. They should ensure that both the individuals fulfilling the roles, and those that are dependent upon the activities of these people, know exactly where responsibility and accountability lies.

Assurance Provision

The integration of COBIT with ITIL processes not only allows management to improve processes and control-based elements, it also helps to demonstrate the level of IT governance. With the utilisation of an industry standard set of controls (and common terminology) facilitating the provision of assurance to both internal and external assessors, this potentially reduces the time and effort required from both operational staff and assessors in completing compliance-based initiatives.

ISACA/ITGI’s Aligning COBIT 4.1, ITIL v3 and ISO/IEC 27002 for Business Benefit document provides a bi-directional mapping between COBIT and ITIL. Examples relate to a subset of Service Desk and Incident Management activities: COBIT’s Deliver and Support (DS) – DS8 Manage Service Desk and Incidents, and ITIL v3 Service Operation (SO) Incident Management. Table 1 (removed) details examples of COBIT to ITIL mappings and Table 2 (removed) the reverse.

The mappings can then be used to drill down from the COBIT Control Objectives into specific Control Practices to beef up existing, or proposed, ITIL processes in order to help achieve effective IT governance (the practices are detailed in ‘COBIT Control Practices: Guidance to Achieve Control Objective for Successful IT Governance’). These can be used to create specific process control points that an organisation can measure compliance against. Examples, in the context of the above, are ‘progress in addressing issues identified is tracked to completion’, ‘issue trends are analysed periodically to identify underlying issues and initiate remedial action to address them’, and ‘there is a process for responding to (and where necessary escalating) incidents on a timely basis’.

Not all the COBIT Domains map onto ITIL. There is no reason why, however, an organisation cannot utilise COBIT’s supporting Control Objectives within these Domains to further improve business alignment and IT governance.

So, to summarise, used together ITIL and COBIT can provide the necessary framework of good (or best) practices that enables an IT organisation to visibly align itself with the goals of the business, and effectively manage its resources to enable these goals through the optimised delivery of organisation-needed information and business-enabling IT services.

Republished from


Project Portfolio Management Best Practice

As IT functions are increasingly expected to ‘deliver more with less’, portfolio management tools and techniques are required to reconcile corporate strategy and scarce IT resources, and facilitate better decision-making across the enterprise. Importantly, portfolio management can help address two of the key challenges facing CIOs in 2009 and beyond – reducing IT costs and demonstrating the value IT delivers to the business.

Since Henry L. Gantt developed the Gantt chart in 1917, corporate project management activities have been supported by a variety of tools and techniques. Most recently, with organisations subject to an increasing variety of corporate pressures and constraints, the portfolio-based management of projects has become a corporate necessity. It is driven by increased business demand for technology investment, growing complexity of business and IT operations, and the need to provide governance-dictated transparency.

The corporate adoption of Project Portfolio Management (PPM) delivers a framework of policies, processes, and enabling technology that can help organisations to prioritise and manage the utilisation of scarce corporate resources against organisational need. It is an essential element of IT Governance that can help to minimise risk and maximise ROI, and assist an organisation in selecting the right blend and balance of investment. PPM can also help boost corporate productivity by formalising workflows and improving collaboration across the enterprise.

When introducing portfolio management, an organisation must realise that it is no different from any other corporate change project, with associated risks that need to be closely managed. These include the failure to gain business buy-in (from the board through to users), a lack of understanding of the business objectives for portfolio management (across the enterprise), the procurement of a PPM tool that doesn’t meet business needs, and not considering the bigger picture – potentially creating a clumsy add-on to existing business processes and a ‘garbage in, garbage out’ scenario. The failure to address these risks will ultimately result in poor corporate adoption and the inability to deliver against change projects’ stated benefits.

An organisation can maximise its chances of success by following five PPM best practices: building the right portfolio management foundations, realising the importance of PPM tool selection, thinking beyond the technology and processes to address people factors, closely managing PPM-specific change risks, and applying sufficient focus to analytics given that PPM is not just about improving project control and delivery.

Build Strong PPM Foundations

In building the right foundations for the introduction of portfolio management, an organisation must understand its own business drivers for portfolio management. Which business issues and pain points will it address? It is only then that IT is able to start to sell the benefits of PPM to the business, across all stakeholders; not only ensuring that there is a consensus as to the need for PPM but also ensuring that there is a common understanding as to why it is needed and what it will deliver. Butler Group cannot overstate the criticality of senior management and board-level buy-in and that without this any corporate PPM initiative will probably fail.

In doing this, an IT organisation must identify real business benefits that resonate amongst key stakeholders. This will include the definition and quantification of both the quantitative and qualitative benefits to be realised from the deployment of PPM tools and techniques. It also needs to introduce a robust benefits realisation tracking framework so that success can be reported against critical success factors and key performance indicators (including increased ROI), importantly ensuring that both financial and strategic value can be demonstrated.

In addition to looking forward to the new PPM-enabled state, an IT function also needs to take a step back to look at what its organisation is already doing in the project management arena. Without this an organisation will effectively be trying to implement PPM in isolation, without the necessary level of business alignment and without the opportunity to ensure that PPM is introduced on top of a consistently used, fit-for-purpose project management methodology. Badly managed projects will still be badly managed projects with PPM, the difference being that the level of project mismanagement will be far more evident to the business.

Whilst PPM will help to resolve project mismanagement in the medium-to-longer term, there is the very real risk that poor project management will negate the stated benefits of the PPM initiative, particularly when considering the old adage of ‘garbage in, garbage out’.

Select the Right PPM Tool and Vendor

As with the introduction of most new technologies, an organisation must ensure that the business is driving the technology and not the other way round. In Butler Group’s opinion, the successful introduction of PPM is dependant on the selection of the right software tool, with the tool needing to integrate with the rest of the business from both an organisational and technical perspective. A tool with the ability to offer scalability and flexibility (it must be able to grow as both the business and its PPM activities grow) and should not require a disproportionate level of customisation (and the complexity this brings).

Unlike more traditional business technologies, a new PPM tool is probably not supporting a raft of existing business processes. One could argue that this is good from a ‘greenfield’ perspective; however, the creation of corporate PPM from scratch (even if via a benchmarking exercise) may add unnecessary complexity to a PPM-driven change project. Alternatively, an organisation needs to look at the procurement of a PPM tool as more than just obtaining the required software, and also assess the value the vendor can bring.

Hence, the creation of a solution/vendor shortlist should not only include requirements relating to portfolio management functionality and standard criteria such as inter-process integration, interoperability with existing IT and management software, technical requirements, supplier background, implementation parameters, and support and maintenance arrangements. They should also reflect the fact that potential PPM vendors can deliver much more than just the technology, and assess vendor knowledge, services, and experience (such delivery methodologies and the provision of best practice frameworks and processes) that can be leveraged in the creation of the required corporate PPM ecosystem.

Address People Factors

As with the introduction of many new technologies and processes, addressing people-related factors is crucial to success – technology and processes don’t usually fail by themselves. Employees are one of the key stakeholders that need to buy-in to the corporate PPM initiative and must be involved, and communicated to, throughout the life of the change project. They need to understand why both they and the organisation need to use portfolio management and how it fits into the bigger picture of IT and Corporate Governance. Importantly, PPM needs to be integrated into, and not viewed as an add-on to, existing working practices and procedures. The PPM change project must address people issues through a focus on usability, such as the delivery of in-process training, and realise that if a PPM tool is too difficult to use, or requires people to radically alter the way in which they work, then PPM will ultimately fail.

Closely Manage PPM-specific Change Risks

Big bang approaches are often inappropriate for PPM deployments; alternatively an organisation must ensure that their choice of vendor and tool will deliver the right speed of change. Vendors must balance organisational needs with benefits realisation, avoiding common implementation pitfalls, and resulting in a business-integrated solution. To help minimise the risks associated with an implementation of a PPM change project, Butler Group recommends that an organisation starts with a Proof of Concept (POC) or takes a phased delivery approach, and uses a low-risk environment to understand all the people, process, and technology changes required to achieve a successful PPM deployment.

An organisation should also consider using SaaS delivery, at least to begin with, to shorten the time-to-value and minimise cost, risk, and change effort. Having said this, whilst demonstrating a speedy ROI is critical (particularly in the current business climate), it is vital that an organisation manages the speed of change, based on its level of maturity and ability to handle change, remembering that it is the business’ change not the vendors. Importantly, an organisation should start small and build on its successes; where necessary this will help to continue to sell the benefits up through the enterprise.

Focus on Analytics

Whilst better control over, and visibility into, project expenditure is a much needed corporate facility, PPM is not just about improving project management and delivery – information exploitation is also key. A PPM tool’s analytics functionality is vital to an organisation wishing to realise the full business benefits of portfolio management. A procuring organisation must therefore ensure that potential PPM tools have the depth and breadth of analytics to meet all its business needs, across a wide spectrum of business users.

User requirements will not only vary by corporate role, but also be based on personal information interpretation styles. A suitable PPM tool should provide facilities that ensure that all types of user can, and want to access the dashboards, reports, and scenario/what if analyses they need to make effective business decisions. The analytics should also be readily available outside of the PPM tool given that not all potential recipients will have access to the technology, particularly third parties. Additionally, where some users, such as senior business people, may only require access to the information layer of the PPM ecosystem, a best of breed PPM tool will offer access to dynamic analytics outside of the core PPM technology, providing users with real-time access to project- and portfolio-related information from within alternative clients such as Microsoft applications.

In summary, for an organisation to maximise the probability, and level, of portfolio management success, it should ensure that it prepares well, can readily demonstrate benefit delivery, actively involves its people, selects the right PPM tool and vendor, starts small and builds on its successes, and ultimately manages at its own pace.

Republished from

Practical Problem Management

For many organisations Problem Management is somewhat of a poor relation to corporate Service Desk and Incident Management activity. Whilst the Service Desk and Incident Management processes are adequately staffed, defined, and operated, Problem Management is often ‘something to be done when time allows’. Consequently, Problem Management may never rise to the top of the IT Service Management (ITSM) ‘to do list’. Even if an organisation undertakes reactive Problem Management in response to a Major Incident, say, proactive Problem Management (where dedicated resource actively identifies problems) may never receive due attention. Interestingly, of the major ITIL processes, effective Problem Management activity can provide the highest return to an organisation.

One possible cause of corporate inattention is that problems are often confused with incidents (with the terminology interchanged wrongly), or are seen as an incident state rather than a separate entity requiring a different type of ITSM response. The ITIL definition of a ‘problem’ is the cause of one or more incidents, with Problem Management the process of managing all problems throughout their lifecycle. The process’s primary objective is to prevent problems and resulting incidents from occurring, to eliminate recurring incidents, and to minimise the impact of incidents that cannot be resolved (referred to as known errors within ITIL). In order to achieve this goal, Problem Management must get to the root cause of incidents and then initiate actions to improve or correct the situation.

A practical way to differentiate between problems and incidents is to view an incident as a symptom that is resolved when normal operation (from a customer perspective) is restored. However, a problem is the root or underlying cause of an incident or incidents that is resolved only when the underlying cause is permanently rectified. In ITIL v2, Problem Management was a part of Service Support; in v3, it is now part of Service Operation and, due to conflicting priorities, Butler Group recommends that an organisation treats Incident and Problem Management as separate processes with different process managers.

Problems can be identified just about anywhere within the IT ecosystem: acceptance into production, changes, updates/patches, vendor products, user errors, production execution, and failures. However, the main source for problem identification with an organisation will probably be the analysis of incidents as part of the proactive Problem Management process. Problem management resource should regularly analyse incident and problem data, identifying trends and reporting them, along with problem management metrics and success stories, both within and without the IT function.

For effective Problem Management, the problem management team must provide problem control, which is a process of problem identification and recording, problem classification, problem investigation and diagnosis, and actively tracking problem status through to resolution or known problem/error status. Unfortunately, many organisations fall down at this first hurdle, with IT support attention so focused on incident resolution that it is in a perpetual state of ‘bailing water out of an overflowing bath’ rather than looking to ‘turn off the taps’.

IT management needs to appreciate that far too much costly, and possibly scarce, IT resource is spent fighting repetitive fires and that this resource would be better utilised supporting problem management personnel in tackling the root causes, rather than the symptoms, of IT failures. Outside of the IT function, the business impact of problems, in the form of recurring incidents, can be considerable in terms of lost user productivity or, more importantly, the financial implications of outages to critical business services, and degradation of both customer perception and the reputation of the corporate brand.

For some IT organisations, providing resource for Problem Management activities may be easier said than done. Rather perversely, IT needs to undertake some initial Problem Management activity in order to justify longer-term activity. The analysis of Incident Management data and conversations with key customers will help identify a sample of problems that will allow IT to establish the business-wide costs associated with recurring incidents. When compared to the costs associated with undertaking Problem Management activities, the organisation is able to isolate the potential benefits to be realised through the proactive resolution of problems. In the current financial climate it may be necessary for IT organisations to use this information to justify a short-term proof of concept project that can formally demonstrate benefit delivery.

Importantly, organisations shouldn’t try to do too much too soon. Resource should be focused on a prioritised set of initial problems with activity ramped up as successes are achieved. IT also needs an initial Problem Management strategy that is focused on planning, and delivering, services that are closely aligned to business requirements. This business-oriented approach will help keep IT grounded in the real reasons for Problem Management and away from a perpetual state of ‘analysis paralysis’.

When justifying the adoption of Problem Management to the business, IT should also make it clear that the process works with existing Incident and Change Management processes to ensure that IT service availability and quality are increased. That over time, Problem Management will identify permanent solutions and reduce the number and resolution time of incidents; resulting in less downtime and disruption to business-critical services, reduced expenditure on ineffective workarounds or fixes, and a reduction in the cost of, and effort in, fire-fighting or resolving repeat incidents.

Once an organisation has corporate commitment to problem management resource, it must ensure that they have cradle-to-grave processes formalised right across the problem lifecycle. The operation of the aforementioned problem control process will result in one of three outcomes; that a change is required to correct a problem, a problem cannot be fixed but a workaround has been identified, or no fix or workaround have been identified. In the first instance, the organisation should use an error control process to correct the problem via the corporate Change Management process. In the second instance, the problem is classified as a known error with a workaround – a temporary way of resolving the incident – logged in a known error database and made available to all support teams for ongoing incident resolution activity. Finally, where a problem has been investigated but no solution or workaround identified, this is recorded as a known problem; with the information again made available for the benefit of all support teams. It is important to recognise that these three problem states are not mutually exclusive and that a problem may move between them over time. For instance, when possible, a workaround should still be made available whilst a problem is awaiting the implementation of a required change.

There are a multitude of available problem management tools and techniques to facilitate problem resolution. These include Kepner-Tregoe, Ishikawa diagrams, Component Failure Impact Analysis, Fault Isolation, Technical Observation Post, Fault Tree Analysis, problem brainstorming, CRAMM, trend analysis, chronological analysis, and Pain Value Analysis. Kepner-Tregoe is a useful method of problem analysis for formally investigating deeper-rooted problems and includes the following high-level stages: define the problem; describe the problem in terms of identity, location, time and size; establish possible causes; test the most probable cause; and verify the true cause. Ishikawa diagrams document the causes and effects of one or more incidents. Typically the outcome of a brainstorming session, the problem is represented as the trunk of a ‘tree diagram’ with causes shown as primary and then secondary branches. Creating the diagram stimulates discussion and often leads to increased understanding of complex problems.

As with all processes, the efficient and effective operation of Problem Management requires fit-for-purpose performance metrics. For example, critical success factors include visibly improved service quality, problem cost and productivity impact minimisation, and the reduction in the cost of problem management. These should be supported by a basket of appropriate KPIs such as trend-based, percentage reduction measures in the average time to resolve problems, the average time to implement fixes to known errors, the average number of undiagnosed problems, the number of repeat incidents, the number of incidents and problems affecting business-critical services, and the average cost of handling a problem. Or qualitative measures such as improved customer satisfaction responses relative to business disruption caused by incidents and problems, and volume-based measures such as the total number of problems recorded in the period and the number of problems not resolved within SLA targets. All metrics should be reported by problem category, impact, and priority-level, and trended over time.

Problem Management should have strong relationships with other key ITIL processes. In addition to its linkages with Incident and Change Management, it needs to use Configuration Management data to help determine the impact of problems and resolutions. Availability Management has a dependency on Problem Management information and activity, and some problems will require investigation by Capacity Management teams and techniques. Problem Management can also be an entry point into IT Service Continuity and Major Incident Management, where a significant problem is not resolved before it starts to have a major impact on the business. From a Service Level Management perspective, Problem Management contributes to improvements in service levels, and its management information should be used as the basis for SLA review activity.

To conclude, Problem Management is critical to efficient and effective IT operations and an organisation should seriously look at why it hasn’t formally adopted Problem Management policies, processes, and techniques. The hurdle probably isn’t the process itself, given that it is relatively straightforward when compared to most ITIL processes. It is more likely that suitable resource has never been justified for an activity that can be perceived as distant from day-to-day IT operations. Whilst the justification of dedicated problem management resource may at first appear daunting, the same was probably once true for the provision of Service Desk facilities. The analysis of corporate incident management data should support the need for the proactive management of recurring incidents within most organisations. Go on, do some digging; you might just make IT’s and your customers’ lives a lot easier.

Republished from