I've written here about value and benefits, but I've never talked about the underpinnings of Benefits Management. Time to correct that oversight.

Early in my consulting career I worked with a group of folks in the UK who were Cranfield business school disciples. Cranfield has developed a framework they call Benefits Management which talks about ways in which you can ensure IT actually delivers benefits to the business. This framework instantly made sense to me. As a technical guy, I had always known in the back of my head that IT had to serve the business in order to be successful, but I never really thought about it much. Benefits Management was the first framework that explained to me in ways I could easily understand how to bridge that all important gap.

If you're interested, you really need to take the course or read the book, but I'll give you a flavor of it here.

In summary, the idea is that when you make IT decisions, you need to make them based on business benefit. That is to say, how much will each project, program or architectural decision impact the business. This may seem difficult, and it is. The idea that Cranfield introduced me to that helped me understand was the idea of indirect but specific and measurable benefits. Cranfield has some very specific rules about benefits that keep you from creating false value statements. My favorites are:

1) A benefit must be measurable. If you cannot measure it, it's not a benefit by definition.
2) A benefit must have a business owner. If you claim that your software will increase sales by $2M, then the Sales VP must be willing to accept a higher sales quota as a result. If not, it's not a benefit by definition.

I cannot tell you how many IT planning meetings I've been in where one or both of these simple rules have been violated. A classic example is worker productivity. "Deploying this software will increase knowledge worker productivity!" Really? By how much? Is the COO willing to fire people because the company is so much more efficient? Or will production quotas rise because of this? If not, it's not a benefit.

In fact, flagrant violation of these rules led to once was once called the productivity paradox. Although this theory is largely debunked, it shows that massive technology infusions don't result in value unless they're carefully managed.

The second major revelation that the Cranfield framework brought to me was the idea that IT should focus on the top line of the business rather than on the bottom line. In many organizations, IT is simply a cost center. This means that you should do IT as inexpensively as possible. Containing costs leads to higher profits. Every dollar you squeeze out of the bottom line goes directly to profit. Unfortunately, as an IT guy this means you're the one getting squeezed. Not a fun place to be, really.

On the other hand, IT organizations that add to the business' top line are much better places to live. If you can create additional business value for your organization then you can justify higher budgets and larger teams. It's also way more fun to work in a place that's creating new things and adding value than a place that's all about cost containment. Since my exposure to Cranfield I have always sought to be on the value side of the house as opposed to the cost side. This change in thinking really changed my professional life.

ITA