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.
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!