Building Acceptance and Adoption of Governance of Enterprise IT

“Building Acceptance and Adoption of COBIT at Sun Microsystems” is the title of an article published in the ISACA Journal in 2005. Much has happened since then, including the acquisition of Sun Microsystems by Oracle Corp. And, in all that time, the light has kept shining on COBIT, and the COBIT/governance champions have continued to drive the acceptance and adoption of COBIT and the governance of enterprise IT (GEIT).
During that time, the enterprise has enjoyed some successes and learned some valuable lessons along the way. The following are the key lessons learned:
1. Understand the target. COBIT is not the target. The target is improved governance and management of the enterprise’s IT. To do so means adopting, leveraging and implementing the industry-accepted concepts and practices that are embedded in COBIT. COBIT provides the overall framework, but when it comes to execution, the enterprise must dive deeper into those concepts and practices.
2. Use the COBIT umbrella. COBIT is the end-to-end umbrella framework. The enterprise developed a presentation that showed how the most common industry-accepted frameworks/methodologies/practices complement each other.1 It is a little dated because of the updates to some of the frameworks that have taken place, but it still tells the story. COBIT goes a long way in harmonizing the many frameworks. This is important and incredibly valuable in dealing with the many IT specialties. Specialists are very good at what they do. Service management professionals manage, and, for most, their preferred guidance is ITIL. Security professionals protect, and, for many of them, the preferred guidance is the ISO/IEC 27000 series. By using a COBIT-inspired model, all groups were able to see how their work fit under an overall umbrella and how their work related to each other’s work.
3. Stay focused. Improving the governance and management of enterprise IT is a journey, not a destination. Some enterprises want to focus on the short term. That is fine as long as it is in the context of the longer-term direction. Related to this is the worry among some employees that COBIT will be replaced within the enterprise in a year or so by something else that might be the “hot topic” in the management world. Two things are helping to avoid that. First, the enterprise has a COBIT/governance champion, who keeps an eye on where the concepts in COBIT can add value. Second, the enterprise is not implementing COBIT per se, it is implementing improvements to how it governs and manages the IT contribution to the enterprise, and COBIT is the guiding framework.
4. Use it all. COBIT and all the COBIT collateral, including Risk IT and Val IT, provide an amazing body of work. There are golden nuggets throughout all of the material. By having someone who has an in-depth understanding of the COBIT material, a COBIT champion, the organization can get really serious about improving governance and management of enterprise IT. For instance, Sun/Oracle has found the mapping documents very helpful when talking about how the various frameworks all fit together. Sun/Oracle embraces ITIL as well, and has had some success using the COBIT User Guide for Service Managers.
5. Avoid common mistakes. Using the Sun/Oracle experience, and after consulting other organizations that are undertaking implementations of governance of enterprise IT using COBIT, some common reasons that implementations fail have been identified. As may be expected, they fail for many of the same reasons that other transformational change efforts fail.2
The following are some specific examples of how Sun/Oracle has successfully leveraged the concepts in the COBIT-related materials:
1. Sun/Oracle leveraged the IT Assurance Guide: Using COBIT to create a discussion worksheet for process health and maturity self-assessments. It is a two-part document. The first part applies to all processes and addresses the six generic process controls. The second part addresses the controls specific to each individual process. Sun/Oracle uses the input and output tables to identify key boundary processes. This ensures that the enterprise has key stakeholders from these processes involved in the discussion. The focus of the facilitated discussion is the process’s current state and the business impact of that state. The discussion of the business impact is influenced by the business objectives. Sun/Oracle uses the goals cascade in COBIT (appendix A and the management guidelines) to help provide a line of sight between its activities and its business goals. The enterprise can then step easily into a maturity assessment of the process using the maturity attributes (figure 15 of COBIT 4.1). 3
2. To bring predictability and reliability to how the IT group plans and manages the work across the enterprise, the group leveraged many of the concepts embedded in the COBIT framework portion of the COBIT 4.1 publication. The group needed a way to operationalize the Plan-Do-Check-Act (PDCA) concept at the IT organization level. The enterprise had a corporate planning cycle, and the IT group created the “IT management cycle” to complement that corporate activity. Figure 1 shows how the IT management cycle is represented; elements have been drawn from COBIT and other complementary frameworks. (Note: MRP is budget-related.)
3. It became useful to demonstrate what the enterprise must do to achieve integration and alignment of the governance/management activities. Figure 2 is a matrix that helped Sun/Oracle do just that. It combines the IT management cycle with the IT governance focus areas. The key message is: Both vertical and horizontal integration and alignment of the activities are necessary.
4. From time to time, the IT group revisits the components of governance of enterprise IT as described in COBIT: leadership, organizational structures and processes. The enterprise decided to focus on the organizational structures and has found that it has done a pretty good job with the vertical structures (the traditional who reports to whom), but has not focused sufficiently on the necessary horizontal (or lateral) structures. This led us to two new internal rules:
o Horizontal organizational structures (i.e., a risk council or information security community) must be as deliberately thought through as the vertical structures of the organization.
o When a decision is made to form a horizontal structure, it must have a well-defined charter that includes the mission or purpose of the group, the composition and the decision rights.