Enterprise Software optimize

BI systems failure: Is the CIO to blame?

Jay Rollins comments on a recent discussion about whether a CIO could be faulted when business intelligence systems projects fail. He breaks down the two sides of the argument and offers his take.

Jay Rollins comments on a recent discussion about whether a CIO could be faulted when business intelligence systems projects fail. He breaks down the two sides of the argument and offers his take.

--------------------------------------------------------------------------------------

I recently read a conversation in a LinkedIn group regarding the high failure rate of business intelligence systems (BISs). The premise of the conversation was that it could be the CIO's fault that these projects consistently fail. One camp said the CIO should have seen this coming and either killed the project or done something to save it. Also, the CIO should have understood the business well enough to guide the project so it would add value to the company.

The argument against this line of thinking focused on the fact that you can bring a horse to water, but you can't make it drink. Basically, the role of the CIO is a trusted adviser and facilitator to the business whose purpose is to apply new technologies to business processes and help the business run more efficiently.

The strange thing is that both sides are saying somewhat the same thing, but there is a subtle difference.

Defining BI

First, a definition of BI is in order -- and not the 30-second slick sales guy elevator pitch. A BIS is basically a decision support system. Someone pulled together enough data to actually mine some information that can be used. As with any system, things tend to get more complex as time goes by. Once some information is viewed as having value, more and more information is sought. Spreadsheets, Microsoft Access databases, and disconnected Web data portals all grow up in silos until someone says, "Hey, we have to organize this all somehow."

There is more to it than that, but basically that is the evolution. Someone suggests a BIS tool, and the company goes down the path of learning more about it. The sales person does her job and gets some excitement going. Now all the data and bits and pieces of actual information can miraculously become a business decision support and forecasting system that can run a bunch of complex "What if" scenarios.

Looking at both arguments

I think the subtle difference in the two arguments has to do with the different perception of job scope. The first argument states that the CIO is also a steward of the business as well as the lead technologist. In that role, the CIO is the only position in the company who can connect the data transformation lines to the advanced decision making tools. The CIO's deep knowledge of the business, coupled with the knowledge of the data available and how to turn it into real information, makes that person the only position in the company that can be key to a successful BIS implementation.

The second argument views the job scope as the technologist only. Business managers are the experts in the business. The CIO position here is to translate the needs of these business managers into technological solutions.

Evolving the scope of a CIO's role

So what is the CIO's role: business leader or technologist? The challenge that I have found time and time again is that the business wants the technologist, but they need the business leader; unfortunately, the business will resist this fiercely. "You're the computer guy; you're not supposed to know about the business." Some companies have realized this need; many others have not. But this is the direction of the CIO role in my opinion.

My answer to the initial question is that, yes, it is the CIO's fault if BIS projects consistently fail. Assuming the role of technologist instead of the business leader, you can always say that this is not in my job scope. But as the role of the CIO continues to evolve, that tends to look more like an excuse.

Get leadership tips in your inbox TechRepublic's IT Leadership newsletter, delivered Tuesday and Thursday, features blogs, white papers, and other resources for IT managers and CIOs. You'll receive advice on staffing, morale, dealing with day-to-day challenges, and much more. Automatically sign up today!
14 comments
alanfinn
alanfinn

CIO - Chief Information Officer - not manager of sales or marketing or advertising or manufacturing or shipping and receiving. BI is gathering, safeguarding, and making data available to those other departments. If the other departments fail to utilize the data correctly, it's their failure, not the CIO.

No User
No User

This predicament is one of my long standing points. Typically the standard business types (SBT's) keep IT outside the room with the big table instead of realizing the rightful place of IT is very near the head of that big table. Once again IT "Is Specialized Business". Being it is business with a Special Unique feature that for the most part falls outside the standard business matrix the SBT's don't know how to handle IT and deal with IT as part of the team. With out a detailed example I would say that it's a failure of the SBT's. They use the end product. They have a rather consistent trait in which they insist that IT stay outside business because in their mind IT is not part of the business. That point of view never ceases to astound me. Even although in most cases they would be lost and the business functionless or at least severely handicapped they still blindly insist that IT is not part of the business. The very nature of IT is to enhance capabilities and open new opportunities. When used in a business environment they are enhanced business capabilities and opportunities. That is the "TRUTHFULLY" undeniable combination of business and IT working together hand in glove. As time goes by the more inseparable they become. The critical point to make is that the CIO position must be real and not just a title. A real CIO has plenty of high titled folks working under them to handle the entirety of technical details and so on. The CIO's mission is to ensure that technology is properly implemented to leverage business opportunities, increase efficiency, and improve the general employee experience. To do that the CIO MUST be at the big table and well indoctrinated by the SBT's in the general operation of the business. You are absolutely correct in saying that the CIO must have a solid understanding of the business and the general goings on with the various departments. Oddly enough SBT's always take the position that IT "should" be teaching them how to best utilize IT (and then let them do what they want) while simultaneously holding tight to the belief that they should not need to work with IT and teach IT folks the business. They think that we should either already know "EVERY" type of business function, more over every way that every business utilizes those functions or be replaced by someone who does. That double standard is generally mater of fact and arrogantly enforced. They feel that if we don't already know what they do then we should not be there and they are aghast at the notion that they actually have a responsibility to teach us their trade and perplexed that it's necessary to do so to permit IT to in turn teach them how to utilize IT to leverage business opportunities, increase efficiency, and improve the general employee experience. The bottom line is the business failed because IT "IS" part of the business so either way the business failed!!! In my humble opinion it is absolutely necessary for IT in general and specifically the CIO or top IT job by what ever title to be fully integrated with the business operations. When I say IT MUST sit at the big table I mean that IT is not just in a meeting with the top Brass I mean IT MUST be informed and mentored in a meaningful way the purpose and objectives of the business, the intentions of management in how they conduct their duties and their plan for maintaining and growing the business. It needs to be top down bottom up. If you don't know the business you can't optimize IT for what you don't know and equally bad is not getting the right tool for the job. Thanks Jay for proving one of my long standing points.

Deadly Ernest
Deadly Ernest

Yes, the CIO is to blame, the same as the unit commander is to blame when a military unit fails to perform properly in the field due to internal mistakes. In both cases you come back to the boss not seeing the place is run properly and people doing their jobs properly. In my limited experience most BISs fail for the same reasons a lot of specialised in house projects fail: 1. They select one organisation or person to prepare the specifications of the system, and thus fail to have what they do properly cross checked and audited. 2. They fail to have the collection of the information for the system specification properly checked to see the information is coming from the appropriate areas and all relevant information is collected. 3. See the people working on the design of the BIS are properly supervised to see that a suitable system is designed to business needs instead of accepting a near miss being pushed by the designers. In short the CIO failed to exercise the management they're paid for. they need not do all the management tasks, but they must see someone is responsible for doing them and that they do do them.

adams_john73
adams_john73

Another great post by Jay. I think that it is worth pointing out that whether fair or not, the CIO will be blamed for BI failures. In today's world it is essential that the CIO be a business leader and not just a technologist. That leadership requires a clear understanding of the nature and timing of information that the other business units need in order to be competitive. The segregation of duties that once existed between business, finance, and IT have been blurred or erased altogether. It is time to expect that the CIO will play the primary leadership role in selecting and implementing BI systems. To do otherwise is to adopt an uncompetitive business structure.

Deadly Ernest
Deadly Ernest

in every case of a BIS failure I've seen, it was because the BIS was not properly designed for the business needs. The CIO or the person the selected and failed to supervise bought something of the shelf as they felt 'near enough was good enough' in a BIS that isn't good enough.

Deadly Ernest
Deadly Ernest

then the car manufacturer is to blame. Is the crash is due to a mistake by a mechanic then the mechanic is to blame. The design of a BIS is usually due to the requirements set out by the senior management, and it's the CIOs job to see the people selecting a BIS or designing have the proper information to do the job right and they meet the requirements properly. If they fail to see the task is properly supervised or checked, they failed, end of story - the buck stops where?

moraller
moraller

I have seen these projects fail for one main reason. No one in the company has a clear idea of what they want to use all this data for. There is a general idea of, "If we collect all this stuff in one place it could be really powerful." That is not at all the same thing of having any idea of what sort of analysis you want to perform. Collecting and displaying data is easy. Getting companies to use that collected data for anything useful is hard, and it can't be laid 100% at the CIO's feet if it doesn't happen. The CIO can explain the advantages, show how to use a system and make the first reports available, but if the CFO (for example) doesn't really care all that much about digging into that data the project will be considered a failure because no value was really added.

moraller
moraller

I have actually had a conversation that ended when a department manager said something along these lines, "I don't know what I want to see or how I want to see it. Isn't it your job to present me data?" IT simply can't know all the possible uses that all the departments may have. It is job of other leaders in the company to make sure their needs are clearly defined and articulated. All a CIO can do is ask (beg) for input, if it is not forthcoming the resulting design flaws will be laid at the CIO's feet, but it isn't truly his/her failure. A BI failure is normally the fault of everyone (IMO).

Deadly Ernest
Deadly Ernest

One of the most useful BI systems I've ever seen was little more than a well designed interface that drew data from all the other business systems as required. It had a series of GUIs where you checked the type of data you wanted, the way you wanted it filtered, the way to sort it, and the way to display it. It then accessed it's data base which was just a list of data fields and where they were found in the other databases. It then got and sorted the data and presented as you wanted. The managers could manipulate it however they wanted as the information was copied into a file and put in another program to allow them to prepare presentations etc. You could save a particular report and call often if you wished. Interestingly, the company where I saw this had one senior manager who objected to it very strenuously. The MD found out why after it was put in. The first analysis of manager performance showed the objector wasn't doing his job right, and he was soon let go.

Deadly Ernest
Deadly Ernest

supervision of his supervision - just like responsibility for auditing, each has a share of responsibility to see it's done and done properly and on time.

moraller
moraller

I agree with you 100% Let me lay out the steps of the the failed project that I am talking about. 1. Corporation decides it needs to have a data warehouse for better reporting. 2. After research and talking with all parties involved I recommend against starting a project because I don't see any dedication from the teams to do the work involved. 3. Company decides to do the project anyway. 4. Teams don't do the work needed. 5. I tell the CEO you can't have a BI project without cooperation from the whole company and I can't put together a data base without input from the people using the DB. 6. After talking with all teams involved CEO decides that the extra work required during implementation is too burdensome and stops the project. 7. I'm to blame?

Deadly Ernest
Deadly Ernest

I was once in a situation of designing a database for an organisation back in 1990. The people who would be using demanded I get it done a.s.a.p. but the key players wouldn't tell me what they wanted. I simple documented everything and made periodical reports to their boss about my inability to deal with their side due to them not being able to tell me what they needed. As the one responsible for seeing the job got done right, I made no further moves until I got what was needed. If I'd gone ahead without the required information the job would have been done wrong. The CIO is in the same situation, it's his job to see the job is done right and properly documented. That doesn't mean he has to do the work, just see it's done right by his staff. If he doesn't oversee it properly or keep insisting on getting the proper information, he's derelict in his duty.