Outcomes vs Outputs: Why it's important to understand the difference?
For the more pedantic among us, the difference between Outputs and Outcomes is significant and important. At Ad Esse, we spend much of our time helping clients to focus on the outcomes they are trying to achieve. We also help them to identify their business processes, which inevitably means clarifying both inputs and outputs.
If you think you know the difference, or just want to remind yourself about why it might be important, read on…
Let’s start with some definitions.
Processes deliver OUTPUTS. In other words, what pops out of the end of a process is an output.
As you can see, Outputs can usually be seen, felt, or moved about. If you can get your hands on it, it’s probably an output from some process. If you were running a Project, you’d probably call it a Deliverable.
Now, the important thing is, Outputs are only produced (or should only be produced) because there is a customer of the process who wants them. In our example processes above, the three customers are: the Line Manager who has a vacancy to fill, the person who wants a new mortgage and the person who wants the meal.
Customers usually have expectations about both the process and the output (how they get what they want, and what they actually get). That’s where Outcomes fit in.
An OUTCOME is a level of performance, or achievement. It may be associated with the process, or the output. Outcomes imply quantification of performance.
Our newly appointed people may be:
- too late for the line manager (Timeliness)
- capable, or incapable of performing their role (Competence vs. Requirements)
- too many, or too few (Quantity)
Our Mortgage Offer Letter may be:
- correct, or full of errors (Accuracy)
- easy to understand by the customer, or full of jargon ( Customer Perception of Clarity)
- what the customer wanted to see, or not (Customer Satisfaction)
Our Meal might be:
- too hot, or too cold (Temperature)
- too much to eat (Quantity)
- tasty, or disgusting (Customer Perception)
Because it’s about performance levels, you can’t get your hands on an Outcome! But, you can draw it on a graph.
You can express Outcomes, quantitatively, on a Line Graph, showing how performance changes, over time. And, if you’re really serious about continuous improvement, you’ll also be showing target performance levels and relevant benchmark comparators on your trend graphs.
Is it that simple?
At one level, it is that simple. Unfortunately, the relationship between processes, outputs and outcomes can be difficult to untangle. Often, there will be a many-to-one relationship between processes and any particular outcome.
Take Staff Satisfaction. A desired organisational objective might be to achieve an improved level of Staff Satisfaction (outcome). There is no single process that causes Staff Satisfaction. It is the result of multiple processes and their associated outputs. These processes would include staff development, appraisal, reward and recognition etc. So their is no single process that delivers an Output called a Satisfied Employee.
Another example. Many Local Authorities have the (very laudable) objective to develop a thriving local economy (Outcome). Again, there are many processes, with their outputs that impact on that outcome and the level of achievement. The processes might include those to attract inward investment, or providing start-up funds to entrepreneurs. A thriving local economy is an Outcome, not an Output. Incidentally, it may not be an easy to measure outcome once you get the economists and statisticians involved!
Why do you need to know the difference?
Well, if you are trying to improve your organisation’s performance, you need to be able to describe the Outcomes you want to achieve (or have to achieve if a Stakeholder such as the Government is driving you). You need to be able to express these quantitatively, so you can track progress over time. Then, you can decide which of your organisation’s processes will impact on each Outcome. At that point, you will know what the Outputs are, that also impact on the Outcome.
Say, one an organisation makes Widgets. And, one of their desired Outcomes is happy Customers (measured by their Customer Satisfaction Index). They also want to make a profit on the widgets that they sell. Three of their key processes are widget-making, widget-distribution and customer billing. In order to achieve the two Outcomes these processes must:
- produce widgets that are right first time (cost efficiency contributes to profitability)
- produce widgets that meet the customer’s specification (quality contributes to customer satisfaction)
- deliver widgets undamaged and on-time (both contribute to customer satisfaction)
- issue accurate invoices (contributes to customer satisfaction)
- collect cash from customers by the due date (contributes to profitability)
So, by starting with desired organisational outcomes, you can make clear linkages to key processes. For each of those processes, you can then decide what its contribution must be towards the organisational outcomes. Hey presto, high-level business objectives deployed down into real processes, operated by real people.
It works the other way round, too. For those organisations who know that they want to work on improving their processes; the question to ask is what are the Outcomes that the process is trying to achieve. Then, improve the performance of the process and its outputs accordingly.
Director, Improvement Skills Consulting Ltd.