“This is what the Minister wants – that’s the business case”. I wish I had a dollar for every time a senior public servant has said that to me. It is almost invariably provided as the explanation as to why the project they are directing doesn’t have a business case. It is also almost invariably the reason that the project is failing to deliver and the source of increasing executive angst and tensions.

Let’s have a quick look at what is wrong with this thinking – and yes Agile fans, this applies to your projects as well.

“The Minister wants it”

That’s the other way the explanation for a lack of a business case gets expressed: “The Minister wants it.” The problem here is what is meant by “it”. Everything pivots on that. I am constantly amazed by how people are willing to invest hundreds of days of staff effort, and millions of dollars, often tens of millions of dollars, based on little more than a general understanding that the Minister wants something.

You wouldn’t buy a car like that, you wouldn’t buy a house like that, you pretty much wouldn’t buy anything like that. You need some basic information which, with apologies to the Department of Veterans’ Affairs, confirms whether the project is DVA:

  • desirable: the balance of costs, benefits and risks
  • viable: able to deliver the products
  • achievable: whether use of the products is likely to result in envisaged outcomes and resulting benefits.

“I don’t want to spend months creating a lengthy cost-benefit analysis”

This is also commonly offered as an adjunct: “The Minister wants it, so I don’t want to spend months creating a lengthy cost-benefit analysis”. No-one asked you to do so. This is where I get frustrated with a lack of understanding as to what a business case should or shouldn’t contain.

Benefits do not have to be financial. For public service projects they often aren’t. If they aren’t, don’t pretend they are and try to “convert” things into dollar values. It is artificial, and everyone knows it is.

So what should be in a business case? A project should:

  • create and maintain a (documented)business justification for the project;
  • review and update the business justification in response to decisions and events that might impact desirability, viability or achievability of the project;
  • define the management actions that will be put in place to ensure that the project’s outcomes are achieved and confirm that the project’s benefits are realized; and
  • define and document the roles and responsibilities for the business case and benefits management.

And that’s all you need as a minimum. But don’t take my word for it. These words are taken from the 2017 edition of the PRINCE2® Manual. So don’t let your corporate PMO give you a twenty-page template and tell you that’s PRINCE2, because it isn’t.

Want to know more about what using PRINCE2 really means?

If you would like to know more, please call me personally on 0407 404 688 or email me at john.howarth@tannerjames.com.au. I would be very happy to come to meet you, answer questions and provide further information.

What do you think?

Please feel free to comment on the blog itself or via LinkedIn.