JOnline: IT Governance—Practical Case Using COBIT 

Download Article

In this project, the COBIT model was used in combination with COBIT QuickStart and the Gartner approach for defining priorities for IT projects based on the company strategy.

The following phases have been performed in this project:

  • COBIT QuickStart assessment
  • Presentation to the board and decision of priorities
  • Setup of an IT business steering committee
  • Development of the handover procedure from the project team to operations
  • Business process modelling

This project started as an initiative taken by IT management and the company chief executive officer (CEO) with the objective to optimise the processes within the IT department and clarify these processes to the business units.

As a result of the work performed within the IT department, the organisation realised the need for identifying and developing its own business processes (last phase described in this article). This initiative was fully supported by the president of the board and the CEO; their support had a positive influence on the involvement of the business units at all levels (from director to the employee) and improved relations between IT and the user departments.

The following sections describe the different steps executed in the project. The last step, development of the business processes, is ongoing.

COBIT QuickStart Assessment

The project started in February 2004 with an assessment of the suitability of COBIT QuickStart for this company.

As recommended in the QuickStart guide, this suitability assessment was executed by means of a discussion with the chief information officer (CIO), who gave the answers to the questions in Figure 1.

The outcome of the first assessment, ‘Watch the Heat’, is shown in Figure 1.


The second step of the suitability assessment is the ‘Stay in the Blue Zone’ assessment. The results obtained from asking the related questions are shown in Figure 2. For the ‘Stay in the Blue Zone’ assessment, this company definitely did not stay in the blue zone for four out of seven criteria, and the result of the ‘Watch the Heat’ assessment indicated four red indicators. The immediate consequence was that COBIT QuickStart is not entirely applicable in this environment, since the assessment highlighted the strategic importance of information and communications technology (ICT) within the company.


Despite this result, IT management decided to continue with the QuickStart approach. This limited the scope of the first assessment, which was executed immediately after the suitability assessment, and also reduced the number of control objectives the organisation had to take into consideration when defining the IT governance implementation approach.

In this way, COBIT QuickStart was taken as a first step toward the full COBIT approach.

The QuickStart assessment was executed by means of interviews with the IT management team. The result was documented in the QuickStart assessment form (figure 3), where the capability maturity levels were used, instead of the seven levels described in the QuickStart guide.


Presentation to Board and Decision of Priorities

After the QuickStart assessment, a plan was developed with possible improvement actions. A meeting was scheduled to present the plan to the board.

The overall purpose of this meeting was:

  • General introduction of IT governance
  • Specific proposal for IT governance at the organisation
  • Decision on the priorities for the proposed improvement actions

At this point, it was important to make clear the responsibilities of the different hierarchies in the company. Therefore, in this meeting, stress was laid on the responsibilities of the different levels in the organisation.

General Introduction of IT Governance

In this introduction, the following topics were clarified:

  • Definition of IT governance
  • Advantages for the stakeholders
  • Why the organisation needs IT governance
  • What the board and management can do about IT governance
  • Short explanation of COBIT framework

Specific Proposal for IT Governance at the Company

The proposal included improvement actions in two dimensions:

  1. Internal IT project
    • IT strategy and objectives:
      • Align with the corporate strategy and objectives.
      • Reference the Plan and Organise domain of COBIT.
    • Develop IT processes and procedures:
      • Determine priorities based on the COBIT QuickStart assessment and the IT strategy and objectives.
      • Refer to ITIL processes.
    • Handover from development to operations:
      • Define the tasks and responsibilities.
      • Determine the levels of collaboration and involvement during the development cycle.
      • Start with support in the handover of ongoing projects.
    • Collaboration with research and innovation:
      • Define roles and responsibilities.
      • Determine how to collaborate with the existing organisation.
      • Determine how to align with the business and the IT strategy.
      • Determine how to organise communication between the business and reporting to the board of directors.
  2. External IT project (where the business is involved)
    • Purpose of IT business steering committee:
      • Follow up and direct the IT strategic plan.
      • Minimise the risks related to the investments.
      • Prepare the budget for 2005 (this was the first time that a budget exercise, specific for IT projects and investments, was executed).
      • Define measurable objectives and manage their follow-up.
    • Tasks of IT business steering committee:
      • Select and approve IT projects and define the priorities.
      • Follow up on the status of these projects.
      • Take the required measures, if needed.
    • Roles and responsibilities:
      • Determine the role of IT—driver/enabler/service provider—for all departments.
      • Determine the role of the board of directors and management.
      • Define these roles related to the management of IT projects and the decision-making process.
    • Project portfolio management:
      • Define the scope of portfolio management.
      • Provide input for the IT business steering committee.
      • Ensure that it is comprised of criteria to determine priorities and a method for planning, reporting and follow-up.
    • Optimise communication:
      • Formulate regular and clear objectives of communication (two directions).
      • Evaluate the necessity for a customer survey.

Decision on the Priorities for the Proposed Improvement Actions

After a profound discussion, the board decided to give priority to the following two improvement plans:

  • Handover from development to operations
  • IT business steering committee

The reasoning behind this decision, as the president of the board formulated it, was ‘to optimise the communication at the different boundaries: internally within the IT department (between development and operations) by developing the handover procedure and externally (between the IT department and the business departments) by establishing the IT business steering committee’.

Establishing the IT Business Steering Committee (ITBS)

To define the function of the IT business steering committee, a meeting was organised with the directors of all business units. The outcome of all these interviews was consolidated in a document called ‘The Functioning of the Business Steering Committee’.

The main topics of this document are:

  • Why is an ITBS needed?
  • Who are the members of the ITBS?
  • Which type of projects will be in the scope of the ITBS?
  • How will the IT projects be prioritised and the progress be managed?
  • What are the responsibilities of the ITBS and its members?

After integrating some of the management feedback, the document was approved by the complete management committee.

The next step consisted of defining the process for the operational functioning of the ITBS.

The purpose for developing this process was to get a clear view from all parties involved about the input and decision flow required within the committee.

The outcome was a process flow shown in figure 4.


The ITBS meets on a monthly basis with a predetermined agenda where the following points are discussed:

  • Remarks on the minutes of previous meeting
  • Short presentation of new processes developed (if any)
  • Update of the planning and progress reports of the ongoing IT projects
  • Issues (if any)
  • Presentation of new project initiation forms (by the manager of the business unit)
  • Presentation of miscellaneous items from the business units

This meeting is managed by a secretary, who is from the IT department. This person also has the responsibility for the IT overall planning and budget and is well placed to guide and prepare this meeting.

The first big change was the introduction of the IT budget in the company. This introduction was a common responsibility of the controller and IT, who collaborated to get all the input from the departments and consolidate the result in a structured overview.

The budget will be checked on a monthly basis against the actuals realised within the IT projects and investments.

Another positive outcome of the ITBS was a systematic use of the project initiation form, which is needed to get a new project approved by the ITBS.

Developing the Handover Procedure

As said before, the development of this procedure was an internal IT project and, as such, less relevant for the IT governance stream. Therefore, the explanation about this part of the project is limited to a short description of the outcome of the project.

The purpose of this project was to:

  • Clarify tasks and responsibilities
  • Determine the collaboration and involvement of each person involved in development projects
  • Define the required handover documents
  • Develop the handover procedure

Context: Link to Development Cycle

The starting point was the ICT project procedure, which needed to be integrated in the complete development cycle. See figure 5 for clarification.


Steps in the handover procedure include:

  • The handover is prepared.
    • Development team prepares the conceptual and technical description.
  • Project leader prepares the meeting.
    • The purpose of the meeting is to determine in which way operations can support the system being developed and the documentation required for support.
    • People from operations review the documentation and give feedback to development about what items are missing.
  • Development and operations work together to finalise the documentation.
  • Operations accepts the final documentation.

Handover Documentation

Different Parts of the Documentation

The minimal documentation that needs to be delivered is:

  • Conceptual aspect of the application
  • Technical aspect of the application
  • Operations manual

Why is Documentation Needed for Support?

  • Diagnosis—When there is an incident, operations needs to check the different components to find out which component caused the problem.
  • Monitoring—Indicate what operations can control or test for the system that is being developed. How do they use monitoring?
  • Business continuity—Which technical reorganisations in the system can operations execute to keep the system running? How should this happen? What needs to be taken into account?

Documenting the Business Processes

The purpose of documenting the business processes is to improve the efficiency and effectiveness of the organisation. This was obtained by creating clarity in different communication processes at the company.

The interesting aspect of this project was the business/IT integration. As the project progressed, business got more and more involved in the IT governance project, resulting in an IT-initiated project becoming more and more integrated into the business departments.

After the development of the business processes, a mapping to the IT systems and applications was completed. Through this exercise, a clear framework was obtained to align IT projects and their priorities to the business strategy and objectives.

The result of this process modelling was that the business processes are now used by different groups as follows:

  • IT business steering committee:
    • Process flows are used on the highest level with a high-level link to the systems.
    • The business processes are used to situate and approve project initiations and define priorities among the different projects.
  • IT development teams:
    • Process flows are used on all levels, with all existing links to the existing systems.
    • Business processes are used as the basis for defining the requirements of the users.
    • These process flows give the same basis for IT and the business, make communication easier, and are the basis for the functional analysis.
  • For the development of the IT service catalogue:
    • Process flows are used in discussion with the user department to inventory and define the services for each department.
  • For the improvement process:
    • The process flows are used at any level, depending on the scope of the desired improvement.
    • The result of each improvement exercise is an optimisation of an existing process or a part of a process where the elimination of redundant or duplicated activities is achieved.

Greet Volders
is managing consultant of Voquals NV (Belgium). She started her career as a functional analyst and progressed to project leader and consultant for projects relating to the implementation of methodologies for application development and project management. As projects in the pharmaceutical and telecommunications industry revealed the importance of quality assurance, Volders chose to focus on quality assurance and quality management in the development of information systems. In 1995, she founded a consultancy company, Voquals NV, which provides services in domains related to quality management in IT environments. Voquals has advised several companies in the implementation of a quality system. Volders has been vice president of the ISACA Belux Chapter since 2003.

The complete versions of the documents or presentations mentioned in this article can be obtained by sending an e-mail to Additional information is available at

Information Systems Control Journal, formerly the IS Audit & Control Journal, is published by ISACA®, Inc.. Membership in the association, a voluntary organization of persons interested in information systems (IS) auditing, control and security, entitles one to receive an annual subscription to the Information Systems Control Journal.

Opinions expressed in the Information Systems Control Journal represent the views of the authors and advertisers. They may differ from policies and official statements of ISACA® and/or the IT Governance Institute® and their committees, and from opinions endorsed by authors' employers, or the editors of this Journal. Information Systems Control Journal does not attest to the originality of authors' content.

© Copyright 2005 by ISACA® Inc., formerly the EDP Auditors Association. All rights res erved. ISCATM Information Systems Control AssociationTM

Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Where necessary, permission is granted by the copyright owners for those registered with the Copyright Clearance Center (CCC), 27 Congress St., Salem, Mass. 01970, to photocopy articles owned by ISACA® Inc., for a flat fee of US $2.50 per article plus 25¢ per page. Send payment to the CCC stating the ISSN (1526-7407), date, volume, and first and last page number of each article. Copying for other than personal use or internal reference, or of articles or columns not owned by the association without express permission of the association or the copyright owner is expressly prohibited.