Business Case
Abstract
The business case is a document which sets out the perceived benefits, requirements, and constraints of a project. It outlines the justification for the project, and while the document itself is the responsibility of the sponsor, the compilation is often a combined effort of the sponsor and the project manager designate. The business case sets out the basic why, the what, the when, and the how much, although these may be more fully explained in the project management plan.
Keywords
Business case; sponsor; requirements; constraints
Chapter Outline
Before embarking on a project, it is clearly necessary to show that there will be a benefit either in terms of money or service or both. The document that sets out the main advantages and parameters of the project is called the business case and is (or should be) produced by either the client or the sponsor of the project who in effect becomes the owner of the document.
A business case in effect outlines the ‘why’ and ‘what’ of the project as well as making the financial case by including the investment appraisal.
As with all documents, a clear procedure for developing the business case is highly desirable, and the following headings give some indication of the subjects to be included:
1. Why is the project required?
2. What are we trying to achieve?
4. What is the anticipated cost?
5. How long will it take to complete?
6. What quality standards must be achieved?
7. What are the performance criteria?
8. What are key performance indicators (KPI)?
In addition any known information such as location, key personnel, resource requirements, etc., should be included so that the recipients, usually a board of directors, are in a position to accept or reject the case for carrying out the project.
The Project Sponsor
It is clear that the business case has to be prepared before the project can be started. Indeed, the business case is the first document to be submitted to the directorate of an organization to enable this body to discuss the purpose and virtues of the project before making any financial commitments. It follows therefore that the person responsible for producing the business case cannot normally be the project manager but must be someone who has a direct interest in the project going ahead. This person, who is often a director of the client’s organization with a special brief to oversee the project, is the project sponsor (sometimes also known as the project champion).
The role of the project sponsor is far greater than being the initiator or champion of the project. Even after the project has started the sponsor’s role is to:
1. Monitor the performance of the project manager
2. Constantly ensure that the project’s objectives and main criteria are met
3. Ensure that the project is run effectively as well as efficiently
4. Assess the need and viability of variations and agree to their implementation
5. Assist in smoothing out difficulties with other stakeholders
6. Support the project by ensuring sufficient resources (especially financial) are available
7. Act as business leader and top-level advocate to the company board
8. Ensure that the perceived benefits of the project are realized
Depending on the value, size, and complexity of the project, the sponsor is a key player who, as a leader and mentor, can greatly assist the project manager to meet all the project’s objectives and key performance indicators.
Requirements Management
As has been explained previously, the main two components of a business case are ‘what’ is required and ‘why’ it is required. Requirements management is concerned with the ‘what’.
Clients, end users, and indeed most stakeholders have their own requirements on what they expect from the project even if the main objectives have been agreed. Requirements management is concerned with the eliciting, capturing, collating, assessing, analysing, testing, prioritizing, organizing, and documenting of all these different requirements. Many of these may of course be the common needs of a number of stakeholders and will therefore be high on the priority list, but it is the project manager who is responsible for deciding on the viability or desirability of a particular requirement and to agree with the stakeholder on whether it should or could be incorporated, taking into account the cost, time, and performance factors associated with the requirement. Once agreed, these requirements become the benchmark against which the success of the project is measured.
Ideally all the requirements should have been incorporated as clear deliverables in the objectives enshrined in the business case and confirmed by the project manager in the project management plan. It is always possible, however, that one or more stakeholders may wish to change these requirements either just before or even after the project scope has been agreed and finalized. The effect of such a change of requirement will have to be carefully examined by the project manager, who must take into account any cost implication, effects on the project programme, changes to the procedures and processes needed to incorporate the new requirement, and the environmental impact in its widest sense.
In such a situation, the project manager must immediately advise all the relevant stakeholders of the additional cost, time, and performance implications and obtain their approval before amending the objectives, scope, and cost of the project.
If the change of requirements is requested after the official start of the project, that is, after the cost and time criteria have been agreed, the new requirements will be subject to the normal project (or contract) change procedure and configuration management described elsewhere.
To log and control the requirement documents during the life of the project, a simple ‘reporting matrix’, as shown below, will be helpful.
Testing and periodic reviews of the various requirements will establish their viability and ultimate effect on the outcome of the project. The following are some of the major characteristics that should be examined as part of this testing process:
• Feasibility, operability, and time constraints
• Functionality, performance, and quality requirements and reliability
• Compliance with health and safety regulations and local by-laws
• Buildability, delivery (transportability), storage, and security
There may be occasions where the project manager is approached by a stakeholder, or even the client, to incorporate a ‘minor’ requirement ‘as a favour’. The dangers of agreeing to such a request without following the normal change management procedures are self-apparent. A small request can soon escalate into a large change once all the ramifications and spin-off effects have become apparent as this leads to the all too common ‘scope creep’. All changes to requirements, however small, must be treated as official and handled accordingly. It may of course be politically expedient not to charge a client for any additional requirement, but this is a commercial decision taken by senior management for reasons of creating goodwill, obtaining possible future contracts, or succumbing to political pressure.