It is easy to forget about ‘why’ the project exists. The Business Case indicates why the project is being carried out.
It is important to anticipate any problems or threats that may have an affect on the project so that appropriate actions can be taken.
This process takes the outline Business Case form the Project Brief and the resource requirements from the Project Plan.
From these the sub-process produces a refined Business Case that is later incorporated into the Project Initiation Document.
It also updates the Risk Log with any expansion on risks discovered when writing the Project Initiation Document, plus the addition of any extra risks found since.
The sub-process refines the Business Case and may reveal extra risks.
The objectives are:
To achieve the above certain steps are required:
For the Business Case:
For the Risk Log:
For the Project Plan:
Where there is a serious risk the Project Board may require a contingency plan and approve a budget for it.
This would only be used if the risk occurs.
The decision on project viability will be a balance of risk and identified costs against the agreed benefits.
If any of the steps raise a problem that may affect the Business Case then the Project Board will need to be informed as soon as possible.
The Project Board may need to raise a Project Issues with corporate or programme management.
The Project Manager is responsible for this sub-process.
There will be assistance from Project Support and advice from Project Assurance as necessary.
The Project Manager should informally discuss the Business Case and risks with the Project Board before presentation in the Project Initiation Document.
Management information | Usage | Explanation |
---|---|---|
Project Brief | Input | Contains high-level views of the anticipated business benefits and risks as identified in Starting up a Project (SU). |
Project Approach | Input | Will contain information about the way the work is to be conducted and could provide input to both the Business Case and risk analysis. |
Risk Log | Update | Add any identified new risks. Modify with details of any changed risks. |
Project Plan | Update | Update with any significant extra activities and resource requirements to counter risk exposure. |
Business Case | Update | Extract from the Project Brief and update with the latest (more detailed) information |
These are given in tabular form in the file ‘IP3 refining the business case and risks.doc’ in the product package.
By the very nature of risks they will in themselves cause another effect in a cause-effect chain. Its up to the Project Manager to know where to cut the chain.
If the project is part of a programme then you must use its risk monitoring mechanism unless there is a valid reason not to.
It would be good practice to combine the maintenance of all Risk Logs at the programme level.
Usually the customer pays for the project but in some cases the supplier may fully or partially fund the project.
In this situation the customer may have less rights to insist on the inclusion of risk avoidance or reduction activities.
The customer and the supplier are likely to have different Business Cases.
Payment methods to suppliers must be considered. It could be: