Topic 3.8: Business case: valuing other impacts

Likes people like this topic - including you!

SharesThis topic has been shared 25 times!

Progress2,617 people have passed the quiz

(A cynic is) a man who knows the price of everything and the value of nothing

Oscar Wilde, Lady Windemere’s Fan, 1892

It is reasonable to expect the overall impact of a project to be 'worth' the investment costs.

Yet for many projects – especially those in government and the not-for-profit sectors – there are no direct financial returns.

Indeed, not every impact– nor even the vast majority of impacts for some projects – can be priced.

These impacts are the non-monetary (intangible) outcomes delivered by a project, and can include positive or negative changes to:

Knowledge and/or skills (which should lead to improvements in productivity)

The brand (reputation) of our organisation and/or client

Stakeholder networks and relationships

Advantage over competitors

Corporate culture

Community well-being, and

The physical world.

Now it might be possible to say that as a result of this project and the new knowledge it enables we will increase our productivity by five percent.

Nonetheless, it is not always easy (or even desirable) to definitively state that this project will enhance corporate culture by three percent, which will lead to a 0.5% productivity boost and 0.18% return in profit over three years.

A profit-making option may also harm others

That said, it is still vital to quantify these impacts so that we can:

  • Compare them at least indirectly to the costs of investment, and
  • Ultimately evaluate whether our project is a success.

It is equally important to benchmark the impacts of our ‘do nothing’ option as a basis for comparison.

So how can we quantify intangible benefits?

You started to list some of these intangible outcomes in the project concept canvas.

By the time you reach business case development, you should have added significantly to this list.

You can now compare each option (including ‘doing nothing’) by the extent to which it will change an intangible outcome.

It is important that your statements about the impact of each option are substantiated with a detailed argument as to why you think each outcome is likely.

These statements are not only used to justify the organisation’s preference for one option over another; they become a set of expectations (or promises) that stakeholders will expect the project to deliver.

A number of other, commonly used effectiveness metrics include:

Unit counts

For example, the number of people trained or the number of patients treated

Event tallies

For example, the number of safety incidents or the number of errors in production

Avoided cost analysis

For example, reduced travel time or operational savings

Satisfaction ratings

For example, Likert scales, where '5' is very happy and '1' is very sad

Analysis of commentary

For example, the ratio of positive to negative feedback

Unfortunately, whereas many project business cases are quick to state the intended benefits of each option, they quite often fail to describe how these impacts will be measured beyond dollars and cents.

You should finally make an effort to distinguish who benefits from (or is harmed by) each of these impacts.

Stakeholder groups impacted by projects include:

  • The performing organisation (including their staff and owners)
  • The project’s client
  • End users of the project’s outputs, and
  • The general community (non-users).

In this instance, it may also be useful to consider the natural environment as a proxy stakeholder (if you have not already done so).

This is because the environment impact of your project has the potential to excite your stakeholders and impact (for better or worse) your social licence.

By linking impacts to stakeholders you can make more persuasive arguments for each option by directly addressing their specific, motivating needs.

Critically, the business case is the best (and often only) place in the project lifecycle to discuss and define these impacts.

Once project planning starts, the manager’s focus will shift exclusively to output realisation, without any immediate regard for these broader concerns.

The lesson here is twofold:

Firstly, if you don’t define outcomes and benefits at the initiation stage, it is not clear to stakeholders why the project is being undertaken.

Expecting the project manager to do so in planning – that is, once a high-level scope, time frame and budget have been approved – is distracting at best and more often than not invites a significant level of conflict.

Secondly, if you don’t quantify the benefits now, how will you know if your project is a success?

As we said right at the start of this coursea project is only a means to an end.

Delivering on time, on budget and to scope might be great for the project manager’s résumé, but is meaningless if no-one ever uses (or everyone under-uses) the project’s final product, service or result.