Preparing a Project Brief (SU4)
The Risk Log needs to be created by this time. The Project Mandate may have referred to a number of risks facing the potential project. These may be such risks as competitor action, impending or mooted legislation, company policy changes, staff reorganisation or cash-flow problems. Certainly, the preparation of the Project Brief should give rise to an early study of such risks. Creation of the Project Approach may also have introduced some extra risks.
Authorising Initiation (DP1)
This is the first formal milestone when the Project Board can examine the Risk Log as part of deciding whether project initiation can be justified. Pragmatically, the Project Manager should have discussed informally with board members any known risks that seem to threaten the project viability.
Refining the Business Case and Risks (IP3)
The Project Manager examines risks again as part of preparing the Project Initiation Document. At this time the Project Plan will be created and this may identify a number of risks, such as unknown performance of resources, contractor ability and any assumptions being made in the plan. New risks may also come to light as a result of adding detail to the Project Brief. At the same time all existing risks are reviewed for any new information or change in their circumstances.
Authorising a Project (DP2)
The Project Board nowhas an updated RiskLog to examine as part of its decision on whether to go ahead with the project. As a result of refining the Business Case, a number of risks may have been identified. Very often the ‘owners’ of these risks will be members of the Project Board and they should confirm their ownership and the actions required of them.
Each time a plan is produced, elements of the plan may identify new risks, modify existing ones or eliminate others. No plan should be put forward for approval before its risk content has been analysed. This analysis may lead to the plan being modified in order to take the appropriate risk action(s). The Risk Log should be updated with all such details.
Updating the Risk Log (SB4)
As part of the preparation for a newstage, the Project Manager updates the RiskLog with any changes to existing risks.
Authorising a Stage or Exception Plan (DP3)
Before authorising a plan, the Project Board has the opportunity to study the risk situation as part of its judgement of the continuing viability of the project.
Authorising Work Package (CS1)
Negotiation with the Team Manager or team member may identify new risks or change old ones. It may require the Project Manager to go back and amend some part of the original Work Package or change the Stage Plan. Examples here are the assignee deciding to use new technology or needing to find special/rare resources.
Accepting a Work Package (MP1)
This is the point when the TeamManager makes out a team plan to ensure that the products of the Work Package can be delivered within the constraints of the agreed Work Package. Like any other plan, it may contain new risks or modify existing ones.
Examining Project Issues (CS4)
Assessment of a new Project Issue may throw up a risk situation. For example, a proposed change may produce a risk of pushing the stage or project beyond its tolerance margins.
Reviewing Stage Status (CS5)
This brings together the Stage Plan with its latest actual figures, the Project Plan, the Business Case, open Project Issues, the tolerance status and the Risk Log. The Project Manager (in conjunction with the Project Assurance roles) looks for risk situation changes as well as any other warning signs.
Escalating Project Issues (CS8)
As well as Project Issues, a risk change may cause the Project Manager to raise an Exception Report to the Project Board.
Reporting Highlights (CS6)
As part of this task, the Project Manager may take the opportunity to raise any risk matters with the Project Board. Examples here would be notifying the board of any risks that are no longer relevant, warning about new risks and reminders about risks that board members should be keeping an eye on.
Giving Ad Hoc Direction (DP4)
The Project Manager advises the Project Board of exception situations via the Exception Report. It has the opportunity to react with advice or a decision – for example, bringing the project to a premature close, requesting an Exception Plan or removing the problem. The Project Board may also instigate ad hoc advice on the basis of information given to it from corporate or programme management or another external source.
Identifying Follow-on Actions (CP2)
At the end of the project a number of risks may have been identified that will affect the product in its operational life. These should be transferred to the Follow-on Action Recommendations for the information of those who will support the product after the project.