3G A M M A I N S I G H TS

WHOSE PROJECT IS IT ANYWAY?

Seamus O’Sullivan

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

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

hard analysis. The following are common pitfalls found with business cases:

TEAMS LOSE SIGHT OF THE BUSINESS CASE, BECOMING FOCUSED ON THE TECHNICAL SOLUTIONOne 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 ALLThis 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 productsor 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 CASEMany 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

THE BUSINESS CASE TRIES TO BALANCE COSTS WITH REVENUES INSTEAD OF CONTRIBUTION / MARGINThis 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

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

“Project managers need to getunder 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 tovisibly 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 AUTHORSeamus 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

3G A M M A I N S I G H TS

ABOUT 3GAMMA3gamma 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 OFFICE3gamma Sweden ABDrottningtorget 5SE-411 03 GöteborgSwedenPhone: +46 31 309 7910

STOCKHOLM3gamma Sweden ABDrottninggatan 92-94SE-111 36 StockholmSwedenPhone: +46 8 748 0330

DENMARK3gamma ApSFrederiksborggade 15DK-1360 Copenhagen KPhone: +45 53 700 400

MALMÖ3gamma Sweden ABWTC TeknikportalenSkeppsgatan 19SE-211 19 MalmöSwedenPhone : +46 40 627 04 05

UNITED KINGDOM3gamma UK LtdRiver Court,3 The Meadows Business ParkStation Approach, BlackwaterSurrey GU17 9ABLUnited KingdomPhone +44 192 879 6800

UNITED KINGDOM3gamma LtdSuite D, Silk PointHulley Road MacclesfieldCheshire SK10 2LLPhone +44 161 219 8240

FINLAND3gamma OYSentnerikuja 2FI-00440 HelsinkiPhone +358 50 3 748 371