As the new year approaches, debates over the “value” of IT and business projects intensify; it’s not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I’m hearing more about the struggle to quantify business value, especially when selecting those few projects that will “make the cut.” We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (yes, don’t scoff – it is possible – more in a later post…)
However, I think there’s an interesting vision in some people’s minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately – as long as they all have business values assigned.
I don’t think assigning a value to every proposal is realistic, and certainly not something to aspire to – well, not directly anyway. There are a number of significant hurdles to deal with – the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty …
As the new year approaches, debates over the “value” of IT and business projects intensify; it’s not holiday stress, but the excitement of the approaching New [fiscal] Year. Lately, I’m hearing more about the struggle to quantify business value, especially when selecting those few projects that will “make the cut.” We will definitely iterate on our scoring framework, adding a cost / benefit template to facilitate more apples-to-apples comparisons between projects (yes, don’t scoff – it is possible – more in a later post…)
However, I think there’s an interesting vision in some people’s minds; a sort of value-optimization Utopia where, even with hundreds of project ideas on the list, the executive team has the insight and ability to select the best projects and fund them appropriately – as long as they all have business values assigned.
I don’t think assigning a value to every proposal is realistic, and certainly not something to aspire to – well, not directly anyway. There are a number of significant hurdles to deal with – the reluctance of people to commit to hard benefits, the lack of suitable productivity metrics for new technologies and methods, and the difficulty of communicating innovations to those who didn’t think it up on their own (i.e., close the patent office, we’re done).
Yet, even if you did address all of those problems, and could easily measure impact and communicate effectiveness on 300+ terrific project ideas — how could anyone to claim the ability (or the time!) to rank such a list from “best” to “worst” (or, since I don’t propose projects are bad to begin with — “most best” to “least best”)? Truth is, they don’t — most of the business leaders I’ve worked with have no interest in looking at 300 projects, and would be a tad perturbed if I tried to get them to peruse such a list. Do you appreciate it when your teams bring a thousand problems for you to sort through?
Rules of Thumb
Most people have a favorite way of eating their elephants. Yes, one bite at a time — but where to start? How to carve?
Deliver Small, Iterate, and Evolve: The agile among us would focus on short-term deliverables with small measurable steps to make incremental improvements. Speed and iterations will drive the quality and help focus on those areas of work that have the most short-term promise.
Focus on the Big Rocks: The biggest and toughest problems — or the projects with the most benefit — are sometimes so daunting that they intimidate us into dealing with “the easy stuff”. Clear your calendar and tackle these larger opportunities first, else you’ll never get to them.
Focus on the Constraints: Understand which resources are keeping you from launching multiple projects at once. These are typically people — in key positions, with monopoly knowledge. Simplify things by prioritizing their projects first — but strongly consider launching efforts to remove the constraint, by having them document, train, or automate their knowledge.
Practical Problem Solving
As I proofread this post, it sounds like a checklist for common sense; no surprises, just a different level of detail depending on the organizational level you are speaking with. It’s important to understand the fractal nature of business challenges; no matter where you stand in the organization, the number of items on your ToDo list (and/or the number of challenges you are juggling) is roughly the same. The sooner you can put yourself in the other person’s shoes, and speak to them at the level of detail they (not you) need — the more effective your conversations will be.
Besides, they’re paying you to solve problems, not define them.
Previously …
- Measuring and Reporting IT Value (2 of 2) (November 20, 2007)
- Innovation That Matters – Substance Over Style (January 12, 2008)
- Three Business-Case Arguments for Agile, & The Moose On The Table (January 14, 2008)
- Optimizing the Wrong Part of Knowledge Management (March 16, 2008)
- The Innovation Generation – Communication Styles (April 1, 2008)
- IT and the Business are Closer Than You Think (June 28, 2008)
- Facilitating Innovation: Establishing an Environment of Possibilities (August 22, 2008)
- A Plea for Empathetic Communication (November 16, 2008)
Technorati Tags: business value of IT, documentation, innovation, Knowledge Management, people management, PMO, project management
