To get another perspective on where CIOs might report within an organisation, I sat down with Dean Lane, a man who knows the CIO role in the United States inside out. Not only has Dean served as CIO at several companies, including Allied Signal and Plantronics, but when he subsequently served as head of Gartner's IT technology consulting business in Silicon, he had frequent dealings with a broad cross-section of CIOs.

In 2003, Dean founded - and has since run - the Office of the CIO (OOCIO), a community of CIOs that also provides consultancy services. Against a backdrop of heavy-duty professional experience, and through the looking glass of the CIO community, Dean has an excellent view of what the CIO role is all about in the US.

Pat Brans: When you are a CIO, who did you report to?
Dean Lane: Most of the time I reported to the CFO, but I have reported to CEOs as well. The two scenarios set up two very different kinds of relationships. When you report to the CFO, you need to have some kind of a partnership with the CFO, because when you deal with other executive (the VP of marketing, the VP of engineering, or the VP of sales) you're not on the same level. If they don't agree, they can just go to the CFO and say, "What's up with your CIO?"

When the CIO reports to the CFO and deals with these other executives, the CIO is looking up. In other words, he or she is dealing up from a down position. So in this situation, the CIO has to rely significantly on the CFO and his and her relationship with those other executives.

When I reported to the CEO, then I was at the same level not only as the CFO, but also as all the other executives. In that situation, you have a different relationship with the other executives, and those other executives have to deal with you differently.

I know you can't give me exact numbers. But since have a pretty broad view of the American companies, from what you've seen, tell me what you think is the percentage of cases where CIOs report to CFOs?
DL:  From everything I've seen, I would guess that it's around 70% to 73%.

Why do you think so many CIOs report to CFOs?
DL: I think there are historical reasons. When the computer first came out, nobody knew what it was. It was just a box with wires and lights that flash; and somebody said, "What is that thing?"

-    "Oh, that's a computer."
-    "Oh, what does it do?"
-    "It crunches numbers."
-    "Oh, number crunchers, yes. Send that over to the finance group. They'll know what to do with it."

And so, what happened? For 50 years we grew up under the financial people. And if you think about it, what is the CFO do today? They keep the numbers and report on how things are doing both externally to analysts, and internally to the CEO.

The CFO goes to the CEO and says: "I have a unique way where you can measure the marketing guy, the manufacturing guy, the engineering guy, and everybody else. You can measure them all consistently. That way is with dollars."

Now, along comes the CIO who works for the CFO. The CIO has many ways to measure every department - not in terms of dollars, but in terms of production, in terms of time, in terms of effort, and in terms of head count. All of these things can be translated to dollars, but these and other measurements can be taken just from the information that is collected by the CIO.

Still the CFO wants to hold on to dollar measurements. I'm not placing blame here. I'm just saying that the past history of doing things according to the CFO's standards has not yet been overcome.

Since we're talking about history, let me ask an historical question. When exactly do you think the CIO role came about?
DL: The CIO title came about sometime in the late 1980s. They gave the top IT person the title chief information officer (CIO). At first, it was a big misnomer, because back then, all CIOs were concerned with was the number of servers, desktops, and so forth the company needed.

Today, if that's all you do as a CIO, then you're not really the CIO. You're the operations person. If you're the top information person in your company, you do need to be concerned about how many servers you have; but more importantly, you need to be responsible for what information you have on those servers and how that information can be utilised for the advancement of the company or a particular campaign or a department or some other effort.

We talked about CIOs reporting to CFOs, what about cases where CIOs report to somebody else?
DL: I see cases where CIOs report to COOs. That's usually fine. But we also have some community members who report to the engineering people. That's not so good.

In some companies, they say the chief technology officer is responsible for everything IT, be it product development or be it business systems. I think that's a big mistake. The CTO, in my mind, is the head of engineering, and works on getting products out. The CTO shouldn't be concerned with things like buying and running enterprise applications. I see that as being quite different from product development. Nevertheless, in some companies, the CIO reports to the CTO.

I've also seen cases where a CIO reported to the marketing department. That was strange. It only lasted a year, but they tried it out - and it didn't work out well.

I think if a company is going to do well, the CIO either has to have a relationship with a CFO that is so strong that, when the CIO goes to speak to somebody, it's as though the CFO is speaking to them. Otherwise, the CIO has to report to either the COO or the CEO.

If there is a COO in the company, and he or she is the only one reporting to the CEO, then it's fine for the CIO to report to the COO, because then the CIO is on a level with all the other department heads.

But I've seen organisations with the COO, the head of HR, and the CFO, all reporting to the CEO. When you ask the CEO, "Why doesn't the CIO reporting to you? They always say, "I just can't have another direct report." But I believe that those people don't understand the importance of what a CIO could do for them - not what they are doing for them now, but what CIOs could do if you unleash them.

Do you think that CIOs run into problems because of the way they express themselves and the way they interact with business leaders.
DL: Yes. If CIOs had chosen the correct language and vocabulary and learned to talk to the business in their terms, we'd be in a lot of different position.

One of the goals of our CIO community, the Office of the CIO, is to transform the CIO into the CEO of the IT department. We don't want to take over the business but we want CIOs to run their department as though it were a business. Once CIOs do that, they'll be able to communicate with other department managers in the same way on the same level and the same wavelength.

CIOs need to understand that there's no such thing as an IT project. Everything is done for the business. CIOs understand this at some level. If you talk to any CIO, they will tell you that the technology portion of a project is 10% in terms of complexity or difficulty. The other 90% is the business side of it.

But still CIOs need to be more careful with the language they use. For example, IT directors often use the word "implementation" to mean we went live. That terminology creates a big problem. If you go live today, the business is going to be less efficient for a while. For some time things are going to cost more and people are going to be annoyed. Why? Because when you start using a new system, you change something.

Everybody has to learn to use the new system; and only when they've learned how to do use it do they improve. It's just like anything else. If you've never played the piano and I said, "Okay, here's your piano. Go ahead and play the piano," you would not be very good at it because up until then, you've only played the guitar. A year later, you're probably are a lot better at playing the piano.

This is exactly what happens with new IT systems. The problem is, a lot of people start measuring the ROI from the day they go live. Implementation isn't over until users get good at using the system, and that's usually much later than the go-live date.

What I'm describing is part of the business side of our jobs. Some IT directors just don't understand. They say, "Hey, you turn the switch and now we're on this new system. The old system is gone. Let's start measuring."

All too often that first impression of the system leaves a bad taste in the mouths of users and business leaders – and that bad taste might last for years.