The business case informs decisions
The purpose of the business case is to enable decision makers to deliver well informed decisions in relation to the change initiatives they invest in or do not invest in.
Programmes and projects represent investments in change initiatives or improvement activities. They should always have a justifiable business case that is clearly understood and supported by clearly defined metrics, by which successful delivery can be measured.
For those working with agile methodologies, the business case will support the first two agile principles that emphasis the commercial importance.
1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
A well-formed business case will likely be built up over a few iterations in conjunction with other important management products such as the benefits map, project product description and risk analysis.
The business case should cover at a minimum:
1: The benefits map showing the relationship between the required capability and the realisation of benefits.
2: Short description of the project outputs options that have been considered.
3: Risks to the output and delivering the right capability, then achieving the outcome and realizing the benefits
4: Timescales for achieving the benefits will be usefule in building up the context for the project.
5: Costs for delivering the project output. Often the benefits will be realised after the project is closed. There should also be a budget for the work to be done outside the project
6: Cost benefit analysis
Understand why the project will be initiated
Before you can define a project business case it is aboslutely critical to understand why the project will be initiated. By answering the following questions you will develop an understanding as to why the project and other initiatives are important.
1: What is the opportunity we need to exploit or problem we need to resolve?
2: Which strategic objectives do we have a need to work on in relation to the above question?
If you cannot align the problem or opportunity to one of your organisations strategic objects then it is likely that there is no business case for carrying on.
For businesses the following categories of objectives are likely to be relevant.
Financial: Relating to tangible measures that satisfy stakeholder expectations
Core Service: Relating to increasing efficiency, quality or output
Customers: Relating to ensuring that reputation is managed and demand for services remains strong and predictable.
Organisational capability: Relating to ensuring that the organisation remains relevant and able to meet future needs (e.g. innovation and new service development)
Resources: Relating to ensuring that staff and suppliers are providing the skills and commodities required by the organisation.
3: What are the expected benefit(s) that we need?
A benefit is the measurable improvement resulting from an outcome that is perceived as an advantage by one or more stakeholders and contributes to the strategic objectives of the organisation.
Tip: If you define the benefits that are needed, then it will be easier to identify and define the outcomes that need to be achieved in order for the benefits to be realised. By defining the benefits you will be able to establish a value for each benefit, which in turn will inform the decision on how much can be invested to realise the benefits.
By identifying benefits at the beginning of the project, this will help us to focus on benefits-led change, where what we do is driven by a clear understanding of what we want to realise. This will help to avoid the tendency of identifying what we want and then work out why we want it.
4: What is the expected outcome?
An outcome is the result of the change derived from using capability resulting from having the project outputs.
Example of an outcome: Any change to the way you do your daily work or other activities is an outcome resulting from the new capability that you are able to now use. New software products are an example of new capability, how has your life changed as a result of Twitter, Facebook, iTunes etc.
Tip: If you define the outcome(s) you really want, give examples of how the outcomes are observable, then you can determine metrics that will measure the outcomes that matter.
This and the benefits information will contribute significantly to identifying the capability needed and project output that will deliver the capability. You will also have a basis to estimate how much it is worth investing in delivering the project output.
5: What capability do we need in place, in order to realise the expected outcome?
As you have noticed each of these steps builds on the one before and none of them should be missed.
There are likely to be many products or services that can deliver part or most of the capability you need if you adjust how you work with these products.
If you want a product or service that fits the way you work, then you need to be very clear about the capability that needs to be delivered.
6: What project outputs (products, services or functions) is the most suitable
As mentioned before once you know what capability is needed then you are in a position to define the most suitable output from the project.
Explore alternative options
Developing the business case is an iterative process and at the beginning it is important that alternative options are considered in order to get the best cost-benefit balance. This process will enable the team to identify different combinations of benefits and dis-benefits. While your eventual business case will focus on what appears to be the best choice it is useful to make a not as to why alternative options where not selected. This includes the option of doing nothing.
Assumptions and Constraints
Every project will be based on certain assumptions. Assumptions are a source of risk and should be documented and monitored.
An assumption is statement that is taken as being true for the purposes of planning, but which could change later. An assumption is made where some facts are not yet known or decided, and is usually reserved for matters of such significance that if they change, or turn out not to be true, then there will need to be considerable re-planning.
At the start of the project document a summary of the key risks and the likely impact should they occur. These can later be transferred to the risk registry. It is worth documenting risks to realising benefits even if they are outside the project scope.
The following two risks are very common and I bring them up at the beginning of every project I run.
1: The right people not being allocated to the project, or being allocated to the project and still expected to complete their normal operational duties.
2: The wrong project product or component products are developed due to poor planning processes or short cuts being taken in the planning process. This will result in the wrong product for the business, which is likely to be a threat to the viability of the business.
Evaluation criteria to measure project success from the business perspective
Once you have documented the expected output(s), outcome(s) and benefits. It is useful to know against which criteria the project will be considered a business success. It is possible that this will influence the tolerances set for project variables such as time, cost and scope.
The project success must be related to the benefits the project contributes to the parent organisations success. A project that is delivered on-time and under budget, but does not contribute to the parent organisation achieving its goal is in effect a failure.
I recommend that you measure success of the project by how much it contributes to the Necessary conditions or Critical Success Factors that need to be fulfilled in order for the organisation to achieve its Goal.
Continued business justification
Throughout the projects life we must constantly assess if the planned project output continues to meet the business need. It is quite likely that what was envisaged as being a suitable output at the beginning of the process may change as the market changes or as Users gain a better understanding as to what they require. Changes to scope will likely affect changes to other project variables.