Image: Thumbnail of Report Cover

Download PDFPDF version of guide [3.0MB]

Download PDFPDF of Quick reference card [0.3MB]

Download PDFTips for PDF and HTML versions [0.5MB]

Download PDFWord version of checklists [0.1MB]

Focusing on key outcomes

“Previously, our project proposals had long lists of outcomes – including many generic outcomes such as efficiency, compliance, and scalability. It happened partly because we adapted new proposals from ones approved in the past.

However, the new Deputy Secretary bounced a proposal, saying ‘Put the two or three key business outcomes on the cover – these are the reason the Minister should support the project. Put the standard outcomes at the end. The Minister is entitled to think we do them as a matter of course’.

Giving clear prominence to the outcomes of interest to the Minister forced us to tighten up our thinking. Our proposals are much better for it.”

… Program delivery branch head.

Business outcomes

Better Practice results: No misunderstandings with stakeholders, including the Minister, on the intended business outcomes of proposals; improved ability of senior executives to manage their portfolio of projects, due to clarity of outcomes for individual projects.

The business outcomes of a project justify the commitment of resources and provide a key focus for project design and delivery.

As such, an important area for attention by the project sponsor is ensuring that the proposed business outcomes are:

  • clearly described in business-oriented terms, indicating who will benefit – for communication to the project funder and other stakeholders;
  • able to be measured or assessed and indicate the intended extent of improvement or target level of performance;
  • few in number – to help focus attention on the most important outcomes; and
  • realistically able to be achieved by the project.

To help develop business outcomes with these characteristics, it is useful for the project sponsor to:

  • maintain awareness of possible areas of difficulty in developing business outcomes;
  • explore and confirm the underlying reasoning – such as the flow of cause and effect – associated with the project;
  • use an understanding of the flow of cause and effect between project elements to identify important and realistic outcomes for the project; and
  • make a strong personal contribution to the process.

These issues are discussed below.

Possible areas of difficulty in developing business outcomes

As discussed earlier, in this Guide we use the term business outcomes to refer to the reasonably attributable outcomes from the use of the products of the project. For example, the desired business outcome from a new ICT system might be reduced operational costs, or improved client service.

Although achieving clarity of the desired business outcomes may appear straightforward, in practice difficulties can arise from:

  • Different values – different stakeholders may value outcomes differently. For example, one stakeholder may consider the priority outcome for a project is improved customer service, while another may give priority to reduced entity costs.
  • Different terminology or perspective – different people may apply different descriptions to the same idea or feature. For example, the making of payments might be considered by one person as an outcome of a new payments system; another person might consider making payments as an input to a desired outcome of changed behaviour by the recipients of the payments. Indeed, choosing to expand or reduce the scope of a project can change the terminology applied to the same idea or feature.
  • Ambiguity of expression – a desired outcome may not be expressed clearly enough to give the same understanding to different people.

The best outcome description may evolve slowly

“At the concept stage getting outcome clarity is important. Be patient – in a complex project it may take some time to evolve a crisp definition. For each project we prepared draft business outcomes – and then debated each one until we had informed agreement from all agencies.”

… Executive Director, program of cross-agency projects.

Exploring the reasoning of the project

At its simplest, a project delivers a product which, when used, leads to a desired outcome. In practice, the chain of reasoning is more complex, involving intermediate steps, uncertainty on the strength of cause-and-effect between these steps, and with a number of options to consider.

Accordingly, the concept stage is an opportune time to make explicit the underlying reasoning – or logic – of the elements of the project. Making explicit the underlying reasoning helps to achieve a shared understanding among stakeholders, and to clarify the business outcomes.

At the concept stage, the focus is exploration of broad outcomes and their enablers. It is useful to consider alternative perspectives on the desired outcomes, and innovative approaches to reaching them. More detailed consideration of specific solutions is best undertaken at the business case stage.

By way of example, consider a project to implement a new policy initiative which will make payments to assist individuals, with social benefits being the ultimate goal.

A ‘reasoning chain’ for a program delivery project: 1. awareness created; 2. claims made; 3. new payments system; 4. payments made; 5. behaviour changed e.g. increase education; 6. social benefits e.g. reduced dependency

The diagram at right shows the central reasoning behind the design of the initiative for this example. The first step of the chain is that awareness of the new scheme is created in order to encourage eligible people to make claims. The chain of reasoning proceeds to a social benefit such as reduced welfare dependency.

A benefit of exploring the chains of reasoning associated with a concept is that it encourages questioning of the reliability of the reasoning – for example: Is awareness of a scheme really the main determinant of the number of claims? How important is the ease of making claims? In turn, this questioning often opens up new possibilities for discussion, and may add new segments to chains of reasoning.

In many cases a high-level goal will have been identified – such as reducing administrative costs – and the task at the concept stage is to clarify what that means and how to achieve it. This will involve ‘working backwards’ from the desired outcomes to describe the underlying logic of the concept.

In some cases, such as a policy implementation project, a relatively complete underlying logic will have been described, and the task at concept stage is to clarify the scope of the project.

Finally, in some cases major elements of a project may be determined by circumstances, such as the end of an accommodation lease. In these cases there is often an opportunity to explore which of several possible outcomes might be emphasised. This will involve ‘working forwards’ from the known activities to the potential outcomes. For example, a project to move to new accommodation at the end of a lease could be seen primarily as an opportunity to reduce costs, to improve customer service, or to be a more attractive employer. While all these outcomes are desirable, in practice the business context for the entity is likely to give emphasis to one of them.

Identifying important and realistic outcomes

A useful business outcome is the last step along the reasoning chain that is clearly attributable to the project.

Having established the broad logic of the concept, the next step is clarifying the scope of the project. That is: what point along the chain of reasoning should be considered the business outcome of the project?

In the previous program delivery example, one scope could limit the project to the processing of claims; an expanded project scope could also include creating awareness about the scheme.

Selecting a project scope may involve a fine judgement. The decision-maker will often prefer to set an outcome that is of direct value to them – such as reduced costs, rather than an outcome that simply makes that possible – such as a new computer system. On the other hand, some items along the reasoning chain may only be partly attributable to the project, because they are affected or controlled by other factors. This is illustrated in the following diagram.

‘Reasoning chain’ showing that a useful business outcome is attributable to controllable factors, and not affected by external factors.

In many cases, a useful business outcome is the last step along the reasoning chain that is reasonably attributable to the project.17

Choosing a point further away from a high-level goal as an outcome increases the risk for the project funder that their goal is not achieved due to some necessary step not being part of the project. Choosing a point beyond the limit of reasonable attribution to the project as an outcome creates a situation where the project sponsor is being held responsible for an outcome beyond their control. In addition, the project funder will be disappointed if external factors result in the outcome not being achieved.

‘Reasoning chain’ and comment on possible business outcomes for a project: 1. awareness created; 2. claims made; 3. new payments system (too narrow); 4. payments made (attributable, valuable); 5. behaviour changed e.g. increase education; 6. social benefits e.g. reduced dependency (too broad)

Continuing the previous example of a program delivery project, choosing the new payments system as the business outcome is overly narrow as it focuses on a project product which provides value only through its usage.

Alternatively, nominating the business outcome as ‘increased economic independence of the target group’ is overly broad. While this social benefit may be the ultimate reason for approving the policy it is likely to be affected by other causes, and it would be unreasonable to hold the project accountable for achieving it. In any event the social benefits arise primarily from the program expenditure and not from the expenditure on the project itself.

A reasonable business outcome for this example is along the lines of ‘Prompt and accurate assessment of claims and payment of entitlements to the eligible target group’.

Project sponsor responsibilities

Given their responsibility for proposed business outcomes, it is better practice for project sponsors to:

  • make themselves available to participate in concept planning discussions;
  • encourage a degree of questioning and innovation in exploring what business outcomes will be most useful for the project concept;
  • understand, and be able to explain to stakeholders, the business outcomes of the project – in particular, this includes being able to distinguish between the accountable business outcomes of the project, and the anticipated consequential effects which are also of interest to stakeholders so as to avoid possible confusion and unrealised expectations; and
  • use their broader knowledge to help align the outcomes to the goals of government and stakeholders, and assist the project team focus the proposal on these issues.

Clarifying business outcomes may seem simple, but can be subtle and time-consuming. However, with a skilled adviser and the right people involved, a useful set of business outcomes can be identified in a reasonably short time.18

17: In some cases, additional elements along the reasoning chain may be identified as required business outcomes for sub-projects of the overall project. These are useful as early indicators of progress.

18: There are many related methods which help explore the underlying reasoning for projects, such as the Outcome Relationship Model of MSP, and the Investment Logic map used in the Victorian Government Investment Management Standard. See Appendix H – Additional sources of information at page 115.