The Business of IT Blog

Outcomes vs Outputs: What’s The Difference?

4 minute read
Kirstie Magowan

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.

Access the 2020 Gartner Magic Quadrant for ITSM

The Gartner Magic Quadrant for ITSM is the gold-standard resource helping you understand the strengths of major ITSM software vendors, insights into platform capabilities, integration opportunities, and many other factors to determine which solution best fits your needs.


These postings are my own and do not necessarily represent BMC's position, strategies, or opinion.

See an error or have a suggestion? Please let us know by emailing blogs@bmc.com.

BMC Bring the A-Game

From core to cloud to edge, BMC delivers the software and services that enable nearly 10,000 global customers, including 84% of the Forbes Global 100, to thrive in their ongoing evolution to an Autonomous Digital Enterprise.
Learn more about BMC ›

About the author

Kirstie Magowan

Kirstie has been active in service management since 2000, working in a wide range of organizations, from primary industry to large government entities, across New Zealand and Australia. Kirstie has spent much of the past 15 years working at a strategic level as an ITSM consultant. She regularly takes on operational assignments to remember what it's like to be on the ‘coal face’ of service management, as this allows her to provide real and actionable advice as a consultant. Kirstie first qualified as an V2 ITIL Manager in 2004 and spent four years working as the Chief Editor for itSMF International from 2012 where she built a strong global network of service management experts. Kirstie is a member of the authoring team for the ITIL4 book - Direct, Plan and Improve, and a contributing author to the ITIL4 practice guides.