If you have been paying attention to ITIL4® you will almost certainly have noticed the buzz around the terms ‘outcome’ and ‘output’. I’ve had many conversations over the past months about the difference in these terms, particularly the huge value companies can realize when they start thinking in terms of business outcomes. Unfortunately, many people are still using these two terms interchangeably. In this article, we’ll define the differences between outcomes and outputs, give real examples and best practices, and share additional resources.
Outcomes and outputs: a real-world example
To get the context right, let’s start with a simple, non-IT example. Imagine it is Billy’s 5th birthday. You go to the local bakery and order a Spiderman-themed cake for the morning of the party.
If I ask a group of people the outcome of this transaction, most people will answer that the outcome is the birthday cake. That is not correct. The outcome of this will be a delighted birthday boy and a group of happy, cake-filled 5-year-olds. The cake itself is the output, provided by the bakery. If the cake had not been tasty, or if the bakery had delivered a fairy-themed cake instead of the desired Spiderman, then the desired outcome—happy kids—would, in all probability, not have been achieved.
Defining business outcomes and outputs
Thinking in business terms, here’s how we can define these two terms:
- The outcomes are what the business wants or needs to achieve.
- The outputs are the actions or items that contribute to achieving an outcome.
An easy way to think of this is that outcomes are the results, and outputs are the activities that support the desired results. For example, a business outcome could be ‘increased customer satisfaction’. An output that can help achieve this might be a responsive online ordering system.
If we delve deeper, outcomes are usually the benefit your customers receive from the technology solutions you deliver. To move towards achieving outcomes (results), you must truly understand your customers’ needs. What challenges are they facing? What are the issues, constraints, and priorities that are important to them? Understand what causes them inconvenience, what costs more than it should, what takes more time and effort than necessary.
Armed with this information, you can shift your focus to the outputs (activities) that make positive changes in these areas.
Delivering outputs, achieving outcomes
It is important to understand the difference in these terms not just for clarity, but because outputs are much easier to measure than outcomes. An output is nearly always quantitative, with data available to show whether these have been delivered. Outputs are easy to report on and to validate. There is no grey area.
Outcomes are more challenging to verify because they are both qualitative and quantitative. Whether your outcomes have been achieved will rely, to a great extent, on the perception of the people who receive the service. Perceptions are not easy to measure or report on, but it is essential you find a way to do so.
Remember that outputs are simply a means to an end. If your organization has achieved all stated outputs, but you haven’t achieved the desired outcome, then you need to review the outputs to make sure they are correct. Measuring the achievement of your outputs alone, without measuring outcomes, can produce the “watermelon effect”. All reports and dashboards are showing green, but when you delve deeper, reports on the achievements of your outcomes are all red: your customers are not happy.
Now, I am certainly not suggesting that you no longer need to report on the achievement of IT outputs. Not at all. Instead, you need to express these outputs in terms that the business understands—showing exactly how they contribute to the business outcomes. Rather than telling the business that you achieved 99% service availability, you should report that customers were able to make 60,000 successful transactions per day. This provides clear business context and shows the value that IT outputs deliver.
How companies can understand outcomes and outputs
Recently I’ve been working with a business that is moving from legacy services (often paper-based) to a new digital platform. Many of the business owners have been working there for 20 years or longer, so they find it difficult to translate the work they do currently to the proposed new services.
Workshops made apparent a big reason for these difficulties: the team was often thinking in terms of the outputs they currently produce, then attempting to transition these to the digital platform. Changing this thinking was essential. I asked the team to articulate the business outcomes they need to achieve—this completely changed the direction of this and subsequent workshops.
With the desired business outcomes clearly stated, the team was able to let go of historic outputs and define new outputs that would enable their business outcomes to be achieved. This realization was a watershed towards a new way of working. Now, when the team gets stuck in discussions on process, they pull back to stated outcomes. This focuses them on the outputs they require, stepping away from old processes in order to build new processes.
For me, understanding the difference between outcomes and outputs was a real ‘ah-ha’ moment. I see the same flash of understanding when I explain this to colleagues and customers, both within IT and in the larger business.
Look at what you are creating with the IT services you are providing—are you putting a cake on the table or delivering a room full of happy children?
Additional resources
For a comprehensive understanding of ITIL, see our ITIL 4 Guide. To learn more how successful service level agreements support outputs, and therefore outcomes, see our SLA Best Practices for ITIL.
