Mandatory projects are annoyingly common in organisations. They include projects to meet an external compliance requirement – a change in government legislative policy for example. They also include risk avoidance projects. These are less obviously ‘mandatory’ as ultimately, they arise dependent on a management decision about what risks are bearable. Common examples are updates to software or technology to keep in line with new versions.
I was listening recently to a CIO tell her team that no business case was required for a major infrastructure project because “It was mandatory”. Are you reacting with the same horror and disbelief to this as I did? This is either ignorance about the purpose of a business case or a standard power play being made by a technical department that believes they should lead the business – that they know best!
OK, then, what is the purpose of a business case? And, more specifically, what is its purpose when it is written for a mandatory project?
The purpose of the business case
Let’s consider both the process of creating the business case as well as the output. Business case development is the perfect platform for building a coalition of support from key stakeholders. It is during this process that stakeholders’ values and agendas are surfaced, explored, challenged, and common ground found. Without this activity, the business case document is truly not worth the paper it is written on.
The output, the business case as a document must face two tests from two different governance groups. The first scrutiny must determine whether the project is ‘worthy’. Does it return sufficient value to its stakeholders to make it worth investing in? This is generally an easy assessment to make. If the stakeholders want it; if they value what it will cause in terms of altered capability – it’s worthy.
The second assessment is much harder and is the reason why benefits as a concept prove so difficult to get agreement on. The other purpose of the business case is to allow comparisons to be made between projects; to assess which has greater worth – which is the better project amongst the plethora of competing projects?
Consider the case that you can only invest in the performance improvement of just one athlete. Should it be the world-class swimmer, Sally, or the Olympic runner, John? You can’t get them both to run or to swim and the winner takes it all. You are going to have to find a metric that captures something in common between the two – a measure that allows you to make comparative judgments of value between the two competing contenders.
For projects, it’s just the same. One project offers a reduction of process time by 30% for a business process. Another provides an opportunity to gain revenue from marketing a new product. To make a choice, it is no longer reasonable to list what the stakeholders see as good – the changes in operational performance and new markets – now the comparative values probably will get to be described in terms of risk-adjusted financials.
A benefit lexicon is established by an organisation for exactly this purpose. But what exactly do you use when the process improvement project is competing against one designed to rebrand the organisation? You can pretend you can determine the projects’ financial values – but it’s a scam – and you know it. So, perhaps a deeper abstraction into strategic alignment, or competitive advantage? Who is the better athlete, or the better bet, Sally, or John? Why exactly are you investing in them anyway?
What about mandatory projects?
Now take the situation that one of the projects is mandatory. The need for a business case appears to have fallen away. If it’s mandatory there is no choice. It must be done, so worthiness and competition are no longer factors. Right?
This is the well-worn argument of those who see that being mandatory is an open sesame to running a project without the ‘inconvenience’ of governance. And they are so wrong! Even for mandatory projects, it is just as important to build a coalition of support. It turns out, one person’s understanding of which solution meets the mandatory condition is not commonly shared by all! And here lies the rub, and this is why a business case is essential for every mandatory project. If a project is being run because of compliance or risk avoidance, there are no benefits. It is being run because the risks associated with not doing so are unacceptable.
As there are no benefits, the organisation is no better off after the project than it was before. This means that the criteria for the best solution for a mandatory project, the best project, is the one that delivers a solution at minimum cost. Surprised? Surely not!
However, if a project is going to use the impetus and energy that being mandatory injects to improve performance or capability, if it is going to deliver benefits as well as avoid the risk or deliver compliance, the original purposes of a business case are reinstated.
The trouble with mandatory projects
The fundamental threat posed by mandatory projects to organisations is that they create opportunities for projects to deliver improved outcomes, such as being better, simpler, or faster, “while they are at it.” In other words, since there is no oversight or governance, projects may take it upon themselves to make improvements and deliver benefits without approval from stakeholders. These additional “and-while-you-are-doing-this” improvements lead to increased costs and out-of-control projects.
To steer clear of these issues, declaring a project as mandatory necessitates a strong business case, showcasing its cost-appropriateness. Moreover, if there’s a chance to boost capabilities amidst organizational changes, the business case must justify the extra costs as a worthy investment, yielding returns that outweigh the additional expenditure.