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

Toward a general theory of Business Value

The title of this post is a little highfalutin, but it gets the idea across I hope.

After many discussions with people about this subject, I find that the words "business value" tend to mean something very narrow to most individuals.

For example, the words often mean mainly or mostly: "the numbers we put on the story cards", "the silly NPV estimate someone made to get this project approved", "how the company benefits from this team's project", "something that only the business guys care about...probably they just want to boast that they have the project with the biggest one", etc.

It is important to note immediately that business value ties in with our highest values. To satisfying the basic human needs of those in difficult circumstances, of obtaining our highest aspirations, of leading a good life (in whatever way you define that). When I was young, I was taught two main rules: (a) Love God, and (b) Love your neighbor as yourself. Without ignoring (a), let us say that in my opinion, business value is really about expressing caritas to specific individuals.

To me, when you use the words business value, you imply and/or are really talking about a whole bunch of things:

• a definition of what value means; and one or more specific operational definitions of BV for the effort (project) at hand
  
• a bunch of ideas that surround and pervade BV, that are key to the way we use it
• a recognition that communication and motivation are key
• a very practical down-to-earth subject, that is at the same time difficult and slippery
• a bunch of practices that make BV useful. I want to call these the BV engineering practices (although again that may sound too highfalutin to some)
• change and learning, so the subject is as much about adapting to change and learning about it faster, as about any hard and fast dicta on BV itself

And other things as well.

So, I wanted to back up on the subject. At least compared to some who want to rush to consensus on one definition of business value (eg, reduction in cycle time, to pick one of my favorites from Lean).

So as not to lose you, please define in your own head what Business Value means to you. Say, the business value of a project. (I assure you there are many different definitions out there.) Now, think about that as I talk about why we care about business value.

I am searching for the general ideas that pervade all views of business value. And perhaps by examining them, we may discover more about what BV really is, or at least how to use it better.

Why do we care about Business Value?

"You have to be very careful if you don't know where you're going, because you might not get there." This was Yogi Berra's wacky and wise way of saying it.

I have been on too many projects where there was no clear definition of what we were trying to accomplish. In several cases, one guessed that we were at the personal and daily whim of some project "leader" (not that I considered the leadership skills all that high).

Let me state this a different way.

In the world, my hypothesis is that there are an infinite number of good things to do. The problem is not finding a set of good things to do, but in deciding which are the most important things to do.

So one reason we care about BV is to, in this short lifetime, accomplish something truly meaningful.

Another reason is that we work in small teams. And we want everyone to be working toward a common goal. So we need to agree what that common goal is. It can be expressed in many ways, but at one level it must be called business value. Or, more specifically, the operational definition of business value for this project that motivates the team to do only (and just) what is needed as defined by business value.

Put another way, business value draws upon our natural motivations, and gives us a basis for putting a natural order into all the arrangements involved with a team's work (eg, who does what, the architecture of the system, etc., etc.).

Another reason is based on my hypothesis that change is incessant. This means that people forget, customers change, customers' needs change, past estimates (if they were accurate) are no longer accurate, etc. To the degree we understand BV appropriately, it can act as a guidepost in this swirl of change. We do not build new products for mere technical success. We do it to provide business value to specific people, so we must adapt to this change.

My hypothesis is that BV itself is also changing. This is alluded to below, but more a subject for later.

Four related ideas

Let me mention now four ideas that are key to understanding business value (that weren't already implied by things I said earlier).

Cost-Benefit Analysis: No buyer buys a thing in isolation. He is always comparing an apple to an orange to a box of Cheerios. He only has some much money (or time), so which gives him the most satisfaction for the buck? It is my hypothesis that we should use this kind of thinking (or should) for each project. And we should do this at a more granular level also.

Pareto's 80-20 Rule: Pareto posited that in any population, there were "the vital few". This is translated into saying: "20% of the things provide 80% of the value." And this is true for any size population (or at any level of population, if you prefer). So, it is probably true of projects, of themes within a project, of nitty "requirements" within a story.

My hypothesis is that, in any set of stories for a project, there are at least one or two order of magnitude difference (given the same size story) between the BV on one story versus another. This information is very valuable. This is a very common (although not universal, I think) situation for product backlogs.

Knowledge-creation: There is a whole set of ideas around knowledge creation. We will greatly simplify them here. First, that a team is better at learning/discovering new things than an individual. Second, that knowledge goes through cycles of conversion from tacit to explicit (and perhaps back again). Third, that knowledge creation is energized by putting people together in a place and providing a context (meaning). (See The Concept of "Ba".) Fourth, that knowledge can be said to self-organize into a product (solution). There is increasing evidence that knowledge-creation is the core competency. Our hypothesis is that applies to Business Value in many ways.

Learning Methods: We think BV should be used in the context of (to pick one instance) Deming's PDSA model. This is Plan-Do-Study-Act. (Basically the scientific method.) We think short, time-boxed iterations are key. That some data is a key learning device (comparing expected results to actual results). And that general indicators are more important than slowing down for precision and "accurate" numbers. In the end, though, it's about people, not the numbers. The numbers are only a rough guide to the people. In many cases, out-of-the-box intuition may be a better guide.

A full BV engineering approach

Let's give a rough first definition of what we think a minimal BV approach would be (the fancier term would be a full BV engineering practice).

• a well-communicated high-level definition of business value (this might have multiple dimensions)
  
• a well-communicated operational definition of BV for the specific effort
• a clear way to measure whether that hypothesis (as embodied in the operational definition) was correct; or how incorrect it was (probably a likelier outcome)
• a confirmation that this definition actually energized behavior (eg, the programmers wanted to see success in that way) and that it was used in a way that allowed small adjustments toward a better outcome
• a clear set of practices for using this definition throughout the course of the project
• a clear way to modify those practices, so that better practices could emerge over time
• a common understanding about the time-boxes around the practices, and a continual questioning about whether those time-boxes (presumably at different frequencies, depending on the practice) were the most effective in guiding a better delivery of business value in this specific case
• a set-out way to develop the people to perform these engineering practices (training and the like)
  

There should also be some discussion about the dimensions of the word "better" in the next-to-last bullet. That might mean faster, more, higher quality (perhaps more reliably hitting the target), cheaper, etc., or some combination of those, depending on the context. My personal bias would be, first, to optimize faster delivery.

It is probably necessary to say (just as we still have to say that agility requires greater discipline of a sort) that the overview of the BV engineering approach above does not imply something like BDUF, endless documentation, high ceremony, etc.

* * * *

Now, does all that discussion make sense in the context of your current definition of Business Value? I hope so.

I would greatly appreciate your comments on this discussion. And on later related discussions. Or earlier ones. More to come.

Suggested Resources for CSM Course NYC Feb 28-29

Here are some of the resources we mentioned in the course.

First, a suggestion and two cautions.
Suggestion: Always tightly link thinking and action.
Caution: "Words, words, mere words, no matter from the heart." W. Shakespeare
Caution 2: "Of making many books there is no end, and much study is a weariness of the flesh." Ecclesiastes 12:12

The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition) by Frederick P. Brooks. It includes the famous essay on No Silver Bullet.

The New New Product Development Game by Takeuchi and Nonaka. Let me ask you to go to www.hbr.com and look it up. It's a Harvard Business Review article. It costs $6 (softcopy). If you need to see it before you buy it, contact me.

Rolling out Agile in a Large Enterprise by Gabrielle Benefield. This is about Yahoo. Many good suggestions.

Software by Numbers: Low-Risk, High-Return Development by Mark Denne and Jane Cleland-Huang. This book explains what you should go to Minimum Marketable Feature sets to get incremental funding. Or...it pays to go Agile.

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn. Key stuff.

Agile Estimating and Planning (Robert C. Martin Series) by Mike Cohn. Again, key stuff.

Leading with the Heart: Coach K's Successful Strategies for Basketball, Business, and Life by Mike Krzyzewski and Donald T. Phillips. I live the Duke Blue Devil basketball team. Not surprisingly, I find basketball an apt metaphor for a software development team. Coach K gives a lot of great advice about building a winning team.
The Concept of "Ba" by Nonaka and Konno. This article gives an introduction to this subject.
***
There are many other great resources. This is a start. You may also want to look at earlier posts of this sort. Start here.