Defining the Business Value of a Project

I’m following a project management meme lately; while freely admitting that I’m oversimplifying some complex topics, I will forge ahead with … project “value”.

At work, we’ve been talking about the classic challenge of putting a business value on a project. I call it a “classic” challenge because it’s a basic requirement for every prioritization exercise that I’ve been exposed to. You know the drill – we have 10 projects, but only time and resources to do 5. How does the organization pick those Fortunate Five? It could be is simple (yet painful) as gathering all the project sponsors in a room – no one leaves until we get a forced ranking. Or let the prioritization happen surreptitiously, as key project sponsors conduct a battle of personalities, or duel it out by job title.

Most would prefer a transparent process, but how does one drive an apples-to-apples comparison between a capital-intensive infrastructure upgrade, custom software development for a marketing program, and a replacement air conditioner for the tool room? Yes – some of us need to prioritize IT work in the same queue as operational projects required to keep the business running.

It actually simpler than it sounds, once you realize you’re not looking for hard dollar benefits. This isn’t a capital request, that needs a firm ROI; we just need a reasonable value statement that lets us compare different types of projects. And there’s only three basic types of “value” – revenue growth, cost reduction, and risk management.

The first two are obvious; I’m implementing a system that will grow the business / sell more product, or I’m implementing a system that allows me to use less power, less materials, less printing costs, whatever. Risk Management is a powerful value proposition that covers things like infrastructure upgrades, software updates, employee training, and process documentation. Another important type of risk management is compliance – with government edicts, and customer & regulatory requirements.

Please note [again] that I’m not talking about hard dollar benefits; I’ve seen plenty of projects that are prioritized based on “productivity”, which is invariably a soft dollar benefit (if this [revenue-growth] CRM system makes my sales reps just 1% more productive [at $100M annual sales], the system will pay for itself in six months …). Another classic soft-dollar benefit is “cost avoidance” (by implementing this Magic New EAI tool, we can triple our sales without hiring any new customer service reps).

Most folks will have trouble understanding this simplistic idea of a business value; they get caught up in comparisons to the ROI calculations required for most capital investments. The PMO needs to reassure them – that’s way too much rigor for this exercise, we’re just looking for a quick and easy way to compare wildly different investments at a high level. We just need reasonable value statements, so we can quickly make a first cut, and focus our resources on the next one or two projects.

Of course, this lack of rigor might benefit project sponsors blessed with some degree of communication skills and personality … but now we’re negotiating, right?

This Post Has 0 Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Articles

You Can’t Run IT Like A Business (except Maybe You Can …)

Well-intentioned IT leaders, and their functional peers, want to apply run-like-a-business concepts like customer satisfaction and value creation to the operations of shared service functions. If we can describe things with the same words, we can apply the same fixes. But it's a bit tricky to restate things in a meaningful way...

Read more
Saving For A Rainy Day ... (Innovation Budget)

Accelerate Innovation with a Simpler Budget Approach

Organizations are desperate for innovation, but these are still investment choices that require complete and credible data to enable the right decisions. Developing a simple standard for characterizing all costs will accelerate decision making.

Read more