The Purpose-Driven CFO Part 5: Don’t Waste Money Doing Projects

By Andy Burrow

[First published 21st March 2017]

[This article is also on LinkedIn - why not "Follow+" Andy and give the article a "like"?]

How can a purpose-driven approach help Finance managers and CFOs to prevent their businesses from wasting money on projects?

Over the course of this series, I’ve been looking at business Finance activities from what I’ve called a “purpose-driven” perspective. I have set out to investigate whether examining, and being explicit about, the reasons why we do things, actually changes or influences the way we do them. If you haven't seen it already, take a look at the introductory article that explains the thinking behind the approach: The Purpose-Driven CFO Part 1: Introduction. That, fittingly, tells you why I’m asking the ‘why’ questions!

I’ll give you the links to the other articles in the series at the end.

What is a Project For?

A project is, “an individual or collaborative enterprise that is carefully planned to achieve a particular aim.”

However, my question is not what projects are, but why do we do them? What is the purpose of a project in business, generally speaking?

My answer would be that the purpose of projects is to implement changes that improve the performance of the business. 

All Projects Should Be Strategic

Unpacking that further leads back to asking how we would measure improvements in performance. And we’ve seen when I looked at purpose-driven strategy, and again looking at reporting, that we can’t just look at profitability. Once we’ve decided, working from the business mission, vision and goals, what our strategic issues and imperatives are, everything we do must fit with the strategies to address them. So, when we measure the performance of the business, it’s telling us how successful our strategies are in taking us towards multi-faceted goals.

Therefore, if the purpose of projects is to improve the performance of the business, that means they should be strategic. They should be part of the strategic plan for the business.

Now, that doesn’t mean that we can only ever incept projects during the annual strategic planning round. If you’ve read my piece on strategic planning, you’ll know that I think that strategy should be flexible and dynamic. What it means is that every project must be able to demonstrate the extent to which it will contribute to the strategic goals of the business. 

Business Cases are Important

One of the implications of this is that project business cases are important. To people in some companies, this might sound obvious. But I’ve seen so many poor business cases in my time that I believe it’s a pretty important point. I have seen business cases for project investment in excess of £0.5m approved almost ‘on the nod’ on the basis of 3 or 4 PowerPoint slides. And those projects almost always eventually overspent and underdelivered.

And to take the purpose-driven angle, the reason we ask for business cases for projects is to reduce the risk of losing money on them. So, there are three important points:

There must be very clear and detailed guidance (and training) on what is expected in a project business case (and ideally an official template).

Space does not permit me to go into every area that I believe a project business case should cover. But here are a few bullet points to consider:

• Explanation of why the project is required
• What the objectives of the project are
• How the project addresses one or more strategic issue
• Alternatives considered to achieve the objectives
• How the benefits will be achieved (i.e. how do the changes lead to the benefits)
• Financial cost vs benefit analysis
• Key risks
• ‘What if’ analysis – what if upfront costs, ongoing costs and benefits, are more/less than expected?

If there is an agreed template, and approvers don’t allow projects through without correct completion, then people will take it seriously. And they will want some training and guidance on how to go about completing one successfully.

I’m not suggesting the business case templates should include every detail, and be lengthy documents. But there should be enough in the body of the document for reviewers to fully understand why the project is being proposed, what changes are being proposed, what the impact on the business will be, what the costs and benefits will be, and what degree of confidence there is in achieving cost, benefit and time targets. And the executive summary should be enough for the final approver to get a good picture of what they’re approving, and be confident that the reviewers have had enough information to allow it through for approval. That is to say that every section of a business case must be purposeful in demonstrating that the project will, in fact, improve business performance.

There must be independent review of project business case proposals before approval.

The Finance review is probably the most critical, because Finance is the bastion of business performance. But there should also be an IT architecture and infrastructure review if it involves software and/or hardware. And perhaps there should be a HR review if the changes involve redundancies or restructuring.

But the important thing is that the reviewers take their reviews seriously, and do a thorough job. The devil is always in the detail, as I’m always saying. And reviewers need to think thoroughly and laterally around the impact on the business, and whether what the proposer says makes sense. Be very wary where you read, “this aspect has not yet been assessed fully, but is expected to be…”. And, don’t be afraid to ask for evidence, explanation and justification, for statements made.

The project cannot be allowed to start until it has been approved, and reviewers should be empowered to turn down proposals.

In one business where I was responsible for reviewing business cases, I allowed myself to be pushed by the project sponsor to take it forward for approval. I was given an ear bashing, lectured on why the benefits case didn’t stack up, and was told not to waste their time with such flaky business cases in future. I learnt how seriously the senior people in that company took business cases! That’s the way it should be.

In other businesses, I’ve seen business cases go straight from the sponsor to the approver and get signed off with a, “trust me, it’ll be fine”. Those are the ones that trip up. 

If you’re in Finance, with the responsibility to review business cases, do the business a favour. Ask the difficult questions. And make sure that only the worthwhile projects get past your review. I did this in that same business, having learned my lesson. I was presented a business case for a six-figure investment in a new system that would make a business process more automated and straightforward. The trouble was that the cost savings (from not having to employ the temps they had doing the manual work) were not enough to cover the costs of the system. I said ‘no’, and the business case didn’t go for approval. They then discussed alternatives with the IT team, and worked out that they could use Visual Basic macros in Excel to deliver the level of automation they needed for a tenth of the cost.

Equally, senior business management and the CFO should empower business case reviewers to say ‘no’ and support them in toughening up the proposals that come through them. Without that support, if the CFO and others allow the process to be circumvented and pragmatically curtailed, the whole review activity will be undermined.

When Should a Business Case be Required?

In thinking purposefully about projects, and business cases in particular, we do need to recognise that the research and analysis that goes into a good detailed business case represents a cost in itself. So, it is worth considering whether the cost of doing a thorough business case outweighs the benefits. The main benefit in doing a thorough business case centres on the reduction in the risk of losing money through overspending or underachieving benefits. However, the size of that risk will be lower with smaller projects. And therefore, the cost of doing a full business case may not be justified.

Setting appropriate levels in the financial control framework will help to get focus right. Perhaps allow for no review requirement up to a certain level, then a one page business case and a junior review up to another level, and then full business case and full review above another level.

Plan for Benefits Realisation

Another implication of thinking of projects from a “why” perspective is that we should switch our mindset. The purpose of a project is to deliver the benefits (for instance, less people required to do something), not just to deliver a change (a new system, for example). This is a point I made in one of my other articles, where I put it in bold terms: "There’s no such thing as an IT project!”

This will have implications. Firstly, when benefits are asserted in the business case, they should be signed up to formally by the managers responsible for achieving them (normally called “benefit owners”). So, for example, if there will be a reduction in headcount in a certain team, then the manager of that team should commit to make that reduction in the business case (subject to successful delivery of the change). If they won’t sign up to it, it probably won’t happen, so how can the project claim it as a benefit?

Secondly, the project plan should include the “benefits realisation plan”. Practically speaking, the difficulty with this is that project managers are often appointed just to deliver the change. And the benefits normally come later after the change has been delivered. What I’m suggesting could, in fact, lead to project managers staying in place until at least the point where the benefits are clearly going to be achieved.

The other problem is that standard project methodology makes the project manager responsible for project closure. What I’m suggesting is that the project isn’t closed until the benefits are being delivered. The benefits realisation part of the final “lessons learned” report at the end of the project is so significant that I don’t see how you can do the report before you get some idea of the extent of success in realising benefits.

What that means is that either we have to keep project managers in place longer and make them responsible for more, or the benefits realisation phase and project closure should be handed over to the management of someone else in the business. Discuss!

Stage Gate Reviews Should Be Serious

I’ve already gone over my target word count(!), but I’ll finish up with two final thoughts that flow from doing projects in a purpose-driven way.

One is that if we’re serious about only doing projects that improve business performance, then we must accept the possibility that projects could be stopped if they no longer look viable (from either cost, benefit or risk point of view) at a “stage gate” review. This is a similar point to the one above about taking the business case seriously. Every stage gate review must include a serious review and enrichment of the business case. 

Projects Should be Linked to Planning and Reporting Processes

Finally, the link into reporting and planning processes should be strong. Both the costs and benefits of projects should be included in business forecasts. This is another reason for having benefit owners signed up in the business case. And there should be good, regular, project status reporting into business management. The project reporting should not end with the project sponsor or steering group. This is built on the premises that projects must be strategic, and that business management reporting must report on success/progress of strategic plans.

Purpose-Driven Projects Are More Successful

To sum up, knowing why businesses do projects, and being able to articulate and understand the purpose behind each particular project being proposed and undertaken, will help Finance to add value in several ways:

1. by ensuring benefits are explicit, reasonable, achievable and owned;
2. by ensuring that projects are strategically aligned;
3. by ensuring that value destroying projects do not get approved.

Related articles

To save you looking, here are the links to all the articles in this series:

Part 1 - Why be purpose-driven?

Part 2 - Is it time to bin the budget?

Part 3 - Purpose-driven strategy

Part 4 - Financial reporting for what?

Part 5 - Don't waste money on projects

Part 6 - Internal control is for Finance Business Partners too

Part 7 - The great alternative to analysis paralysis

Part 8 - What is a purpose-driven Finance function?

Part 9 - Developing Finance business partnering

Part 10 - Finding purpose in the boring bits of Finance

Other articles

7 Things Finance Can Do to Help Projects Succeed

There's No Such Thing as an IT Project

Free downloadable resource

The Projects Partnering Healthcheck Tool - to identify where can you do more to support projects as a Finance Business Partner