As one of the newest consultants to join the Systemscope team, I can honestly say that I feel as though I am up to my eyeballs in new terminology and acronyms.  Mastering this lingo is like learning a new language, and as a consultant one of my roles is to translate, clarifying areas of confusion to ensure that everyone is talking about the same thing.  As I have come to understand, one client’s “framework” is another’s “strategy,” “action plan,” etc.  One of the key things I have learned in my time at Systemscope is that discussion and setting expectations at the outset of a project – including defining the terminology that will be used in order to ensure we are all “singing from the same hymnal” – is so important.

Amidst all of the terminology thrown around regularly by consultants and government workers, is the common conflation of “outcomes” versus “outputs.”  For casual use, the two terms may be almost interchangeable but, for a government-funded project, which should show measurable and useful returns when completed, it is key to first understand the difference, and then clearly define each of them.

When working with clients under a new contract, the conversation often begins with the client specifying a certain type of deliverable they would like to have in their hands by the end of the engagement, with the idea that the deliverable is the desired outcome.  A deliverable is, in fact, simply an output of a project, developed in support of a larger outcome.

This preoccupation with specific deliverables rather than desired outcomes is a common side effect of the procurement process, for which outputs (often in the form of expected deliverables) must be specified. While it is useful to think in terms of deliverables or outputs in order to determine scope of effort for a given project, we must not lose sight of the desired outcomes – what do we really need to achieve as a result of the engagement?

Clearly defining outcomes BEFORE outputs at the outset of a project has become a key Systemscope principle: outcomes over outputs. Applying this principle means getting a client to first think in terms of outcomes, or, what they would like to achieve or enable themselves to do.  Once the client is able to answer questions about outcomes, keeping the “outcomes over outputs” principle in mind, then the specific deliverables (or outputs) that will enable the achievement of these outcomes can be discussed.

Remember – first understanding a desired outcome allows you to define the output required to meet that outcome. Try not to get hung up on getting Deliverable X until you know that’s what you need! 

A helpful tool we make use of in support of the “outcomes over outputs” principle is Systemscope’s “Deliverable Definition Template”.  This tool is designed to ensure that any deliverables identified are well-defined and will, in fact, support the identified outcomes. It keeps everyone on the same page rather than getting preoccupied by deliverable types or outputs that may not support the larger outcomes of the project.

Take some time at the beginning of your next project to consider the Systemscope “outcomes over outputs” principle and fill out the Deliverable Definition Template.  The clarity this principle and simple task brings to any project is well worth the effort, whether it’s between clients and consultants, or for independent engagements that require some framing.


By Virginia Start (@virginiastart)



Leave us a comment: * Your information is never shared