Mandatory projects: What’s the benefit?!

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.

Fostering a culture of responsible oversight and vigilant governance is crucial to mitigate the substantive cost risks posed by mandatory projects.  Furthermore, any potential improvements must be assessed and justified through a rigorous business case.

Stakeholder-led business case development

Over the last few years, I keep thinking that the penny has finally dropped – it’s the stakeholders that count!  People in projects talk about stakeholders, even the project management associations talk about stakeholders, yet when you listen carefully, you start to wonder.  Are the ‘why’ and ‘how’ of stakeholder engagement really understood? 

One area you’d think was undeniably a stakeholder intensive process is the development of the business case.  Surely this is critical to the stakeholders and the investors in the project?   But no! Today, business cases are often written by specialists in writing business cases, or worse, the project manager, and often in parallel or even after the project has started.

One relatively recent improvement is that you find a whole section entitled ‘Stakeholders’ in a good business case.  Yes, it has an entire section!  But often, the content and purpose are problematic.  It should neither be a list nor where stakeholder analysis is written up.   What it should do is provide evidence in support of the three functions of any business case.

What are these three?

Addressing “Why now?” in the business case

We tried that before!

There are so many good ideas in every organisation!  Most you never get to hear about.  Inertia, change weariness, and poor politics account for much of this waste.  But there is another killer weapon: “We’ve tried that already!  It doesn’t work!”

You’ve used, I’ve used it—such a showstopper.  In one go, you’ve asserted your prescience, your historical rectitude, and just a smidgeon of arrogance.  Not bad for seven words!

The CEO of the company I worked for had a rule: Every recruit for the first 100 days was required to ask questions and suggest ideas.  During these first 100 days, new staff have new and excitingly different perspectives.  Of course, they and you want them to integrate with the company, but this is when they also want to be seen to make a difference.  Over time they become more and more part of the company, absorbing its culture and history.  They adopt the company’s stories and beliefs.  Once fully integrated, they become part of the narrative, and this window of opportunity is lost.

Of course, they do ask annoying questions like, “Why on earth do you do it that way?”; “Why haven’t you done it this way?”, “Have you tried doing this?” But the crucial part of the CEO’s rule was; “Every question and every idea had to be listened to and considered fully by everyone in the company”.  The one response that was forbidden was, “Nah, we tried that before!”.  Nothing kills creativity and innovation than that particular wet blanket, especially when it’s delivered, as it so often is, with a sigh and a pitiful look as if to say, “You don’t think we didn’t think of that!”

But the truth is that just because it didn’t work last time does not necessarily mean it’s not right now.

Benefits come first

You’ve done it! I’ve done it!  It seems so natural.  You start the story at the beginning, and you then follow the narrative until you come to an end – and you find out who did it and why.

That’s fine for a novel, even if it is a little traditional for some modern authors, but it’s a terrible way to write a business case.  Choose a template for a business case, and there it is:

• Statement of the problem
• Analysis
• Discussion of possible options
• Recommendation
• Details of your chosen option

It’s a novel!  And you are the detective, trying to find out what crime has been committed.  Wrong, wrong, wrong, wrong!