The business case for business cases


By Neil Glover, Commissioning Editor

AXELOS Global Best Practice


Beginning a project without first establishing the business case for that project is worse even than putting the proverbial cart before the horse. In effect, you’re letting the horse bolt and setting fire to the cart.

Defining the business case means being clear about what you want to do, change or create in your business area. However, the desire alone to launch a project is not enough: it needs to be worthwhile and requires the funds available to do it in order to get a business case off the ground. Much of what a business case exists to do is instil a sufficient level of control into a project that will run with it throughout its life and provide the necessary tracking in order to keep the project on course. Without these controls, businesses and organizations could be setting themselves up for failure.

There are a variety of origins for a project’s business case: at the most basic level, the push for a project could come directly from the CEO; having say-so from the C-suite could be viewed as a business case by definition, with an in-built acceptance that it’s legitimate. The inherent risk with this approach comes when the project goes wrong and there is little clarity or substance in the original business case. In other contexts, a project could be proposed as part of a wider programme or to make a marked improvement beyond changes that would come under the heading of “continuous service improvements” – these might well meet the demands of a business case.

Though remaining a “work in progress” today, project management and the design of business cases have come a long way since the days of inadequate business cases and absence of controls and this has proven to be critical to managing successful projects. Why is this? Projects have an innate momentum and become politically difficult to stop unless someone is monitoring the project’s justification all the way along. Halting a project that’s out of control is not failure; it’s considered professional project management if it becomes clear the final outcome is not going to deliver what’s necessary. In the UK, particularly in public sector IT, there have been high profile examples of projects that lacked controls, didn’t deliver what they were expected to and should have been abandoned.

A characteristic that some of these failed projects share is that they’ve been driven by the force of somebody’s personality as opposed to a robust business case and the ability to run projects. A good project manager will have the personal qualities to push through projects – namely self-belief and a total commitment to the work. But there should be no room for ego-driven projects!

This scenario has long been a concern for the project management community: despite the availability of project management tools, the people applying the tools might be guilty of advancing their own agenda. Equally, it’s not uncommon to find people assigned project management responsibility because of their seniority rather than experience. This ignores a fact: professional projects need professional project managers. Equally, projects need board level involvement for overseeing and checking whether a project is on track. The project manager is responsible for reporting progress to the board throughout the project and this should be measured against the original business case. Understanding whether the benefits profile of the project will be delivered can only be judged against the business case – otherwise, what is there to report against?


To read entire article (click here)

About the Author

pmwj25-aug2014-Glover-AUTHORNeil Glover flag-uk

United Kingdom

Neil Glover is the commissioning editor for the AXELOS PPM product portfolio. Having studied mathematics and economics at university his career started as a computer programmer at the UK’s Central Computer and Telecommunications Agency (CCTA) which became part of the Office of Government Commerce (OGC). From there he joined the team that developed best practice guidance including the first versions of PRINCE and ITIL. As CCTA became OGC, his interest broadened to include data, information and knowledge management and, after a brief spell with the Millennium Bug, joined the Cabinet Office project that developed guidance for Centres of Excellence in government. Following early retirement from the civil service Neil joined TSO, the official publisher for OGC, as a commissioning editor and was the P3O chief examiner. After its creation Neil moved across to AXELOS at the start of 2014.

For more information: www.axelos.com

PRINCE2 is a registered trade mark of AXELOS Limited.