This is the second in a series of postings providing updates to our book, “The Business Value of IT.”  This posting explains in more detail the Business Value Index or BVI.  BVI was developed by Intel’s IT organization so it comes with the advantage of having been developed by practitioners.

BVI considers three dimensions of IT value:

- Business Value

Business Value measures both the tangible and intangible benefits of a project on a set of weighted criteria.  While there is the advantage of starting with Intel’s tried and tested criteria and weights, there is no reason why your organization could not adjust these to suit its own needs.  Some examples include:

- Customer need
- Business risks
- Technical risks
- Strategic fit
- Revenue potential (recognizing that this is not a fixed number is important!)
- Level of required investment
- Innovation
- Learning

- IT efficiency

IT efficiency measures a project’s impact on the IT organization.  For example, how well does the proposed project “fit” with the organizations enterprise architecture policy (where we are now) and strategy (where we plan to be in the future).  Again, a set of weighted criteria are used.

- Financial Criteria

The model separates business value form financial value.  It is possible for a project to have great business value with little or no financial value.  Projects with negative financial value can still be imperative for the business e.g regulatory implementations or “must have” competitive features.  The model uses Net Present Value, Internal Rate of Return and payback period (see our book for definitions) to assess financial attractiveness.

Intel uses the scores for these 3 dimensions to generate a value visualization of the comparison between candidate projects:

Back in the day, IT was synonymous with flexibility.  “Software” meant exactly that - the ability to implement things is a “soft” way that could be easily changed.  Nowadays, in many cases, software is as rigid as hardware or even more so.  Similarly, the IT group is too often the least flexible department in the organization - “You want what? When?”

Today, we find ourselves in times when businesses are looking to cut back.  Strong IT departments can flex their capacity and cost to meet their business needs.  Poor IT departments don’t have a plan for changing capacity quickly - they have a gas pedal but no brake.

I was reminded of this important quality of an IT department by a guest editorial by Edge Zarella in the ISACA Journal (Vol. 4 2009).  Edge neatly summarized the world that IT Professionals are facing:

• Intense pressure to cut technology costs
• Mandates to improve operational performance
• A need for technology to realign to meet new business needs
• A focus on cash management and a priority around liquidity

It was this last bullet that caught my eye.  It’s not enough for the IT department to claim they have “scaled back.”  They must be able to hand back cash.  How?  Much of the cost of IT departments is in the form of people.  Surely, head count is difficult to flex up and down  quickly, especially if the department is already running lean?  This is only true if there are no advance plans to flex size.  This has to be an important element of all outsourcing contracts and a key justification for starting an outsourcing engagement if you don’ t already have one.

How can we measure the strength of our IT department for flexibility like this?  How about the percentage of budget they could hand back given 3 months notice?

We can take this further.  As we climb out of recession of if a terrific business opportunity presents itself tomorrow, we can turn this IT flexibility metric around and measure how much capacity can be added given 3 months notice.

These metrics have to be supported with detailed plans that are reviewed and revised quarterly to reflect changing market conditions.

If your interested in this blog, you might find the interview that I did with Ann All particularly the focus on risk.

Ann All\’s interview with me!

Bill Curtis has been a friend and partner of DCG for many years and I was surprised and delighted to find that he is now the Chief Scientist of one of our other partners, CAST Software.  To get a sense of the contribution that Bill makes to our field and to get some really useful equations and numbers, I invite you to read his recent white paper, the “Business Value of Application Internal Quality”. Within this document, are several pages on mathematical calculations on determining business value / impact of application failure. Key topics include Corrupted data, violated security, terminated business transactions, lack of business agility, and others.

the-business-value-of-application-internal-quality

I received the following question in an email from a reader and I thought that it might be of more general interest:

“I am a 24 year old student from Austria (Innsbruck) and I study Management and IT. At the moment I am writing on my thesis that is dealing with capturing the business value of a test center. That’s why I am really interested in your book and work. Due to the fact that you are an expert in this area I wondered if you can suggest literature for my thesis. And do you have hints for me or suggestions concerning meaningful methodologies? The main challenge is that a test center has an indirect “business value” due to the fact that it is supporting business software in quality concerns.”

I replied:

“I confess that I have not had as much time as I might like to consider your thesis.  I have not done any online research but simply referenced books that I have on my bookshelves.  Nonetheless, here are some ideas that might be helpful:

1. The value of testing is essentially a risk management problem.  At one extreme, if we perform no testing, what are the potential financial or other value consequences to the business if/when serious and minor defects are discovered by the software customers?  At the other extreme, the cost of removing 100% of the defects in the software through testing would probably be too high so what level of defects is acceptable?

2. If we take the risk management approach to this, we would identify the risks, quantify their potential impact, quantify their probability and then use some sort of algorithm to aggregate the risk cost which we could equate to value of testing.

3. Steve Tockey includes lots of value treatments on software investments in his book, “Return on Software.”  In particular, he has a short section called “How much software testing is enough?” (page 474) in which he identifies this as an optimization question and cross references the other chapters in the book which will provide the tools to perform this optimization exercise so that, as he says, “… the question can be answered from a business perspective.”

4. You might also want to consider the risk management profile of alternatives to testing such as more rigorous design (lots of books on this topic), and peer reviews earlier in the process (see “Software Inspection” by Tom Gilb and Dorothy Graham).  How much these improve the risk management profile?  Generally, it is less expensive to fix a problem earlier in the process than it is at the test stage.

5. If you are interested in building a model of the software development process, take a look at “Metrics and Models in Software Quality Engineering” by Stephen H. Kan.”

Does anyone have any other suggestions?

A colleague pointed me at an interesting dialogue between InformationWeek’s Bob Evans and his readers with the above title.  Bob started the dialogue with an article that listed the eight top priorities that he believes CEO’s have for CIO’s.  Good list.  Good article.  While I support the whole list, my eyes naturally scanned down to #8, “Create a massively transparent organization with all metrics focused on business value.” Yes!

While these articles sometimes end with a rhetorical request for readers to send their thoughts (My requests are NEVER rhetorical), in this case, Bob followed up with an article describing some of the responses.  Somewhat unusually, the responses were great and really added something useful to the original.

For example, executive searcher Judy Homer offered four suggestions on the types of business-value “evidence” those CEOs are looking for:

“During their interviews they are asked to provide metrics and concrete examples of:

1. How they have contributed to their companies’ success and market share.

2. How they’ve increased the level of customer satisfaction and improved the efficiency of the business through the products and/or services they’ve delivered.

3. What their strategic plan would be for delivering value during the first 6-18 months in their new role.

4. How they’ve controlled the cost of delivering effective IT solutions.”

I’d go one step further and say that all CIO’s should ask themselves these four questions every year.

Bob Evans Original Article

Reader responses