What are outcomes and how do we achieve them?

All IT projects are driven, or catalysed, by a desire or need to achieve outcomes, rarely do organisations take on such projects on a whim; they just aren’t that much fun.

Over the years as a conscientious solution provider we have been sure to ask each and every one of our clients “Why are you doing this, what do you want to achieve? What does success look like, how can we measure it?”

To clients, who are living daily with their challenges and aspirations the purpose seems obvious, but clearly capturing it in a way that is measurable can be difficult.

In my experience, Objectives are a little like dreams; they are obvious, self-evident and hang together perfectly, until re-told and scrutinised.

To help clients we created a dream catcher, a lofty name for a simple framework for thinking and capturing about outcomes, as follows:

Absolute outcomes:

  • Business mission
  • Strategic (shorter term) goals

Operational outcomes:

  • Financial benefits
  • Soft benefits
  • Challenges addressed

Ancillary (incidental or journey) outcomes

  • Organisation learning / team building / building resilience to change etc

Linking outcomes to projects & deliverables

If the first step is to clearly capture objectives, the next is to understand how the objectives can be delivered by a system and project.

I believe that this is where many projects stumble for the second time. Creating a link requires the creation of a clear and detailed set of requirements (deliverables) to link to, and this is not a trivial task.

All project pros agree that clearly defined requirements are essential to deliver a successful project. The inference or assumption is that, if the requirements are clearly specified they become the embodiment of the objectives and if successfully delivered then the benefits will surely flow.


  • A spec is never detailed enough to cover all implementation details &
  • The Why cannot be captured in (relatively dry / claustrophobic) functional requirements
  • The benefits must be driven, as much if not more than, the project itself, if they are to be fully realised

At Skop.es then, we have a different perspective on requirements, we see them as backward, as well as forward looking. Meaning that they should be used as a mechanism to tie the project back to its objectives as well as a way to manage and measure the project deliverables.

With this view in mind, we advocate an enhanced process for requirements gathering and use, as follows:

  1. Clearly capture your desired outcomes – using the structure outlined above
  2. At a detailed level capture the relationship between each requirement/deliverable and the objectives
  3. Keep objectives alive for example, base ongoing project decisions on the relationship to objectives – e.g. which system, which features are a priority etc
  4. Adopt objectives driven change and adoption activities – e.g. to achieve objective X people must be using feature Y to its full potential

Skop.es systemises process steps that overcome these challenges.

Practically this means that Skop.es efficiently facilitates the capture of each type of objective, captures each requirement, and then explicitly links each objective with requirements. This information is then presented back to enable project and system decision making.

Regardless of the system (Skop.es or Excel), we encourage you to adopt an Objectives Driven approach.