"How to Tap IT's Hidden Potential" was the title of an article in the WSJ on March 10. Published in collaboration with the MIT Sloan Management Review.
The subhead read: "Too often there's a wall between a company's information-technology department and everything else. That wall must go."
I remember getting a paper back in the 10th grade: "You have a firm grasp of the obvious." I was smart enough then not to feel complimented. (This is perhaps too harsh for these authors; they are raising a very important issue that has not been addressed well enough yet.)
In 1970 Dr. Winston Royce wrote a now-famous article entitled: "Managing the Development of Large Software Systems". Because of this article he is considered the father of "waterfall". One of the top five problems he identified he called (in a positive way): "Involve the Customer". Same basic idea; this was a known problem before 1970. And there have been many surveys of successful projects over the years. One of the top reasons for success always is that the business/customer was more heavily involved.
This gap between IT and the business side is a serious problem, and it is shameful that we (the business community) have not addressed it with much greater success. In my opinion, this is the key reason that we are getting generally a lousy return on our investment in IT. Certainly compared to what we could get. So much so, that management is often so desparate that they use this kind of logic: "Well, it's probably going to fail for $50 million here in the US. Let's ship it to India, where it will fail for $25 million." The logic might be slightly better than that, but not much.
Back now to the WSJ article written by Amit Basu and Chip Jarnagin. So what do they recommend?
I like some of these ideas. I would put greater emphasis than they did on making these solutions adaptive to change and to learning (they do hint at this). You should read the article. (You may need to join the WSJ online. Or see the comment (below) where the article is available for free.)
But what's missing with these ideas? Well, in general, they are too high-level. What is needed is a way to get business and IT people collaborating in a specific small team that will accomplish a specific mission. Where the rubber meets the road. To me, this is where Scrum helps to solve this problem.
The subhead read: "Too often there's a wall between a company's information-technology department and everything else. That wall must go."
I remember getting a paper back in the 10th grade: "You have a firm grasp of the obvious." I was smart enough then not to feel complimented. (This is perhaps too harsh for these authors; they are raising a very important issue that has not been addressed well enough yet.)
In 1970 Dr. Winston Royce wrote a now-famous article entitled: "Managing the Development of Large Software Systems". Because of this article he is considered the father of "waterfall". One of the top five problems he identified he called (in a positive way): "Involve the Customer". Same basic idea; this was a known problem before 1970. And there have been many surveys of successful projects over the years. One of the top reasons for success always is that the business/customer was more heavily involved.
This gap between IT and the business side is a serious problem, and it is shameful that we (the business community) have not addressed it with much greater success. In my opinion, this is the key reason that we are getting generally a lousy return on our investment in IT. Certainly compared to what we could get. So much so, that management is often so desparate that they use this kind of logic: "Well, it's probably going to fail for $50 million here in the US. Let's ship it to India, where it will fail for $25 million." The logic might be slightly better than that, but not much.
Back now to the WSJ article written by Amit Basu and Chip Jarnagin. So what do they recommend?
- Begin with IT literacy - and commitment - at the top.
- Hire an IT leader who sees the big picture.
- Create demand for IT solutions.
- Make sure nothing gets lost in translation.
- Rationalize IT spending.
- Create an IT portfolio by evaluating risks and returns.
I like some of these ideas. I would put greater emphasis than they did on making these solutions adaptive to change and to learning (they do hint at this). You should read the article. (You may need to join the WSJ online. Or see the comment (below) where the article is available for free.)
But what's missing with these ideas? Well, in general, they are too high-level. What is needed is a way to get business and IT people collaborating in a specific small team that will accomplish a specific mission. Where the rubber meets the road. To me, this is where Scrum helps to solve this problem.
7 comments:
The full text of this and all WSJ Business Insights is available with no registration or subscription via MIT Sloan Management Review's website.
Here's the link for the IT article
http://sloanreview.mit.edu/wsj/insight/technology/2008/03/10/
The most current version of Business Insight is all ways here:
http://sloanreview.mit.edu/wsj/
Sean
Thanks Sean.
This isn't a problem with the IT department, it is a problem with functional organization in general.
There is a problem with the proposed solution: it does nothing to address the root causes of the problem it sets out to solve.
Thus, it will be very hard to succeed, and if there is success, it will almost always be temporary. It will require fighting all the time, and as soon as the effort slows a bit, the system will return to its equilibrium state.
It is better, and easier, to change the organization as a whole. For example, go for a flow organization instead, and the problem will disappear. There will of course be another set of problems that replaces the old one, but it is usually easier, and more pleasant, to handle.
Hi Henrik,
I agree. I am sorry if I suggested (and maybe the authors of the article did, but I did not take them that way) that "IT" was that Dept in a firm. I took it to mean, as you suggest, Information Technology generally. And I agree that the use of technologies is a general business problem, not a problem that should be isolated in the IT Dept.
I think I agree it would be better, in some sense, to change the organization as a whole. However, I work with firms that often have 100,000 people. Changing the whole org is very serious work, and (and perhaps I am jaded) won't happen "overnight" as we say in America.
So I like the incremental revolution of Scrum, where we can change one team at a time...5, 10, 15, 20 people at a time.
I was talking to someone at Vanguard about this last night. The point that she made was that the mindset is at least as important as the formal org. In martial arts, we sometimes say "if the heads goes, the body will follow" eg, on a throw. Perhaps it is that sort of Aikido we must do on larger organizations.
If you have a longer discussion of your point, I would like to see it. I bet you do.
Thanks, Joe
Hi Joe,
Sorry if I came across as a bit gruff.
The organizational silo problem affects everyone. The Sales department and the Finance department don't communicate any better than the Sales department and the IT department, or the Engineering department and the Operations department.
No matter where you sit in a functional organization, it looks as if everyone else is against you. (Pretty broad generalization. Nevertheless, it is usually true to a worrisome degree.)
Changing an organization of 100,000 people can be easier than changing a single department. The reason is that when you change the organization as a whole, you can change certain pivot points, which creates a ripple effect that changes the entire organization.
When you try to change a department, or part of one, you usually can't get at those pivot points, so you have to fight the organization instead.
It's just like in Aikido, you need to break the balance to throw effectively.
"The head" is the CEO, and if the CEO goes, the organization will follow. The organization will not always land on its feet though...
I have a blog where I write about change management, Theory Of Constraints, systems thinking, and agile.
If you are interested in how to change an organization, you might get some mileage out of my videocasts on organizational change.
Hi Henrik,
Good ideas. I will study your stuff. Perhaps I need your Aikido on the CEO of one of these large organizations. Or perhaps I need more courage (or a more persuasive tongue).
Regards, Joe
I would love to help. Three pieces of free advice:
1. If you want to change your own organization, start by building a sense of urgency, and a power base.
2. Plan the whole thing like a military campaign. Use a method that allows you to move quickly. My preference is for Strategic Navigation. (BTW, SN is a very good fit with agile methodologies. Management probably needs to tighten their decision loops considerably to make god use of agile, and SN is the best method I know of doing that.)
3. Depending on the culture in your workplace, you may need an exit strategy. If someone with more authority than you sees your initiative as threatening, the response can be out of proportion to the threat, and very sudden. (This is a good reason to use management consultants like me. If the change initiative does not work out, blame the consultant. This is actually one of the options I discuss with clients in order to protect them. Luckily, no client of mine has needed it yet.)
Post a Comment