"How to Tap IT's Hidden Potential"

"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?

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

Have Compassion

Today I was in a meeting with Business and Technology folks, and I started talking about Customer Collaboration over Contract Negotiation. (Many will recognize this line from the Agile Manifesto.)

And I talked about how, always, there is distrust and tension and misunderstanding between the Business side and the Technology side. Well, at least on day 1 in every client I walk into. YMMV. With luck, we start building trust right away.

In thinking about this on the plane back home, I wanted to say something to those 12 people. And since they are not with me now, I will say it to you.

Have compassion.

What do I mean by that really?

First, the most important thing is that it is more blessed to give than to receive. More specifically, it is not about you. It is about doing for others, most especially for the end customer.

Let me introduce my second point with a story. When I teach Agile I like to start with the story of the 6 Blind Men and the Elephant. I won’t explain that story now, but one reason I like it is because that story is also related to Buddha. The compassionate Buddha, as he is known. And Buddha had great compassion for us, and our inability to comprehend all the knowledge we needed to know, and to figure out what is really important. And I say, we team members should have compassion for each other and how hard our work it, how much we need to learn. We try to solve the problems if a person who almost always is not there, and do it with a system that is abstracted and non-concrete in the extreme. And all the easy projects have already been done. Difficult work. We need compassion.

My third point is more specific. My experience is that most Technology folks have no conception of how difficult it is for the Business folks to see and be accurate about what the business need to do to satisfy their customers. The customers are changing, the competitors are changing, they don’t have time to understand what is do-able. This is extremely difficult work that only a few are truly insightful about. (In our economy, many are modestly lucky.)

On the other hand, the Business folks need to have more compassion for the technology guys. Technology work is extremely challenging, and offers great opportunities for creativity and discovery for those Business folks willing to travel those uncharted seas. And capable of escaping the dense fogs.

My fourth point starts with Deming, who has many valuable insights. Deming said that all problems in business are caused, in simple terms, by two things: “the system” and the people (vices, true inability, laziness, etc.). The “system” was all the things that were (or were not) there to structure the people and the work to get the work done. Initially he guessed that 80% of problems were caused by the system and 20% by people. As he grew older and learned more he revised that. I think he finally said that 95% of problems are caused by the system and only 5% by the people. And a leader's job is to get the system improved.

My point here is that, while you may be frustrated in some ways with your colleagues, most of your frustration is not about them, but about how “management” (maybe yourselves) have structured the system through and in which you work together (or not together).

Have compassion. Have patience. And start improving it today.