Principle: Quantify Objectives

by Tom Gilb & Kai Gilb

"All critical
outcome value objectives
can be quantified and must be."

There are two initial steps to quantification of outcome objectives, ‘Scale + Levels.’

First the ‘Quantification Scale’ needs to be defined.

Then interesting levels (like Past, Status, Goal, Tolerable) on
that ‘Quantified Scale,’ need to be specified.

Quantification of Objectives.

The fact that we can use words, like ‘enhanced,’ ‘improved,’ ‘better,’ to describe our objectives, is evidence that these objectives are variable in nature, and that they can, therefore, be represented using numbers.

Most managers need little instruction in quantifying ‘financial’ and ‘capacities’ values. But they usually need considerable help in specifying product values (qualities) like user-friendliness and portability and the softer stakeholder values.

Values describe ‘how well’ a system (organization, process, project, product, service) performs.

We have found no exceptions to the principle that; ‘All critical
outcome value objectives can be quantified.

Commonly stated ‘word-only’ objectives, like ‘world-class quality,’ or ‘enhanced responsiveness to market dynamics’ will be unclear, probably even to the originator. ‘Unclear’ means that even they will struggle to make an acceptable, useful, and clear-to-others interpretation if you ask ‘what does that mean?’

But, worse, there will be quite different interpretations, for every different person, who reads or hears these ‘word-only’ objectives.

The ‘Ambiguity Test.’

You only have to ask people to write out their personal (mis-) understanding of such vague phrases, to see this inevitable confusion. We call this process the ‘Ambiguity Test.’ And it is fun to do it in a serious meeting. People are usually 'blown away’ at the lack of common understanding of critical objectives.

The 20-30 minutes used to make the ‘lack of common understanding,’ of critical objectives, clear to all, in a meeting is an excellent use of time. Because it might lead to a superior and powerful common understanding of your objectives. And might save your project from failure and years of wasted time and money.

A Process

You might not initially arrive at the, with hindsight, 'right' objective: this might take time and feedback. But by getting a truly common-to-participants, and well-understood objective in the planning, you can more easily learn how well that specification works early, and modify it, as needed, later.

‘Ambition Level’ Phrases are not enough.

‘Word-Only Objectives,’ like ‘vastly superior market recognition,’ are a waste of time, except as a starting point for better definition, or as an accessible summary.

We often use these vague phrases as a ‘background component’ of an objective specification, called an 'Ambition Level' statement. We might even quote the top manager source of the Ambition statement. But we don’t ever stop at such a ‘rough’ level of specification. The objective specification is always subject to further quantified definition (using Scale etc.). We suggest using this as an unbendable standard, a Rule, for how you specify objectives.

Your top-level critical objectives deserve that small additional effort. And the clarification effort should have a huge payback.

The problem is that so much current planning practice stops, before the necessary clarification of objectives. Planning ends at this ‘Ambition Level’ containing 'nice sounding words' only.

The conventional planning process usually never clarifies the objective, or even gets the right level of an objective. That is what we see in practice.

The nice-words-only objective, for example, is very likely to be only a presumed ‘means' to your true ends. You might get what you ask for (a ‘means’), not what you want and need (true ‘ends’).

Example

Below you will find a real case where they quantified all critical outcome values on a single page. This example is from a multi-million dollar project, a doctored copy of an early version.

Real Bank Project: Project Progress Testability

P&L-Consistency&T P&L: Scale: total adjustments btw Flash/Predict and Actual (T+1) signed off P&L. per day.

Past 60 Goal: 15

 

Speed-To-Deliver: Scale: average Calendar days needed from New Idea Approved until Idea Operational, for given Tasks, on given Markets.

Past [20xx, Market = EURex, Task =Bond Execution] 2-3  months

Goal [Deadline =End 20xz, Market = EURex, Task =Bond Execution] 5 days

 

Operational-Control: Scale: % of trades per day, where the calculated economic difference between OUR CO and Marketplace/Clients, is less than “1 Yen”(or equivalent).

Past [April 20xx] 10%  change this to 90% NH

Goal [Dec. 20xy] 100%

 

Operational-Control.Consistent: Scale: % of defined [Trades] failing full STP across the transaction cycle. Past [April 20xx, Trades=Voice Trades] 95%

Past [April 20xx, Trades=eTrades] 93%

Goal [April 20xz, Trades=Voice Trades] <95 ± 2%> 

Goal [April 20xz, Trades=eTrades] 98.5 ± 0.5 % 

 

Operational-Control.Timely.End&OvernightP&L Scale: number of times, per quarter, the P&L information is not delivered timely to the defined [Bach-Run].

Past [April 20xx, Batch-Run=Overnight] 1

Goal [Dec. 20xy, Batch-Run=Overnight] <0.5>

Past [April 20xx, Batch-Run= T+1] 1

Goal [Dec. 20xy, Batch-Run=End-Of-Day, Delay<1hour] 1

 

Operational-Control.Timely.IntradayP&L

Scale: number of times per day the intraday P&L process is delayed more than 0.5 sec.

 

Operational-Control.Timely.Trade-Bookings Scale: number of trades per day that are not booked on trade date.

Past [April 20xx] 20 ?

 

Front-Office-Trade-Management-Efficiency Scale: Time from Ticket Launch to trade updating real-time risk view

Past [20xx, Function = Risk Mgt, Region = Global] ~ 80s +/- 45s ??

Goal [End 20xz, Function = Risk Mgt, Region = Global] ~ 50% better?

Managing Risk – Accurate – Consolidated – Real Time

 

Risk.Cross-Product Scale: % of financial products that risk metrics can be displayed in a single position blotter in a way appropriate for the trader (i.e. – around a benchmark vs. across the curve).

Past [April 20xx] 0% 95%.           Goal [Dec. 20xy] 100%

 

Risk.Low-latency Scale: number of times per day the intraday risk metrics is delayed by more than 0.5 sec.

Past [April 20xx, NA] 1%  Past [April 20xx, AP] 100%

Goal [Dec. 20xy] 0%

 

Risk.Accuracy

Risk. user-configurable Scale: ??? pretty binary – feature is there or not – how do we represent?

Past [April 20xx] 1% Goal [Dec. 20xy] 0%

 

Cost-Per-Trade

Scale: % reduction in Cost-Per-Trade

Goal (EOY 20xy, cost type = I 1 – REGION = ALL) 60%

Goal (EOY 20xy, cost type = I 2 – REGION = ALL) x %

Goal (EOY 20xy, cost type = E1 – REGION = ALL) x %

Goal (EOY 20xy, cost type = E 2 – REGION = ALL) 100%

Goal (EOY 20xy, cost type = E 3 – REGION = ALL) x %

Do you have examples of how your project quantified the critical outcome values?

How do you think projects should be orchestrated to succeed? 
With quantified outcome values or with some other information?
Let us know in the comments section below.

Check out our Online Course for Quantifying Outcome Values and more

And if you found this article useful, please share it with your professional friends.