| For example, a software development company may be undertaking a project to produce a new system, with an integration step towards the end of the project. Should the Risk Register include a risk that “Errors might be found during integration”, or is this just the usual technical challenge faced during this type of project?
While it is true that projects are risky ventures and they require uncertainty to be identified and managed proactively, it might be a mistake to include every uncertain task in the Risk Register. If this were the case, there could be a risk for every activity in the project plan: “Activity A might fail”, or “We might have problems with Activity B”, or “Unexpected problems might occur with Activity C”. How should we handle these types of “business-as-usual” risks?
All risks share three essential characteristics:
1. They are in the future and have not yet happened
2. They are uncertain and might not happen
3. They would matter if they did happen
However, some of our planned project tasks also share these characteristics. The reason they are included in the plan is because they occur on all similar projects, so we are ready for them. Our standard operating procedures are designed to deal with these events if they were to occur. So if we included them in the Risk Register, the appropriate response would be for someone to do their job, to follow the normal process for this type of project activity.
In effect, if we include these “business-as-usual” risks in our Risk Registers, we are saying there is a risk that someone might not do their job properly. Is this appropriate to include in the Risk Register? A well-managed project will have management processes to ensure that the appropriate people are on the project team, with the right skills, experience, training and tools for the job. Standard management tasks include monitoring and review of the plan to check that it is being followed. Audits provide assurance that professional procedures and standards are implemented. So we can usually rely on people do their job competently.
Instead of filling the Risk Register with “risks” that are very general and which require no special responses other than doing the job properly, we should focus on finding the real risks that might otherwise surprise us, for good or bad. These are the risks that require our special attention and planning to decide how to address them, since they are not covered by our standard operating procedures. We should keep “business-as-usual” risks out of the Risk Register, and use it to record real threats and opportunities, together with what we plan to do about them.
Having agreed that “business-as-usual” risks should not be included in the Risk Register, how should we stop them getting there? This should be the responsibility of the person who is facilitating the risk process (the Risk Champion or Risk Manager). They need to act as gatekeeper to the Risk Register, deciding whether each proposed risk is valid and can be entered into the Risk Register. They should be clear about what goes in and what does not, and why. This will ensure that generic so-called “risks” are excluded (as well as excluding non-risks such as facts, issues, causes, effects, worries etc.), and will help us to reserve the Risk Register for the real “uncertainties that matter”.
|
