IT Governance Blog

CobiTdefinition:

Establish and maintain an enterprise information model to enable applications development and decision-supporting activities,
consistent with IT plans as described in PO1. The model should facilitate the optimal creation, use and sharing of information by the
business in a way that maintains integrity and is flexible, functional, cost-effective, timely, secure and resilient to failure.

Bill says,

I haven’t seen a company yet that has done this one even close to complete. What it’s talking about is defining data models for customers, vendors, employees, etc - across all applications define a consistent data model as an aid to integration and reporting. With a new company starting up I think this is something that could be done, but most of us have legacy data and applications that make a consistent data model very difficult.

Still, it is worth the effort to get it done. With a consistent and holistic enterprise information architecture model the quality of your analytics, the simplicity of your integrations and the power of your business are all magnified.

Take something as simple as the employee data model. Should be a no-brainer right? Well, it isn’t. Your HR program came stock with certain fields, your CRM with others and you probably have built a myriad of other functional applications leveraging employee data. Taking the time to make the data models consistent across all employee applications is a hard project to fund. More likely you will define your employee data model at the data warehouse level, and map your integrations with each application such that it feeds the necessary data. Once you have a data model defined in the warehouse you are about as close to having a solid data model as you could expect.

Still, even though it is hard it needs to be done the best you can.

The first step in Defining the Information Architecture is defining the enterprise information architecture model.

CobiT definition:

The information systems function creates and regularly updates a business information model and defines the appropriate systems
to optimise the use of this information. This encompasses the development of a corporate data dictionary with the organisation’s
data syntax rules, data classification scheme and security levels. This process improves the quality of management decision making
by making sure that reliable and secure information is provided, and it enables rationalising information systems resources to
appropriately match business strategies. This IT process is also needed to increase accountability for the integrity and security of
data and to enhance the effectiveness and control of sharing information across applications and entities.

Control over the IT process of
Define the information architecture

that satisfies the business requirement for IT of
being agile in responding to requirements, to provide reliable and consistent information and to
seamlessly integrate applications into business processes

by focusing on
the establishment of an enterprise data model that incorporates a data classification scheme
to ensure the integrity and consistency of all data

is achieved by
• Assuring the accuracy of the information architecture and data model
• Assigning data ownership
• Classifying information using an agreed-upon classification scheme

and is measured by
• Percent of redundant/duplicate data elements
• Percent of applications not complying with the information
architecture methodology used by the enterprise
• Frequency of data validation activities

Control objectives:

PO2 Define the Information Architecture

PO2.1 Enterprise Information Architecture Model
PO2.2 Enterprise Data Dictionary and Data Syntax Rules
PO2.3 Data Classification Scheme
PO2.4 Integrity Management

Check out the links for details on the control objectives.

CobiT definition:

Actively manage with the business the portfolio of IT-enabled investment programmes required to achieve specific strategic business
objectives by identifying, defining, evaluating, prioritising, selecting, initiating, managing and controlling programmes. This should
include clarifying desired business outcomes, ensuring that programme objectives support achievement of the outcomes,
understanding the full scope of effort required to achieve the outcomes, assigning clear accountability with supporting measures,
defining projects within the programme, allocating resources and funding, delegating authority, and commissioning required
projects at programme launch.

Bill says,

This is a fancy way of saying, “plan the work and work the plan.” You’ve engaged with the business in defining a strategic plan and project portfolio, but that isn’t a static event. You need to continually monitor performance, adapt, and if necessary move into new areas. If you did your planning right all of that is done jointly with the business so that at all times you are in agreement what IT is doing and how that is helping the business. You can’t just build your project portfolio and dive head-first into the work. This is a living, breathing thing.

Actively manage is the key phrase.

So the sixth and final step in building the Strategic IT Plan is to actively manage the IT Portfolio, working closely with the business to ensure transparency into what IT had planned to do and what IT is actually doing.

CobiT definition:

Create a portfolio of tactical IT plans that are derived from the IT strategic plan. The tactical plans should address IT-enabled
programme investments, IT services and IT assets. The tactical plans should describe required IT initiatives, resource requirements,
and how the use of resources and achievement of benefits will be monitored and managed. The tactical plans should be sufficiently
detailed to allow the definition of project plans. Actively manage the set of tactical IT plans and initiatives through analysis of
project and service portfolios.

Bill says,

The differences between Strategic Plans, Tactical Plans, and Project Plans can sometimes be difficult to draft, particularly given CobiT’s mandate of ensuring these plans are “sufficiently detailed” to drive the plans that arise from it. It is very easy to draft a strategic plan at a level of detail that would actually preclude needing a tactical plan - if you find yourself in those shoes it means your strategic plan is too detailed.

So let’s look at a hypothetical example.

Let’s say that one of our company’s objectives is to improve customer satisfaction by 10%, as measured by our quarterly customer satisfaction survey. Good, we have a pretty S.M.A.R.T objective here, and we can immediately think of a number of IT initiatives that could positively impact this goal. As I draft my strategic plan I need to consider, at a high level, what we within IT can do to help the company meet this goal. My strategy will be broken out by the various touch points we have with our customers. From Technical Support, where they interact with us through email and the telephone. From Finance, where we send them easy to understand invoices. From Development, where we make software that is easier to use.

As I put the strategic plan together I meet with the VPs of each of these areas, and get agreement on how improvements in these areas would positively impact our goal. We define some objectives and measurements for each area, and I allocate a percentage of my budget to each.

For the tactical plans I then take each of these strategic areas and break them out into how we will actually address them. Let’s look at Technical Support. Suppose we have agreed that there are a few things we can do to help Technical Support better serve it’s customers. We can streamline the IVR menus so a customer gets to an agent quicker. We can enable a searchable knowledge base for our customers. And we can introduce an email response program that let’s customers know we have received their email and have created an incident for them.

For each of these tactical responses meant to address the overall strategic objective, we need to similarly define resources and budget. These tactical plans would then easily lend themselves to having specific project plans built. And best of all, project team members have an immediate and clear understanding of how their project ties to corporate objectives - it’s a very clear path from project, to tactical plans, to IT strategic plans, to corporate objective. It ties together very nicely.

So the fifth step in building the Strategic IT Plan is to create the IT Tactical Plans, which addresses how we are going to address our strategic goals at a sufficient level so that project plans can be drafted and that there is a clear tie back to the corporate objectives driving our strategic plans.

Reader Vincent asked,”PO1.3 is very high level to me, I wonder if there is any example(s) of acceptable implementation”

I initially starting answering in email but the response turned into a bit of a post so I figured I would post the response here instead:

I’ll try with a simple example. One of the functions we provide in IT is an internal level 1 service desk. This group resolves a lot of issues and then escalates what they can’t resolve. We have a number of SLAs defined for this team including items like first call closure rate, time for initial response based on urgency, etc. Our current SLA for first call closure rate is 70% and we are currently running at 60%. When I built our 2008 strategic plan I used 60% as the assessment of our performance. This team is part of the operations group, or the “keep the lights on” team.

Similarly, we only completed 30% of projects on time. When we consider the projects the business would like us to engage on in 2008 we must be realistic about this number, assess the performance and use that as the baseline on which to build our plan. A key component of our 2008 plan is to improve in this area to 60%, which is still not as high as I would like, but a significant improvement.

Don’t make this more complicated than you need to - PO1.3 means to take an honest assessment of your performance and make sure to account for it in your planning.Bill

CobiT definition:

Create a strategic plan that defines, in co-operation with relevant stakeholders, how IT goals will contribute to the enterprise’s
strategic objectives and related costs and risks. It should include how IT will support IT-enabled investment programmes, IT services
and IT assets. IT should define how the objectives will be met, the measurements to be used and the procedures to obtain formal
sign-off from the stakeholders. The IT strategic plan should cover investment/operational budget, funding sources, sourcing strategy,
acquisition strategy, and legal and regulatory requirements. The strategic plan should be sufficiently detailed to allow for the
definition of tactical IT plans.

Bill says,

This control objective represents the meat of the Define a Strategic IT Plan process. It’s the actual creation of the plan. So far our control objectives have had us ensure we are properly accounting for the value IT is bringing to the business, creating processes that help foster business-IT alignment and to assess IT’s current capabilities and to establish baselines on how IT is performing those capabilities. Now we roll all of that together and create the plan.

You will note that CobiT does not define the form of the plan nor offer many particular details for how you go about actually creating it. That will be business and manager specific. Remember, CobiT is a framework that helps tell you what you should be doing, not how you should be doing it. Creating an IT Strategic Plan is important - how you do it is up to you.

For me, there are a number of very important points captured above. First is that “co-operation with relevant stakeholders”, while extremely important is also very difficult to pull off. Ultimately your stakeholders for your services will be everyone in the company - on a project by project basis they will need to be involved but overall at the level where you are creating a strategic plan you really aren’t involving Stakeholders per se, but instead working with Senior Management of the company. The details will have to be fleshed out in the tactical plans and projects.

Second, it is very important to define the measurements in the Strategic Plan. Good plans do this - bad plans do not, and force project managers or other management later to come up with high level measurements. If baselines are established those should feed directly to measurements within the strategic plan.

Finally, a strategic plan needs to be detailed enough so that specific tactical plans can be created with a degree of accuracy. I have seen strategic plans that are so high-level you really have no idea what they hope to accomplish. Put the details in so that everyone can understand what needs to be done.

So the fourth step in building the Strategic IT Plan is to actually create the strategic plan, ensuring that it is sufficiently detailed so that tactical plans can be derived from it.