You’ve taken over a new project and you’re reviewing the business case. Or perhaps your sponsor has asked you to pick up a new project and you’re looking over the business case to see what you need to get started with.
In his book, Business Leadership for IT Projects, Gary Lloyd talks about the business case as a management tool. The book is of more value than just for IT projects, and I particularly like the ideas that the author provides when it comes to checking the validity and robustness of your project business case
Here are 16 red flags to look for in a business case. This is Gary’s bullet point list augmented by my take on what they mean for project managers.
1. Is the vision clear?
The vision is what people follow. If you aren’t clear about what the project is about in the business case, the people reading it won’t have a chance. It should be specific about the problem and what desirable end state is the result.
2. Is the scope unambiguous?
There’s always ambiguity at the start of a project, there has to be because you don’t yet know exactly how things are going to pan out.
However, points of ambiguity in a business case should be clearly pointed out, with risk budgets attached and plans about how clarity is going to be reached.
3. Have the key stakeholders been identified and engaged?
You might not want to do too much engagement prior to the business case being approved, but you definitely need people to know what is coming. If you are expecting them to work on the project in some way, they need to know that it is a possibility.
The red flag is when the stakeholder section in the business case looks skimpy. It should hold up to questioning: how much do these people know?
4. How was the cost saving or increased revenue calculated and tested?
The maths should be clear. A number alone isn’t going to give anyone confidence that all the variables have been taken into account. And if you can prove the numbers somehow because of desk-based research or a pilot or something else, then that should definitely be shown.
5. Is the worst case scenario really the worst case?
Is there a worst worse case? This is a good question to challenge a business case of a project that is mandatory or regulatory. Often those projects are started on the premise that ‘worst case’ is not being able to trade again, but that might not really be the situation.
You’ll also want to check what the worst case scenario is based on: if it isn’t to do with stopping trading if the project doesn’t happen, is the worst case to do with project costs, operating costs, missing out on cost savings, revenue or something else?
Dig into the facts and make sure your business case makes this really clear.
6. Does the project cost include contingency?
A no-brainer. If it isn’t there, ask where it is and be prepared to frown if the response is that the business case owner has padded all the estimates.
Contingency should be called out specifically for change budgets and risk budgets.
7. What is the change budget?
On the subject of change budgets, there is one, right?
8. What is the risk budget?
And the same for risk budgets!
9. Does the project cost include all of the non-IT costs?
This is relevant when there is a large IT element, or it’s an “IT project”. Training, temporary office space, staffing costs: they all mount up and might not be covered by the IT budget.
10. Does the NPV include all the operating costs?
See if the business case calculations include licences, infrastructure and staff costs as well.
11. Is the discount rate visible?
And Gary adds: does it reflect the risk of the project? This might be defaulted into the calculations that sit behind the business case but you can at least check that they’ve used the standard calculations and didn’t feel the need to bespoke the maths in anyway.
12. What are the comparators that were used to calculate the discount rate?
Again, this is a good question but might be something set by the Finance team in the spreadsheets used for the business case template.
13. Is the time horizon used for NPV realistic?
A high NPV is better and NPV generally is used to help show which project is more valuable to the organisation. That comparison is really only valid if you are all comparing projects over the same time horizon. Or if you aren’t, that it’s clearly different and realistic.
14. Are the performance criteria realistic?
Check that the performance criteria are something that you can sign up to. Is this what you thought you would be measured on and do you believe you can achieve it?
15. What risks are missing?
There’s nearly always something missing! That happens because you are a fresh pair of eyes and you’ve just combed through the business case looking for mistakes. There might be risks that jump out at you by their absence but you may also want to discuss the project business case with the team and check that the risks they raised made it into the document.
16. What key assumptions are missing?
And the same for assumptions. You may spot some because you are coming to the business case fresh, and ask the team what they had that perhaps didn’t make it to final version.
Payback period is an investment analysis technique and it’s personally one of my favourite tools to use for investment appraisal because in my view it’s the easiest to understand of the tools at my disposal.
Today I’m going to work through an example to show you what it looks like. But before we do that, let’s remind ourselves why we might want to use it at all.
Why Do An Investment Appraisal?
Investment appraisals are what goes into your business case to show why your project is financially viable. They are decision-making tools.
The investment appraisal also allows the decision makers to compare your project with others, which they’ll need to do as all the projects are competing for the same corporate funds. The figures from the investment appraisal, and the associated blurb in the business case, confirm why the project is worth the investment based on forecasted cost and time. It justifies the project based on the expected benefits.
So, investment appraisals matter because they help get your business case approved. Obviously, if the numbers don’t stack up then your project doesn’t get approved. Investment appraisal techniques help you show the cost and benefits of your project in a way that makes it easy to compare with others.
What Is Payback Period?
There’s a little video I made about payback period here, but in essence it’s this:
Payback period is the time taken to recoup the project investment.
Let’s take an example.
A project costs £1,000,000. The benefits are:
As you can see from the graph below, the project investment equals the benefits for the first three years, so the payback period is three years.
In other words, you’ll earn back the amount spent on the project through the project’s benefits once three years have passed. At that point you ‘break even’. Benefits from Year 4 are cash in the bank.
From a business case and project justification point of view, the shorter the payback period, the better.
Problems With Payback
So far, so straightforward.
The problems come when you try to be a bit more sophisticated.
For example, payback period doesn’t take into account discount rates (how much money will be worth in the future: is the £200k benefit in Year 4 really worth the same as £200k would be today?).
As with all investment appraisal techniques you can’t measure intangible benefits in this way. Payback is only good for working out the financial side of benefits: the monetary cost and the financial benefit gained.
That makes payback period a bit crude but as long as everyone is aware of the limitations, it can still be a useful tool to forecast when the project will break even and start to turn a profit.
There are other ways that you can put financial information into your business case: Net Present Value and Discounted Cash Flow are others.
What investment appraisal techniques do you use?
Always a fan of a snazzy graphic, I put this one together to summarise the things that you should be including in your project business cases.
Do you (or your management team) include all of these in your business case template? What else do you think should be in there that I haven't covered below?
This is an extract from the draft of the second edition of Social Media for Project Managers by Elizabeth Harrin and published by PMI. Consider it a sneak preview for when the book comes out!
The normal approach is to define your strategy, research what you need to do in order to achieve that (both in terms of cultural and non-technical changes and software/infrastructure investment) and then prepare a business case to secure the investment. When the business case has been approved you then go into more detail and fully scope the projects or programs required to deliver on that investment.
However, a full financial business case doesn’t always stack up for collaboration tools for many reasons including:
In short, the intangibility and unpredictability of knowledge work makes it hard to quantify anything reliably. Project work by its nature is non-repetitive, and if you have deployed your collaboration tool at the beginning of a project you may not have sufficient experience with that team and on that project to estimate, for example, the length of time tasks are taking with any degree of accuracy. Without that baseline you cannot definitely say that your software has improved the delivery time for tasks. For that reason, many organisations choose not to measure efficiency in a quantitative manner. Instead, companies often rely on employee surveys that in turn rely on subjective responses around whether a tool has made it easier to work together. Make an educated guess based on anecdotal evidence and feedback from the project team.
To give another example, it is difficult to quantitatively measure the positive impact on enabling online communications. How much more useful are project workspaces than a phone call? Bloggers in the public online space often use the amount of comments and social shares received on a blog post as a measure of popularity, interest, engagement with their readers and so on. This is not a reliable measure in a workplace setting: a discussion post may have a couple of comments before you step in and facilitate a face-to-face meeting on the topic, or the commentators pick up the phone to each other to get to the bottom of the finer points. The amount of conversation going on is not necessarily a reflection on the quality of those conversations, so again this is a difficult thing to measure.
The inability to clearly define and measure what you want to achieve will make many project managers uncomfortable (and may force them to choose irrelevant or subjective measures for success). After all, the project charter should include enough detail about scope and acceptance criteria to ensure that the relevant people can sign off the project’s products as complete and fit for purpose. You wouldn’t embark on a project without knowing what ‘finished’ looks like, and knowing who would agree that the work has been completed to the required quality.
However, do you measure how well you wrote the Project Charter or how effective your quality reviews were? Probably not, outside a general feeling that it was a good, comprehensive document or that the meeting participants got what they needed from the review. Collaboration tools are a project support system much like email or conference calls – and would you measure the success of those on a monthly basis? Success criteria are useful, but they do not have to be statistically measurable. Consider the implementation of digital team tools as another option for your project management toolkit. You can measure it with the same judgment calls that you do for the other processes in your methodology.
Don’t struggle with a full financial business case unless you really need one to get your investment approved.
If a full financial business case won’t stack up, or your leadership doesn’t require one, then prepare a short options appraisal instead. Review the solutions available to you, using any identified in your strategy document and any others that have come about as part of your general research into delivering the strategy. An options appraisal includes:
Present this to your decision makers and start the discussion to secure the investment in your collaboration tool.
Alternatively, consider asking for approval at this point only for the analysis phase or a small pilot. This would give you a mandate to go ahead and research the market and how the tools might benefit your teams, while not asking for a financial commitment at this point.
Prioritising projects is pretty easy when you can look at the business case and see which one is going to bring you the most return financially. Whether you’re looking at sales, profit, return on investment or some other cost benefit analysis the great thing about money is that it is tangible and numbers-led. So the comparisons are straightforward. Many execs would opt to work on the projects that bring in the most financial return with the least effort. Simple.
Why projects don’t use financial prioritisation
Organisations don’t use financial methods for prioritising for several reasons, including:
In reality, projects don’t just deliver financial tangible returns. Some projects would struggle to put any money-related measures down on paper. They simply don’t compute that way.
In those situations it is a much harder job to compare projects and choose which ones to work on first. Prioritisation becomes more of a shouting match: the manager who shouts the loudest wins. You also risk priorities changing quickly because someone had lunch with someone else who is influential in deciding these things and suddenly your resources are pulled and given to another team.
Without clear prioritisation, it’s impossible to establish which project is the most important. Let’s look at ways that you can prioritise projects when it’s not about the money.
Other ways of prioritising
By the need to stay in work
The main category of project that I’ve worked on that does not have an easy monetary value is the ones that revolve around staying in business. Examples are:
Projects that allow you to continue to operate should be considered high priority. However, they might not be urgent if you can put the work off a bit. So that’s a YES the project must be done but a NOT NECESSARILY NOW for the work schedule.
By the value added
If you can’t compute value in monetary terms, this categorisation of project becomes quite difficult to measure and therefore compare. Narrative is good: have the discussion and thrash it out but use objective questions to force ‘enthusiastic’ project sponsors to fully justify where the value will be added.
Typically you’ve got two choices:
You can see that there is likely to be some overlap – is a new process adding value to existing team members or creating new value? – but I think you get the picture.
Why not do the easy projects? They can fit in around the larger, more strategic pieces. To be able to prioritise the easy work and slot it in to the programme, you need to know how easy it is going to be. Subjectivity comes into play here as well, as you will have to take a relatively educated guess about what’s achievable for your business.
If you have done something similar before, you have clear goals, the skills are in-house and the risk profile is low, then that sounds straightforward enough for me.
These three prioritisation options gives you different ways to look at the portfolio of projects and align the work with strategic priorities. If it’s easy and adds value, do it. If it’s important to keep the business functioning, do it. If it looks really hard and you won’t get much value from it, ditch it. It’s not rocket science.
As with anything that is not based on numerical, statistical analysis, you have to be careful that people don’t game the system. Ideally you want to create a questionnaire that is completed by an objective party in consultation with the sponsor. Give each criteria a ranking and then calculate the overall total. Then you can put your projects in order and work on them as they reach the top.
Project prioritisation is something that you have to go back to regularly. The order you set for your team today won’t be the same in a few months as business priorities will have shifted. The NOT NECESSARILY NOW projects may be at the top of the list then.
I’d be interested to hear your thoughts when you have no way of using monetary criteria to prioritise projects. How do you do it?