The Money Files

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.

Find out more about NPV in this video.

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.

In this video I look at 5 costs that you might not immediately think of but that could have a drastic impact on the profitability of your project.

I've been thinking a lot about resource management recently, and I put together this infographic-esque breakdown of 5 of the reasons you really need a resource management strategy on your projects. There are more than 5 reasons, but I couldn't fit them on! For another couple, check out this article.

I often hear that it’s too expensive, bothersome or simply pointless to introduce project management into small companies.

Owning a small company myself, I know that is categorically not true. When you have limited time, limited resources and above all limited funding, you absolutely need to be confident that you are investing them in the right initiatives.

OK, I don’t call everything that I do in my company a ‘project’ because it’s just what I do when I turn up to work. But I do have a plan, a task list, goals and – new this year in my growing firm – a colleague who uses the same project management software as I do so that we stay on the same page.

So I was delighted to get a copy of Gren Gale’s Project Management for SME’s.

The premise of the book is good. Gren writes:

To deliver a high-quality product to time and budget requires leadership, skill and – as importantly – demands that your whole business is set up to support delivery.

There is a lot of good common sense advice: the kind that isn’t common everywhere such as why you should let your team set estimates (because if you don’t, they’ll end up not believing the schedule).

The book is organised to take you through the project life cycle. Each phase is a chapter starting with inputs, actions and outputs. Once you’ve got through the life cycle, Gren covers governance and soft skills.

At the end of the book are helpful document layouts and links to free online versions, which makes it easy to put any of this advice into practice and get started quickly – important factors for small businesses making the decision to move to a formal project management approach.

There are recommendations for software that work well for small firms, which might end up dating the book in the future. Overall, it’s angled towards service and client organisations: the kind of small businesses that run as consultancies or agencies and important points related to what it is like to work in those businesses are called out when it’s relevant.

There are some interesting stories shared that really point to the fact that the author knows his stuff. He’s definitely been there and done that and knows what works in real life.

Having said that, the book isn’t without problems. PMP, for example, is not a methodology but it’s referenced as one quite early on. I know that many PMI members and others would probably just use ‘PMP’ as shorthand for ‘the way PMI recommends projects are run using the PMBOK® Guide as a reference’ but it might confuse someone else who is newer to this whole project management thing.

Equally, I missed the references. The CHAOS report is cited but there is no reference to which year. The original report is now extremely old and not something that is worth citing any longer (in my opinion) as a reference to how things are today. But there have been other CHAOS studies. It’s not clear which one Gren is referring to, which is a shame.

It’s a slim book, easy to read, and convincingly makes the case for why project management should be adopted by small and medium-sized businesses. There’s a clear return on investment, and this book will help you make the case to your colleagues.

In his book, Business Leadership for IT Projects, Gary Lloyd goes into Earned Value in some depth – enough for business leaders to understand what it is and how it can be used to provide a reality check on project performance.

He warns against ‘earned value complacency’, which is where the exercise of pulling together the EV statistics and producing the graph lull you into the sense of security that you know all you need to know about the project’s performance and expenditure.

If you’ve used EV, you’ll know that the numbers only tell part of the story, so Lloyd recommends that you use it as a tool to enable further discussion about performance. So much of what EV tells you is down to how it is applied. If you’re a supplier organisation using EV on your client projects, you could be using it in a different way to how the sponsor is used to seeing it.

Not radically different, of course – the formulae are the formulae – but just different in terms of base assumptions or presentation. Even small changes in how the data is calculated or what’s included might change how someone interprets performance.

Lloyd recommends that these are the questions that project leaders should be asking of the people putting together their EV charts for projects, whether they are internal or external. As a supplier project manager, a canny customer could end up putting you on the spot if you don’t understand the exact calculations behind the data. Even if it is produced by your company’s Project Management Office, you still need enough of an understanding to be able to answer questions from your client with credibility and accuracy. It’s reasonable of them to be asking you and a good client should want to challenge and understand the numbers. Besides, that process of challenge is good for everyone so don’t take it as a personal affront. Leaders don’t take numbers at face value; it’s not what makes them good leaders.

9 Questions Project Leaders Should Ask About Earned Value

As a project sponsor, if you’re going to choose something in the EV reports to dig into, try to pick something that you have a reasonably good understanding of where the data points are significantly large so as to help the calculations be transparent. Trying to work out whether a particular task is half a day ahead of schedule or not isn’t going to help you understand the model.

Here are the questions to help you delve into what is really going on.

1. Is the analysis based on the completion of individual deliverables/products or on the estimated proportion completed? If the latter, how is this estimated?
2. Do your calculations include a true estimate to complete the deliverables and products, not simply the actual cost incurred to date taken off the original estimate? [Hmm, I’ve been guilty of this!]
3. How often are you reforecasting?
4. Do reforecasts take into account the actual productivity levels on the project? [I would add: and how are you measuring productivity?]
5. Have any estimates to complete been reduced to mitigate overspend elsewhere?
6. What is the cause of overspend?
7. What is the cause of underspend?
8. Why has more (or less) value been earned than predicted?
9. How is contingency for unplanned work and any change budget shown in these numbers?

Could you answer these questions about your EV reports? If not, who are you going to get to explain them to you so that you can adequately explain them to someone else?