CHAPTER 7: IMPLEMENTATION OF GEIT WITH COBIT 5
‘The value of an idea lies in the using of it.’
Thomas Alva Edison (1847-1931)
This chapter looks into the approach to implementation of Governance of Enterprise IT (GEIT) based on COBIT 5.
It is important to recognise there is not a mandatory approach to the implementation of GEIT – but the COBIT 5 books do provide sound guidance on approaches to consider, as well as discussion of difficulties that may arise and methods of avoiding or overcoming these. The key point to recognise is that governance and management of enterprise IT must be specific to your enterprise and that means analysis must be conducted with stakeholders, a business case must be devised, approval gained from senior management and an implementation programme devised and executed. Further, COBIT 5 is not the sole good practice as is well recognised by ISACA, despite the labelling of COBIT 5 as ‘the only business framework for GEIT,’ COBIT 5 is not only based on more than 80 other frameworks and standards as discussed in Chapter 2 but also some of these frameworks, standards and good practices may already be in place and the enterprise needs to build on these. Common examples of good practices already in place in many enterprises today are ITIL, ISO20000, PRINCE2 or PMBOK®, ISO27001 and ISO9001.
Guidance on the implementation of GEIT using COBIT 5 is provided by ISACA in an outline in Chapter 7 of the book COBIT 5: A Business Framework for the Governance and Management of Enterprise IT. Detailed guidance is provided in the COBIT 5: Implementation guide.
Understanding the Enterprise
Many readers of this book are likely to have been employed in their enterprise for many years and so will have a strong understanding of their operations. Consultants who visit enterprises to assist with GEIT implementation will initially conduct activities to understand the enterprise. Areas to understand are:
Key areas
• Mission, vision and values (aka principles): already formally defined in most enterprises.
• Governance policies and practices: usually many of these already exist.
• Ethics and culture: not always formally defined but in many enterprises most staff already are aware of corporate ethics and certainly have personal ethics.
• Business strategy and plans: usually formally defined but periodically these are transformed to meet PESTLE79 changes. Another key change factor that motivates strategic change is competitor products or services already in place or being developed.
• Risk appetite: often understood, but not always formally defined. Changes to risk appetite occur for specific key projects – for example, more risk may be taken in developing a new product or service but a capped budget is used to contain the risk80.
• Industry practices: specifics that relate to the industry sector such as robotics in car production and highly sophisticated computer-based information systems now required in the car itself.
• Regulatory and statutory requirements: a constantly growing set of requirements including Data Protection legislation, Health and Safety legislation, Waste Electrical and Electronic Equipment (WEEE) directive (2002), Sarbanes-Oxley Act (2002), Basel II and III, Solvency II and Corporate Governance Codes.
Other important areas
• Operating model and level of maturity: the business processes that are dependent on people, processes and technology and how well these are currently operating from internal or external assessments.
• Capabilities and available resources: skills, expertise, experience and sufficient numbers of people to structure, organise and run the business and adequate resources such as facilities and equipment to operate successfully and, of course, budgets to fund everything.
Factors for successful implementation
It is extremely important to gain the support of Board members or top management because without their desire to have governance of enterprise IT in place, coupled with their commitment to support the implementation programme, then it is unlikely to be truly successful. In addition, key stakeholders need to support the GEIT programme too.81 The programme to deliver GEIT needs to be communicated regularly to all types of audience to motivate people to adopt the desired changes. Building on existing good practices is vital to move to implementing the required enablers of COBIT 5 to deliver GEIT that fits the nature and desires of your enterprise. As with any programme, it is vital to implement quick wins, that is, relatively easy initiatives that can be implemented quickly in an attempt to secure support, fend off concerns at delays and also communicate success that will encourage participation in subsequent implementation stages.
Important factors that assist with gaining the support and commitment of board members, top managers and key stakeholders are to understand the pain points and triggers. Pain points are difficulties the enterprise is experiencing that are impacting its ability to successfully meet its business outcomes. Triggers are important changes that are taking place or need to take place. Table 7.1 lists examples of key pain points and triggers. Appendix A of COBIT 5: Implementation provides mapping of pain points to COBIT 5 processes, giving guidance on processes that are likely to be important to implement to overcome the pain points. For example, the pain point ‘Outsourcing service delivery problems’ may be overcome by implementation of EDM04 Ensure Resource Optimisation, APO09 Manage Service Agreements and APO10 Manage Quality.
Table 7.1: Pain Points and Triggers to Assist Implementation of GEIT
Another important approach to take into account when implementing COBIT 5 is to use the COBIT 5 Goals Cascade (see Chapter 4) to link stakeholder needs to business goals to IT-related goals to COBIT 5 processes and hence identify key processes to implement.
In addition, risk scenarios can be used to identify key COBIT 5 processes that can assist with risk management. Appendix C of COBIT 5: Implementation tabulates three key areas of risk:
• benefit/value enablement risk
• programme/project delivery risk
• service delivery/IT operation risk.
And each area identifies many risks such as:
• incorrect technology selection in terms of cost, performance features and compatibility
• insufficient quality of project deliverables
• intrusion of malware on critical operational servers and/or laptops.
It then shows against each risk the COBIT processes that are capable of assistance. For example, the risk of intrusion of malware on critical operational servers and/or laptops can be controlled with the COBIT 5 processes:
• APO01 Manage the IT Management Framework (using management practice APO01.08 Maintain compliance with policies and procedures).
• DSS05 Manage Security Services (using management practice DSS05.01 Protect against malware).
Lifecycle Approach to Implementation
Experts in the field of governance of enterprise IT have worked on how to use COBIT to implement IT governance since before 2003, the era of COBIT 3, when ISACA first published its IT Governance Implementation Guide. There have been three completely new editions of ISACA guides to GEIT implementation as ISACA introduced new versions of COBIT and other frameworks such as Val IT™. Experience of best practice grew as implementations were conducted and expertise grew. The current edition, COBIT 5: Implementation, is based on a lifecycle approach of seven phases that is neatly presented as a radar-style diagram (Figure 7.1).
The seven phases of the lifecycle are based on the approach used by Kotter (1996)82 for the implementation of change known as his ‘8 steps for transformation’. Kotter’s approach is also used for ITIL implementation, although ITIL does not include the broad range of concepts that COBIT 5 has adopted.
Figure 7.1: Lifecycle for Implementation of IT Governance Using COBIT®5 (© 2012 ISACA®)
The seven phases are listed in Table 7.2.
Table 7.2: Phases of the COBIT®5 Implementation Lifecycle
| Implementation Phases | |
| 1 | What are the drivers? |
| 2 | Where are we now? |
| 3 | Where do we want to be? |
| 4 | What needs to be done? |
| 5 | How do we get there? |
| 6 | Did we get there? |
| 7 | How do we keep the momentum going? |
Each implementation phase requires three separate but linked areas of activity to be covered together; shown as concentric bands of separate colours in Figure 7.1. These are:
• Programme management – a programme of projects Change enablement – cultural and behavioural changes needed
• Continual improvement lifecycle – details of improvement activities.
All three of these activities must be collectively conducted in each lifecycle phase as shown in Table 7.3.
Table 7.3: Relationship Between Activities that Should Take Place Within Each Phase
It is important to recognise that continual improvement happens throughout the implementation lifecycle; not solely after the implementation has been completed.
Each phase of the lifecycle is formally explained in detail in Chapter 6 of COBIT 5: Implementation in terms of the following areas:
• Phase objective and description
• Many tasks: separately listed for PM, CE and CI
• Inputs and outputs.
For each phase of the lifecycle, roles and responsibilities need to be allocated to staff covering the activities of programme management (PM), change enablement (CE) and continual improvement CI. Chapter 6 of the COBIT 5: Implementation guide provides a RACI chart for each lifecycle phase with detailed descriptions of roles and responsibilities for each activity conducted. A summary of these roles and responsibilities is provided in Table 7.4.
Table 7.4: Roles and Responsibilities in Implementation Lifecycle Phases
A = Accountable R = Responsible C = Consulted I = Informed
Notes:
Board does not have a role in Phase 4, although some Boards may expect information.
Only a single role should be accountable for an activity in a phase.
Several activities take place in each phase, which is why more than a single role has A.
The other key requirements in the implementation lifecycle are to recognise that in each phase there are several challenges to overcome such as:
Phase 1: Lack of senior management buy-in, commitment and support.
Phases 2 & 3: Cost of improvements outweighing perceived benefits.
Phase 4: Resistance to change.
Phase 5: Trying to do too much at once; tackling overly complex and/or difficult problems.
Phases 6 & 7: Difficulty in showing or proving benefits.
The guide, COBIT 5: Implementation (Chapter 4), tabulates 21 challenges in total and with each challenge provides many causes coupled with recognised advice on techniques to use to overcome each challenge.
Finally, one of the key parts of the Implementation Lifecycle Phase 2: Where are we now? is assessment of the current state, a CI activity. A key part of this assessment is to determine the ‘as-is’ state, particularly of key COBIT 5 processes that the enterprise has decided are needed to implement GEIT. Then the gap between the ‘as-is’ state and the ‘to-be’ state can be determined to plan the implementation activities. Assessment of processes has been conducted in earlier versions of COBIT using CMM® or CMMI® (see Chapter 2). However, in COBIT 5, this has been switched to using the international standard ISO/IEC 15504 Software Engineering – Process Assessment Model and this and the method of using it is discussed in the next chapter.
_______________
79 Politics, the economy, social changes, technology changes, legal changes and the emerging need to obey statutory environmental controls coupled with a desire to ‘save the planet’.
80 An interesting example of risk appetite many of you will be familiar with is Red Bull acting as the sponsor for the Red Bull Stratos project (2013) for Felix Baumgartner’s skydive to the surface of the Earth from 39km (24 miles) into space. Red Bull sees itself as a company supporting and participating in extreme sports such as Formula 1 (motor racing) that align well with its energy drink. Although Project Stratos was a big risk, from Red Bull’s viewpoint it fitted its brand and certainly gained international publicity (eight million viewers), and some financial pundits say it has already raised tens of millions of dollars from global exposure of its brand and it was the most money-earning marketing stunt ever. However, the project, which ran for seven years, had a constrained budgetary limit, initially $1M, but this was greatly extended to address technical difficulties with equipment design and according to some media articles was about $50M in total.
81 Take care not to select key stakeholders who only want to be on an e-mail distribution list so they know what is happening rather than they have a commitment to participate regularly in programme activities and are keen to allocate their staff to assist, too. Gain opinions from others about proposed key stakeholders – not easy to achieve without upsetting people and losing support, however.
82 Kotter, J. P. (1996), Leading Change, Boston, Harvard Business School Press.