Main Menu
Home / IT Governance / Legacy Support / Outcomes and Outputs

Outcomes and Outputs

gardeningUsing the example of the work he performs in landscaping, Michael Scarborough describes how some people get a bit confused when ITIL describes outcomes and outputs. Outcomes are the result of “carrying out an activity”, whereas outputs are “what a service provider delivers”. In his example, an outcome is: a raised play area for his kid's swingset. The outcome is: a happy child. Keeping this in mind, Scarborough explains how some service providers think too heavily on one than the other:

Service providers sometimes spend too much time focusing on outputs rather than outcomes, which often causes the customer to lose some of the value promised by the service. Some service providers involved in delivering IT services might be too heavily focused on the technology rather than how the customer uses the technology to facilitate outcomes. For example, a service provider might be focused on ensuring that a network is available for customers 24/7 without considering how customers use that network to facilitate outcomes. In this case, customers might have periods of peak volume where network performance suffered and periods of low volume for which the service is basically over-engineered. This is because the service provider is focused on the technical aspects rather than how those technical aspects are used to do something that the customer wants. The service provider hasn't investigated patterns of business activity and how these are supported by the underlying technology.

Scarborough notes that it's important for service providers to understand how their outcomes (the activity they perform) affects and is used by the customer (the results of that activity). By recognizing this distinction organizations can better understand if they are focusing on one element more than the other, and adjust to better serve their customer. 

About Anne Grybowski

Anne is a former staff writer for CAI's Accelerating IT Success, with a degree in Media Studies from Penn State University.

Check Also

COBOL Is Still Around Because Nothing Better Has Replaced It

When COBOL was made in 1959, no one could have dreamed that it would outlive …

Leave a Reply

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

Sorry, but this content
is for our subscribers only!

But subscribing to ACCELERATING IT SUCCESS is FREE and only one click away!
Join more than 40,000 IT Professionals and get the best IT management articles to your mailbox with Accelerating IT Success!

Unsubscribe at any time