Defining intangibles

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

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

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 or skills (which should lead to improvements in productivity)
• The brand (reputation) of our organization 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, leading to a 0.5% productivity boost and a 0.18% return in profit over three years.

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? 

---

Non-financial metrics

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 how much it will change an intangible outcome.

It is vital 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 organization’s preference for one option over another; they become a set of expectations (or promises) that stakeholders will expect the project to deliver.

Several 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 each option’s intended benefits, they often fail to describe how these impacts will be measured beyond dollars and cents.

---

Who is impacted?

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 organization (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 environmental impact of your project has the potential to excite your stakeholders and impact (for better or worse) your social license.

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 realization 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 course, a 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.