Project and Programme Management #05: Justification

If you have read the previous posts in this project management series, you’ll know that the starting point for a business case is some kind of assessment of the complexity of your project. Not only does this give you an idea of how detailed your business case must be, but it provides some of the information that you can use and expand upon in your business case.

In this article I’ll be looking at the “why” (justification), but before I do there’s one more preparatory activity. That is to determine whether this is a “box ticking” business case or a real one. If it’s the former, it’s pretty likely that the decision has already been made to do the project – and possibly the project will already have started! In the real world this does happen, and although it’s far from ideal, it’s what we have to deal with. In a circumstance like this, a full business case is not necessary and should concentrate on the planning parts and can be fairly light on the why and options parts.

Why are we doing this?

That’s the question you need to answer in the justification section of the business case. It’s the most important part, too. If the reason is not convincing then it shouldn’t matter how quickly and cheaply you can do it, or how low risk it is – it should not be done. Sometimes a good business case presents an argument for why a project should not be done. Never try and mount an argument to carry out a project that can’t be justified.

How do you justify the project?

You can do this top-down or bottom-up. The ideal is top-down because the justification will have been “written” for you. An example of top down is when a new corporate strategy has been written, and it has been determined that certain objectives identified by the strategy can be delivered by a project. You now have a clear linkage: project A will deliver products A1 and A2; these products will support objectives X and Y, and the objectives support delivery of the strategy. However it doesn’t end there. As well as this clear link to objectives and strategy, the justification needs to establish that this is the only (or the best) option for delivering those objectives. This is where the options appraisal comes in. Immediately you come across one of the key things about a business case: the different sections inter-relate so you often have to develop several parts in parallel and go around an iterative loop with them.

The options appraisal is vital because in fact the top-down approach often cuts corners in that a strategic objective will be defined and the solution (what the project is to deliver) is set at that point. Ideally there should be some analysis of the strategic objective before the solution has been defined. So although a top-down approach can be helpful, it also has its pitfalls – one being that it can be hard to persuade senior people to potentially abandon their solution in favour of a different option (or at the very least to set it aside whilst the analysis takes place). This is part of stakeholder management – a topic that I’ll return to at a later date.
Bottom-up is often more common, and is also more problematic. Bottom-up projects are typified by sponsors who want something done in their domain and have not thought about the fit with corporate strategy. The impetus from them will be to retro-fit the project onto the strategy. Just as I noted above that in the real world you often have a “box ticking” business case, so also you often find that you have to try and prove someone’s idea fits strategy rather than the other way around.

Again, you may find resistance to doing a proper options appraisal under these circumstances.

Tools for justification

My second post introduced MoSCoW and ideally you will already have done this with your sponsor, so you should have a pretty clear idea of the priorities and as part of the MoSCoW process you should also have defined some of the key objectives and deliverables.

For establishing a strategic link, there are two approaches depending on the complexity of your project.

Minor projects

For minor projects and some (less complex) medium projects you can use MOST (mission-objectives-strategy-tactics). MOST is a standard business analysis tool, e.g. Paul et al (2010). Mission (or vision) is the high level statement of what is to be achieved. It can be at the level of the whole organisation (“To be the number one seller of ice cream in the UK”) or part of the organisation (“To be recognised as a cost-effective and excellent provider of IT services”). From this, you derive the main objectives (or outcomes) that will deliver the mission (IT equipment recharges are below PC World, New orders satisfied within X days). Then the strategies (not to be confused with corporate strategy) are the ways in which those objectives will be met, with tactics defining the immediate steps to be taken to deliver the strategies.

Using the Windows 7 upgrade example from the previous post, the MOST for this could be something like
M = To be recognised as a cost-effective and excellent provider of IT services
O = To provide modern, fit-for purpose business applications
S = To ensure that business software is upgraded and maintained as appropriate
T = To maintain application platforms within two generations or five years, whichever is the first

So as your organisation is currently on Windows XP and Windows 7 is two generations removed (Windows Vista being the intervening generation), this project fits into that tactic.

Hopefully you will recognise that if you carry out a MOST analysis, especially if it’s top down, you won’t have to repeat it for every project because it will help define a number of projects to be delivered (e.g. the above will also relate to an MS Office upgrade, etc.).

Major projects

For all major projects and some (more complex) medium projects, MOST needs to be expanded into a full benefits analysis using a methodology as such BRM, as defined by Bradley (2010). Bradley defines several stages in BRM, the first two of which are “Set vision and objectives” and “Identify benefits and changes”. These two stages will provide the outputs for a business case justification (and more). It is not my intention to rehearse his method in detail here – better to read his book, but I’ll try and give a flavour.

Strategy Map

During “Set vision and objectives” the aim is to identify the key objectives that contribute to achieving the mission. This is done using a dependencies map, called a strategy map, like the one illustrated here (click the image to see larger version). I’m continuing to use the Windows 7 example, though in practice a Windows 7 project wouldn’t need this full-blown approach (and in practice there would be more supporting objectives identified).

Benefits Map

During “Identify benefits and changes” you take each boundary objective and map out the benefits that will enable the objective to be met. The supporting objectives can help define some of the benefits. (Note that benefits always have to start with words that demonstrate a desired outcome such as increase, reduce, better). The resulting benefits map (click the image to see larger version) clearly shows how the enablers (the things the projects deliver) link to benefits, and the benefits in turn link to objectives. The strategy map then shows how the objectives support the vision or mission. In addition to enablers you can also identify business changes that help delivery the benefits and objectives. Taken together, the enablers and business changes will help deliver the overall objective; one their own they are unlikely to deliver. Thus a benefit of this approach is that it helps you identify the business changes as well as the enablers, an aspect that otherwise often gets missed.

Writing the justification

In carrying out the analysis – whether it’s the simpler MOST or the more complex BRM approach – you will end up with a lot of detailed information. The business case justification needs to draw on this, but you don’t have to put everything in (in fact this can be counter productive as too much low level information can drown the main messages).

If you have used the MOST approach your justification can state the overall mission, describe the one or two main objectives that will help to deliver that and then identify how the project’s outputs will support that. If you’ve used BRM you can follow the same structure, but you only need mention the boundary objectives and end benefits, as well as project deliverables. The strategy and benefits maps can be included as appendices or in the main body as seems most appropriate.

The final section of the justification should allude to the options appraisal but only needs mention the recommended option. The latter will describe the other options considered.

Using a template

If you want to use a business case template, there are plenty out there to choose from. PRINCE2 is probably the best known for use in UK and you can get templates for PRINCE2 from the OGC web site.

---

References

Paul, D., Yeates, D. and Cadle, J. (eds) (2010) Business Analysis, British Computer Society, Swindon (2nd edition)
Bradley, G. (2010) Benefit Realisation Management, Gower, Farnham (2nd edition)