Dark mode switch icon Light mode switch icon

Show me the money

5 min read

Don’t expect any return on investment in IT

Earlier this week, during a short twitter exchange with @dhinchcliffe, I decided to write a more substantial post about why your IT department needs to stop chasing its own agenda. This will be an easier case to make if you realise that IT investments and IT projects generally don’t make any sense. Rather than try to persuade you of this (no doubt you will already have an opinion about this) let me share a tool I use all the time and challenge you to show me where I am going wrong.

The tool is an outcome map - you might know it as a benefits roadmap* or benefits logic. With a little practice this tool is really quick and easy to use. I once developed a map for a multi-million pound digital transformation project during a 40 minute train journey with a key stakeholder followed by about 40 minutes at my desk to make it presentable for the project board. You can build one collaboratively with a team if you can find a bit of space and a pack of sticky notes.

Most people start the map by listing the key deliverables or products. These might be business capabilities, IT systems, written artefacts or a combination of all of these depending upon what you are working on.

Outcome map: Products Outcome map: Products

Next list out the expected benefits which might be increased revenue and profits, tangible cashable savings, increased market share, efficiency gains, reduced risk or quality improvements.

Outcome map: Benefits Outcome map: Benefits

Are you thinking that this is the wrong way round? Well you are correct but we are working on a project or initiative you already know. Outcome mapping works even better if you do it right at the start and work back from the benefits. Let’s keep going for now. In the middle (always leave loads of space here) are the intermediate outcomes which are generally changes to behaviours, ways of working and business operations.

Outcome map: Intermediate outcomes Outcome map: Intermediate outcomes

Finally you need to put in links which show how the intermediate outcomes contribute to the benefits and how the products contribute to the outcomes.

Outcome map: Contribution flow Outcome map: Contribution flow

Don’t worry if the first couple of iterations are a tangled mess - this is quite normal. You can create an executive presentation version later if you want - a kind of business case on a single page. It can be useful to show stakeholders the raw map so that they can appreciate just how tough your project will be but it is risky and you need to know them very well. There are all sorts of useful annotations you can add but, for now, let’s just add a warning sign for key risks or constraints.

Outcome map: Risks and constraints Outcome map: Risks and constraints

Take a few minutes to think about one of the IT projects you know and what kinds of bubbles and links you would put on your map. There is a good chance you will notice several of these kinds of challenge.

  • Some worthy sounding products make no contribution to the benefits. Often this reveals that some intermediate outcomes have been missed but, occasionally, it exposes waste that can be cut. Many strategy or architecture products require extra intermediate changes to make them useful but sometimes they should be dropped.
  • Some benefits have no contributing outcomes or no complete chain back to any products. These benefits might still be relevant but they should certainly be put at risk and the costs to achieve them might be grossly underestimated. As an example, I have seen public service organisations and IT departments try to claim benefits by generating revenue from their intellectual property with no thought of the capabilities needed to do this or how they are going to acquire them.
  • There are feedback loops between products, outcomes and benefits. For example, early savings may be required to provide funds or free-up staff time to invest in further work. Also, operational changes might need to be implemented so that lessons can be fed back into product development. These feedback loops should not be avoided but they do require special attention.

The final challenge is the one that really destroys the idea of IT project and investments.

  • There are no direct links from the products (such as some new IT) to the benefits. The products make some changes possible but unless the changes to business operations are followed through the benefits will never materialise.

Now, your challenge is to find a project or investment that can deliver results with just some IT. If you are feeling really brave share it in a comment below or post it to your favourite social network.

John Thorp’s Information Paradox goes into some detail about benefits roadmaps and a download is available via Fujitsu here.


As I am still waiting for someone to take the challenge here is an example of a what some people consider to be an IT project - migration to cloud computing. As you will see below, this is not really an IT project.

Cloud migration example Cloud migration example

Originally published on by Richard Barton