Most traditional methodologies hold that a business case is something that a project manager inherits and that its responsibility sits with a sponsor, project executive or even a governance board of some sort. However the project manager can, and should, play a critical role in assessing and critiquing the business case to guard against project failure..

1. 3GAMMA INSIGHTS
WHOSE PROJECT
IS IT ANYWAY?
Seamus O’Sullivan

2. Most traditional methodologies hold that a business case is something that a
project manager inherits and that its responsibility sits with a sponsor, project
executive or even a governance board of some sort. However the project
manager can, and should, play a critical role in assessing and critiquing the
business case to guard against project failure.
April 2015

3. Google the phrase ‘project failure’ and you get over 200 million
results. But when is a project a failure?
• When it’s late?
• When it’s over budget?
• When it should never have been done at all?
The Standish Group, one of whose principal activities is to track
project successes and failures, defines a project as ‘an unqual-
ified success’ if it has delivered its key outputs within 10% of
budget, schedule and quality needs. However, I find this defini-
tion to be somewhat simplistic. Is a project really always a failure
when it is late? Not necessarily, I suggest. Unless it is to build an
Olympic stadium or release a new game in time for Christmas
selling, for many projects the chances are even a modest delay
will not be enough to impact the project benefits significantly.
How about the scenario when a project is over budget? Again,
this may not necessarily constitute a failure.
In reality, if a project’s total life cycle P&L goes into the red
because it went over budget by 20%, the project probably
should not have been done in the first place. There were
probably opportunities that would have offered a better return
for that investment.
Obviously I am not suggesting that delivery to agreed costs and
timescales is unimportant. They are, and should be, key success
factors to be taken into consideration when judging whether a
project is delivering what is expected.
However neither should we delude ourselves that estimating
is an exact science. Even with the best and most honest of
intentions, estimating can often be little better than educated
guesswork.
Projects operate in a very political environment and many
project managers will have been involved in a budgeting game
where a ‘realistic’ estimate is produced, sharp intakes of breath
are taken and instructions are given to sharpen pencils.
Seasoned veterans of projects, having been around the block
a few times, often anticipate this approach and therefore pad
out estimates. This can be explicit, in the form of identified
risks with associated contingency, or more subtle, in the form
of inflated initial estimates. The result is therefore more of a
negotiated budget figure rather than an exact calculation.
However, there is no element of ambiguity with the last
scenario. If the project does not have a sound business
justification, it is a failure from the outset. The important
distinction here is the difference between delivering a product /
service / capability and actually realising the benefits.
In summary, a project can deliver on time and within budget
and still be a complete failure because it added no value to the
business. Equally, a project can be 200% over its original time
and cost estimates and still successfully deliver an outstanding
contribution to the bottom line.
PROJECT FAILURES, INCLUDING
THEIR CAUSES AND HOW TO AVOID
THEM, ARE ONE OF THE MOST
POPULAR TOPICS IN PROJECT
MANAGEMENT LITERATURE AND
DEBATE.
“Estimates are often more negotiated
budget figures than exact calculations”
3

4. hard analysis. The following are common pitfalls found with
business cases:
TEAMS LOSE SIGHT OF THE BUSINESS CASE,
BECOMING FOCUSED ON THE TECHNICAL SOLUTION
One example comes from the McKinsey survey mentioned
below. A bank wanted to create a central data warehouse to
overcome inconsistencies that occurred among its business unit
finance data, centralised finance data and risk data. However,
the project team focused purely on developing the IT architec-
ture solution for the data warehouse instead of addressing the
end goal, which was to handle information inconsistencies. As a
result, the project budget ballooned as the team pursued archi-
tectural perfection, which involved the inclusion of unneeded
data from other systems. This added huge amounts of unneces-
sary complexity.
“86% of organisations reported a
shortfall of at least 25% of targeted
benefits”
With milestones and launch dates constantly being pushed back
and investments totalling almost $10m, the bank stopped the
project after 18 months.
PROJECT TEAMS WANT TO HAVE IT ALL
This is where the enthusiasm of the project sponsor subverts
cold hard analysis. An example I have experienced is a require-
ments document with a MoSCoW analysis of 330 ‘musts’ and 40
‘shoulds’. I am not an advocate of the MoSCoW approach. I have
seen too many examples of it being misapplied in this manner. I
much prefer a forced ranking and agile approach. This encourag-
es a depth of thinking as the business is forced to prioritise what
it wants.
For me this quote captures the essence of well-intentioned
but inadequate project management. It was said over 50 years
ago, yet its cautionary tale is as common and as relevant today.
Drucker was talking about business in general, but really it is
about projects, because projects are the vehicle for any change
to a business, its products or its services.
“Projects are the vehicle for any
change to a business, its products
or services”
The key element in this quote is the “with great efficiency”
line. This is the traditional focus of project management; doing
things with great efficiency, with tools for issue management,
stakeholder management, risk management and communication
management. A place for everything and everything in its place;
deck chairs on the Titanic if the project is not going to add value
to the business.
Logica Management Consultancy conducted a survey of 380
senior executives in Western Europe in 2008 and concluded
that 37% of business process change projects failed to deliver
benefits. KPMG conducted a larger survey in 2005, covering 600
organisations globally. In this, only 2% of organisations reported
that all of their projects achieved the desired benefits, and 86%
of organisations reported a shortfall of at least 25% of targeted
benefits across their portfolio of projects. These are not margin-
al numbers. They are huge. Scour the internet, or any books on
project management, and you will see hundreds more examples.
THE BUSINESS CASE
Many years reviewing hundreds of business cases has
reinforced my experience that business case justifications
can be very subjective; strong on rhetoric but weak on cold,
“THERE IS SURELY NOTHING QUITE SO
USELESS AS DOING WITH GREAT EFFICIENCY
WHAT SHOULD NOT BE DONE AT ALL.”
PETER DRUCKER 1973
4

5. THE BUSINESS CASE TRIES TO BALANCE COSTS WITH
REVENUES INSTEAD OF CONTRIBUTION / MARGIN
This is the ‘apples to apples’ comparison. Take a £1m project
that is justified by an uplift in revenue of £2m over three years.
Sounds good at face value. But what is the margin? If the margin
is only 40% the project is actually going to make a loss over three
years.
The point I make is that, during the project, the vast bulk of
effort goes into the when, who and how much. With a good
team and a strong product manager you might get a decent
focus on the ‘what’ as well; continual review of the require-
ments, grooming of backlogs etc. Almost invariably the most
important question, the ‘why’, is neglected.
SO WHAT DO GOOD PROJECTS DO?
A McKinsey survey published in October 2012 concluded that
top-performing projects:
• Establish a clear view of the initiative’s strategic value
• Build a robust business case
• Maintain focus on business objectives along the whole
project timeline
There are two key elements worth stressing in this approach.
The first is a ‘clear view’ of value. This is not a tenuous link or
a long fuzzy chain of causal connections. The team and stake-
holders can see and understand how their outputs directly
contribute to the value of the business.
The second key phrase is ‘along the whole project timeline’. This
is not a one-time activity conducted at a point in history and
then put in a drawer to gather dust. It is constantly reviewed
throughout the project because there is a clear understanding
that things can, and frequently do, change: markets, competi-
tors, technology and opportunities.
Assuming we agree that the business case is a critical element
in the success or failure of a project… whose responsibility is it?
Most methodologies concur that this responsibility rests with
some representative of the business.
• Prince – the sponsor owns the business case
• SCRUM – the Product Owner is responsible for the
profitability of the product
• MSP – the SRO owns the business case, supported by the
sponsoring group
While ultimately this is true, there is a real concern here. It is
difficult to get a project off the ground. To get a proposal onto a
project candidate list, and secure initial funding, someone has
usually had to put some significant political capital into it. Quite
often that someone is the sponsor.
It is very difficult for a poacher to turn gamekeeper. Any sponsor
will be susceptible to the forms of cognitive bias, such as confir-
mation, availability and optimism, that inhibit them from being
truly independent and objective. Try asking a sales or marketing
person to volunteer that the brilliant plan they had is no longer
valid because circumstances have changed. It takes a special
(and rare) kind of person to have the confidence, discipline and
self-awareness to do this.
A colleague at 3gamma has produced another white paper
tackling this particular point. Entitled “Only in Fairy Tales Are
Emperors Told They Are Naked”, it can be found on the 3gamma
website. In it he puts forward the proposal for a governance
board across all projects. The key characteristics of this govern-
ance board are summarised as follows:
• Keep it small
• Keep it senior
• No project stakeholders
This group has the authority to cancel any project in the port-
folio if members are not convinced of its value to the business.
This is an excellent approach, but it rarely happens.
ENTER THE PROJECT MANAGER
Once they have taken on a project, the project manager’s
perceived performance is inexorably tied to the fortunes of that
project.
Whilst it may seem unfair to hold the project manager account-
able for everything, if the right checks and balances were not
in place to guard against issues, if the right risk assessment was
not done, if the right people were not on the project or not
given the right support, then most people would agree that
the project manager has to take a measure of responsibility
and accountability. Why then, should the business case be any
different?
There are good reasons why a project manager is in an ideal
position to challenge a business case. Firstly there is the purely
rational argument. The project manager is unlikely to have been
involved in the initial justification. As such they are less likely to
be susceptible to those cognitive biases that may influence the
sponsor’s view. In addition project managers generally have the
following attributes:
• Logical and analytical
• Skilled at asking the questions without detailed knowledge
• Responsible for, and trained in risk management
The last point is particularly important. What we are dealing
with here is a risk, and it can be restated as such in the normal
language of risk: because the sponsor has a vested interest
5

6. in the outcome of the project, there is a risk they may be
succumbing to optimism bias, as a result of which the business
case may be overstated and the project might not be worth
doing.
However, there are also strong emotional arguments for the
project manager to take a measure of responsibility. The first is
a positive one; motivation. The essence of motivation is to feel
a part of something worthwhile. People want to understand
the bigger picture and understand how the work they are doing
contributes to that. This is particularly true of someone who is
investing as much time and energy as the project manager. The
second reason is slightly more negative but no less important.
As alluded to above, if a project does fail, for whatever reason,
the project manager is frequently the fall guy. It is therefore in
their best interest to raise and highlight any concern before it
becomes viewed as a failing on their part.
SO HOW EXACTLY DOES A PROJECT
MANAGER ASSESS OR CHALLENGE A
POOR BUSINESS CASE?
He or she could make an offensive frontal assault, deriding
the document as a work of fiction that was clearly dreamt up.
Whilst some people do admire honesty and openness, such an
approach is unlikely to result in a long and prosperous career.
A more sound approach is to seek to understand the business
justifications, softly but firmly, and with questions and concerns,
not accusations. It is not a case of carrying out sophisticated
analysis, discounted cash flow assessments, complex scenario
testing or exhaustive market research. It is more akin to asking
three simple questions about the business case:
1. Do you get it?
2. Do you believe it?
3. Would you invest money in it?
Do you get it? By which I mean, do you understand the logic
behind the justification and can you follow a path from this
logic to the numbers used to justify the outcomes? Secondly,
do you believe it? Just because you follow the logic, it does not
mean you agree with it. You may also be sceptical about the
conclusions or numbers drawn from the logic. See the sidebar
for a generic example. Also, do we have evidence for it? Lastly,
would you invest your own money in it? If not, why do you feel
comfortable investing the company’s money in it?
Note: The project manager is not carrying out any analysis here.
She is just asking probing questions and looking (hopefully) for
robust answers and to see the ‘homework’.
I always pushed my project managers to get under the skin of
a business case. They need to be able to repeat it succinctly;
the elevator pitch. If the project manager cannot explain the
business justification in simple terms to the CEO, it not only
undermines the project, it calls into question the project
manager as well, regardless of what it actually says on their job
description.
A product would offer a new unique selling point
(USP) over the existing top three products currently in
the market. This would allow us to grow our market
share to 35% and price the product at a margin of 50%
making a contribution of £500k to the bottom line
P&L over the next three years.
In this example you may accept the first point and also
accept how this would enable an increase in market
share and justify the margin. You follow the logic.
However you should still have questions:
• What is our current market share? There is a big
difference in getting from 30% to 35%, than 3% to
35%
• How is the market split across other products at
the moment and where is our percentage increase
going to come from? Which competitors are we
going to take it from?
• How are they likely to respond? Can they easily
replicate our USP?
• Could they undercut us on price? If so what would
that do to our margin?
• Can we really sustain that margin for the three
years quoted, or does it realistically drop in year
two and maybe more in year three?
• What analysis has been done to test the price
point with customers?
AN EXAMPLE
6

7. “Project managers need to get
under the skin of a business case”
However, this is not just a question of impressing senior
management. The project manager should be able to explain
the justification to the team as well. They want to be motivated
too. They need to feel they are part of something that adds
value to the business. If the answers to the probing questions
are not positive then the project manager could discuss with the
sponsor if ‘we’ should review the business case risk, tackling the
concern together. And, as with any risk, if the project manager
believes the response to be inadequate, then they should
escalate; again softly but firmly, and to their own manager, not
to the sponsor’s manager. This is the core skill of stakeholder
management and influencing. Rarely is it wise to
visibly go over your sponsor’s head.
Finally we have perhaps the most powerful question: “Under
what circumstances would this business case no longer be
compelling?” The effectiveness of this question is that it is not
directly challenging the previous work done, yet it requires
a considered response, and cannot be dismissed with just a
restatement of the same justification.
“Under what circumstances would
this business case no longer be
compelling?”
ABOUT THE AUTHOR
Seamus O’Sullivan is a leading programme manager delivering
major change projects for clients of 3gamma UK. An engineer
by training, Seamus is a Prince, SCRUM, MSP, MoP and MBA
qualified Project / Programme Manager with over 18 years’
experience.
If you have any questions or comments about this white paper,
please contact us today or visit our website www.3gamma.com
The business case can often be the single biggest risk on a project. It is too
important simply to trust it to the sponsor or project executive. The project manager
needs to understand, believe in and be able to defend the business case. If they can’t
then they need to escalate the risk. If they do escalate, they need to do so in a sensi-
tive manner.
CONCLUSION
7

8. 3GAMMA INSIGHTS
ABOUT 3GAMMA
3gamma is a leading professional services firm focusing on IT management. As an independent specialist in IT
management, 3gamma provides advisory, consulting services and fact-based insights to many of the world’s most
respected companies. 3gamma operates globally from offices across the Nordics and UK. 3gamma is a knowledge
firm that bases its expertise of six core capabilities:
• IT strategy and governance
• IT sourcing lifecycle
• IT legal advisory
• IT risk and assurance
• IT operational excellence
• IT project management and delivery
3gamma has, in a series of whitepapers, explored how companies employ agile methodologies and innovative
approaches to IT sourcing to become more aligned with the businesses’ needs and requirements.
GROUP HEAD OFFICE
3gamma Sweden AB
Drottningtorget 5
SE-411 03 Göteborg
Sweden
Phone: +46 31 309 7910
STOCKHOLM
3gamma Sweden AB
Drottninggatan 92-94
SE-111 36 Stockholm
Sweden
Phone: +46 8 748 0330
DENMARK
3gamma ApS
Frederiksborggade 15
DK-1360 Copenhagen K
Phone: +45 53 700 400
MALMÖ
3gamma Sweden AB
WTC Teknikportalen
Skeppsgatan 19
SE-211 19 Malmö
Sweden
Phone : +46 40 627 04 05
UNITED KINGDOM
3gamma UK Ltd
River Court,
3 The Meadows Business Park
Station Approach, Blackwater
Surrey GU17 9ABL
United Kingdom
Phone +44 192 879 6800
UNITED KINGDOM
3gamma Ltd
Suite D, Silk Point
Hulley Road Macclesfield
Cheshire SK10 2LL
Phone +44 161 219 8240
FINLAND
3gamma OY
Sentnerikuja 2
FI-00440 Helsinki
Phone +358 50 3 748 371