A few weeks ago, I participated in a workshop with a global financial services CIO to discuss what the coming 3-5 years would mean for the IT function and its role in the business. The most important driver for this kind of conversation has to be where the business is headed. To serve as a proxy for this, we spent a good deal of time talking about questions facing the business:

1.   Geographic expansion
2.   Product range diversification
3.   Distribution channel expansion
4.   New target customer segments
5.   M&A activity

These kinds of discussions often tailspin into how to organise the IT function, with the concept of a ‘federated’ IT model taking centre stage. However, my advice is to think about the business operating model first, and let that drive the IT discussions. The framework we used for this conversation was one developed by Jeanne Ross at MIT’s Centre for Information Systems Research. Along with her colleagues Peter Weill and David Robertson in their excellent book Enterprise Architecture as Strategy,  she describes a business operating model as: The desired level of business process integration and business process standardisation for delivering goods and services to customers.

By looking at each business along these two dimensions, with a good idea of the answers to the five questions above, you can develop characteristics of both business design and technology systems for each of the four resulting quadrants.  MIT’s version looks like this:

Business Operating Model - Ross, Weill, Robertson (MIT)

Does Your Technology Match Your Business Model?
While looking at a chart like this, the obvious question is: where are we? While answering this, it’s important to first look at where the business is today.  For example, a wireless telecommunication company I spent many years with was very entrepreneurial and based its business on creating scores of local offices across North America.  To do this, they created a cookie cutter business and technology model that could be applied in any market – high business process standardisation, but low business process integration, or a ‘replication’ operating model.  Their IT organisation was basically a centralised IT factory that developed and maintained the core cookie cutters and support systems for the local businesses to operate.

In the case of the financial services organisation, things are a bit different.  Because they have been growing through acquisition of late, they have a collection of businesses that do the same things, but in much different ways – low business process standardisation, but a higher level of process coordination, or a ‘coordination’ operating model.

Coordination is where they are today, but not where they want to be.  For the vast majority of their business, they hope to move to the ‘unification model’ to bring their core products into a single set of business processes.  Even across Europe, the UK and North America, their products and processes share much more than they deviate.

Addressing the Federated IT Model
With an idea of the target operating model in mind, the target IT operating model is next.  Here are some thoughts on how the two relate.

Two final thoughts:

First, this kind of thinking can be applied to companies with several distinct business units; a global footprint is not required. Second, this is a much more complicated topic, especially when culture and language enters the discussion.  However, I think it’s an important starting point; think about the resulting business operating models and only then, start working with the resulting target IT operating designs.  

5 Characteristics of a CIO Dashboard
I figured it was about time for me to tackle the CIO dashboard topic since you’ve been good enough to read along so far and were probably wondering if I would ever get around to it. I think this is a pretty substantial topic, so I plan to use a series of posts to cover it over the next few weeks.

Part 1 explores the rationale for and attributes of a CIO dashboard.  Part 2 will discuss dashboard audience.  Part 3 will cover dashboard design considerations and offer some examples.  Part 4 will talk about decision-making using a dashboard and other issues to wrap it up.

Why Do You Need a CIO Dashboard?
Come on, aren’t you already swimming in data?  Most people are, but there are a few paralysed by reporting – sort of a feast of famine situation.  Nevertheless, the idea of a dashboard is appealing.

Here are some of the reasons I have heard for taking on this kind of project:
•    “I need a summary of what’s going on across IT”
•    “I want to show progress that IT is making toward our goals”
•    “I need to better justify IT investments to the organisation”
•    “I need a way to track a specific target set by my boss”

Consider a comment from JP Morgan Chase CEO Jamie Dimon on how he and his leadership team work (from Fortune, June 8, 2009): You have to be very disciplined, and this is even more important in a crisis. Our management team, 15 to 30 people, talk every day at 7:30, 12 noon, and five o’clock about what’s going on, sharing information, making some decisions on the spot, reviewing facts and information. Plainly put, it is a requirement for his entire team to be armed with the right information every day so as to facilitate timely decisions.  This is what I would want my CIO dashboard to do for me.

5 Characteristics of a CIO Dashboard
These are the five as the core attributes of a CIO dashboard, or any management dashboard for that matter:
1.    One page in length
2.    Easy to read
3.    Doesn’t require a decoder ring
4.    Accurate
5.    Up-to-Date

One page in length
In keeping with the simplicity theme, a management dashboard should contain no more information than can fit on 1 8.5×11 page (or 1 window).  Furthermore, while we would all like to think we live in a 100% digital world, the dashboard should be printable – a requirement if you have senior management as your audience.

Easy to read
To quote Edward Tufte in his seminal work, The Visual Display of Quantitative Information: Data graphics should draw the viewer’s attention to the sense and substance of the data, not to something else. A good dashboard needs to be low on the chartjunk and generous with white space.

Doesn’t require a decoder ring
Not only should a dashboard be easy to read, the data must stand on its own and not required a legend or key.  For example, one of my insurance clients has a composite metric to measure and report on the health of a major re-platforming program – red, yellow, green.  Much quantitative and quantitative data combine to create the measure, but it is not simple or transparent.  Instead, they would be better served by reporting metrics like budget to complete and earned value measures.

Accurate
One of the biggest challenges in management reporting is data accuracy.  A CIO of a regional bank I have been working with wants to understand how much of her staff are working on strategic projects.  The problem is that the time tracking system only provides maintenance and trouble-ticket related categories and some generic project buckets.  The resulting data is virtually meaningless.

Up to date
The dashboard metaphor often leads to a desire for real-time data.  I purposely use the term up-to-date instead because real-time data is both extremely difficult to deliver accurately and almost never needed.