In his blog "bi for business people," Tom Hudock revives the old business versus IT debate, based on some of his recent experiences.
Although I totally agree with the general gist of his post, he makes a few remarks that I'd like to comment on. I know Tom likes a good debate as much as I do!
Tom argues that the sponsor for any BI project should come from the business, not from IT. The CIO often is not at the decision-making table, he observes, and he mentions "the golden rule": those with the money, make the rules.
You know what, I think Tom is right, but I still don't agree. Maybe it is the case, but it shouldn't be. I've always said that the only project approach more disastrous than the IT-driven project, is the business-driven project. No concept of architecture, no leverage for other areas, no real expertise in systems implementations.
I really would like to introduce another golden rule, or wait, let's make it the platinum rule: "those with the knowledge and experience, make the rules." BI implementations, like most IT projects, have a strong business side and a strong IT component. Both IT and Business need to agree. Which brings me to a broader point, organizational maturity. In a project you collect the necessary skills, such as project management, technology skills and business skills, regardless in which department they reside. If I see an "IT project," or a "business project" doing BI, I know enough, it's gonna fail. You need a "BI project," or an "XYZ project."
Bottom line: It's not OR, it's AND. And if the company culture doesn't allow that, and one overrules the other, well, every organization gets the results it deserves.
-frank
Comments (2)
AND is most always better than OR in terms of implementing an Information Solution. However, even when the AND is enacted many projects provide a less than favorable solution from either the technical or the businiess's expectations. What we have here is a failure to communicate. How so you ask when meetings take up 20 - 30 percent of your day? I think the number one cause is the technical-functional gap in mutual understanding. By now most of us have seen the comic strips of what the customer asks for and what the consultants provide not being quite the same.... it is probably going on right now, at your project. You realise it, the customer realises it, more meetings are scheduled, agreements are made, requirements are refined.... Tiresome isn't it? There is no quick fix, it is not easy, and most people will not change the way they interact with each other. So what's a consultant to do? I have found that banging my head on the wall hurts, and having water cooler conversations to vent provides temporary relief but no lasting effect. What does work, and I am sorry to say, I have neither time nor space to profoundly affect your perception or the way you interact with your clients, is good old fashioned project management. Moan and groan as you like but its true. The difference between good project management and performing well is in the communication. Really. The IT folks know their stuff. The Business knows what they require. So, if everyone on the project knows their stuff where is the problem? Why is there a problem? Why can't we all just get along? I think, based on professional experience over the past couple of decades, the problem begins on day one. Which way is the BI solution going to be solved for... Bottom up? or Top down? It CANNOT be both at once. If you try you will be in meetings, lots and lots of meetings. Wait you say, we are implenting a COTS/Vanilla solution. Congratulations you lucky duck. Don't forget to buy a lottery ticket on your way home tonite. Seriously, the business wants to implement based on best practices. Being in BI you could ask, as of what point in time best practice solution should we implement? The best practice is implementing a solution that satisfies the Business's needs, in the shortest amount of time, requiring the least amount of resources. Step 1. Top down or Bottom up. Step 2. Requirements Gathering (dig deep, ask the same question three different ways and clarify). Step 3. Change management (something is going to change either on the solution side or the business side). That is a very simplified foundation to get started building a successful partnership with your clients. Wish I could expound more but my bread isn't buttered by righting in blogs. Remember to communicate, be nice, and love life.
Posted by Jack Hammond | January 31, 2008 7:19 AM
Posted on January 31, 2008 07:19
There is also the question of: Why does the Business have the budget in the first place? Because they can write up a plan of what they would actually need? Most likely.
But what I have seen happen in many organizations, is the fact that there is an IT organization, but due to the sheer intricacies of the IT processes, the Business takes charge and starts acquiring their own IT resources. This proves that IT is necessary, but not important enough to make it to the software acquisition decision table. But how does one balance between:
- optimizing the time spent on developing a solution for the business and
- optimizing the solutions across the organization?
And here the i??organizational maturityi?? as Frank calls it, is important. Some IT organizations do take the path of the Business and create a plan that can prove how the company can save time/budget by optimizing solutions across the organization. And in those cases, IT starts being called into the decision meetings and the culture of the company changes. Would the next step be: IT proposing solutions to the business based on:
- the understanding of the business and
- the understanding of the existing tools?
So, the factors that I see impacting the i??organizational maturityi?? are the need to optimize resources (due to internal or external constraints, like competitiveness, financial strength etc.), and the strength or leadership capabilities of the IT organization. What do you think?
Posted by Andreea Vasiliu | January 31, 2008 8:56 AM
Posted on January 31, 2008 08:56