Risk management process checklist

This checklist shows whether your risk management process is complete. For any question you answer ‘no’ to, decide how to include it in your risk management process.

The sources of risk

The following checklist will help in identifying your project’s risks. It does not tell you what your risks are, but will help to trigger your thinking. For every question to which you answer ‘no’, consider the possible risk implications. It is not possible to write a generic set of risks that is exhaustive, and so this should be used as a starting point for identifying risk, rather than for understanding your full risk situation.

Dealing with risks

Use this checklist when you have identified your risks and need help in understanding the implications. It contains a summary of qualitative risk assessment. (Quantitative risk assessment is outside of the scope of this book.)

1. Do you understand what the risk is?
   • What will this risk affect if it occurs, the project or the business? (In the worst case will the risk make the project fail, or will it have wider implications for your business or organisation?)
   • Is it a project risk? Can you manage it, with your sponsor’s and customers’ support?
   • Is it a business risk? Make sure the parts of the business affected by the risk understand and accept the risk.
2. Define a scale on which you will assess impact and likelihood of risk. For small projects a simple scale of high, medium and low is usually enough.
3. What is the impact on the project of this risk occurring?
4. What is the likelihood of the risk occurring?
5. What is the impact on the business or organisation if this risk occurs? Overall risk = likelihood × impact.

Use the following checklist to decide on the appropriate management action when you have identified and assessed the risk.

1. Start risk management as your project begins. When you start thinking about the project and developing your plan, think about risk. The best way to deal with risks is to identify them early and build any action to overcome them into your plan.
2. Don’t worry when you find risks – project management is largely about risk management!
3. Put a risk management process in place (see page 151).
4. Identify risks (see page 152).
5. Understand and prioritise risks (see above).
6. Ensure stakeholders and customers understand project risks.
7. Decide on action for each prioritised risk:
   • Do nothing, but continue to monitor.
   • Reduce the likelihood of the risk occurring.
   • Reduce the project’s exposure to the risk.
   • Make a contingency plan to deal with the effects of the risk.
   • In the worst case, if the risk to business is too high and it is not possible to mitigate or avoid the risk, stop the project and determine if there is a different way to achieve your goals.
8. Determine the most appropriate time to take action. It may be now; it may be later when a specific event has occurred or you have more information. (However, you have to do it soon enough so that your action will be effective.)
9. Take the risk management action.
10. Assess the result and, if necessary, keep taking action.
11. Continue to manage risks throughout the life of the project.

Dealing with issues

Problems will arise on projects. Any problem that disrupts the project is known as an issue. The following list provides a set of questions to help in identifying issues. For any question to which you answer ‘yes’, you may have an issue.

The next checklist gives you guidance as to whether your issue management process is complete. For any question you answer ‘no’ to, think through the implications and decide how to include this in your process.

Dealing with assumptions

Assumptions are a source of risk on projects, yet assumptions must be made. There is nothing wrong with making assumptions, as long as they are explicit and reasonable. Unfortunately, assumptions are often implicit or unconscious, and difficult to identify. To detect assumptions:

1. Constantly identify assumptions:
   • As you consolidate or create project information such as scoping documents and project plans.
   • Through assumption review sessions. Pull together the project team specifically to review the project plan, scope, requirements, etc. for assumptions.
   • Through feedback from reviewers, the project sponsor and stakeholders. They will often identify assumptions.
   • As an ongoing part of the project. All team members should be able to notify the project manager of new assumptions.
2. In each situation ask: is there a factual and logical basis for the information I am using, or the decisions I am making? If not, you are making an assumption. Are there any jumps in my logic? If there are, you may be making an assumption.
3. Clarify and verify any assumptions you are making:
   • What is the assumption? Document it and remove any ambiguity from the definition.
   • Check it is reasonable to make an assumption. Do you have to make an assumption – i.e., is there no factual information available, or is the cost or effort of getting that information higher than is reasonable?
   • Is this the most reasonable assumption you can make at this time?
4. Filter out irrelevant assumptions – those that are trivial (e.g., I assume there will be paper in the photocopier when I get there) and those which common sense dictates should be ignored (e.g., we assume the company we are working for will still exist tomorrow).
   
   Assumptions should be managed. The following steps provide a straightforward way to manage assumptions:
    
5. Identify and log the assumption. You must get into the habit of documenting assumptions. A common shared assumptions log visible to and accessible by the whole project team is the best way to do this.
6. Identify the sensitivity of the project to the assumption. What will happen if this assumption is false?
7. Assess the likelihood of the assumption being false.
8. Update the risk register accordingly, and put any risk management activities in place if the assumption has a high impact or high probability of being wrong.
9. Assign an assumption owner – responsible for tracking the assumption and alerting the project manager if it changes.
10. Challenge each assumption – ensure it is reasonable. Ask yourself questions such as:
    • Do you really have to make an assumption?
    • Is the assumption you have made reasonable?
    • In what conditions is it true?
    • Can those conditions be removed?
11. If appropriate, set a date for the assumption to be verified by.
12. Verify assumptions, and as you do update the project and the plan according to the facts.

Change control

Change control is a critical process in project management, providing a process to manage the implementation of changes. Modifications or alterations will always occur on projects, and without change control projects risk descending into chaos. Change control should not stop the project altering, but makes sure it is done in a controlled way.

Change control is conceptually simple:

1. Document the proposed change in sufficient detail for the change to be clear and unambiguous.
2. Justify the change: describe why the change is being proposed, and the benefits of implementing the change.
3. Identify when the change needs to be accepted by, if it is to be effective.
4. Identify the impact of the change – will it alter the length of the project, the resources required, or the cost? Does it change the level of quality or risk? Will it affect assessments of project success?
5. Seek authorisation for the change, accepting the impact on the project. Authorisation comes from the project sponsor and key stakeholders.
6. Note the proposed action with regard to this change. The action can be: accept and implement the change, modify the request, or reject it.
7. Keep track of the current status of the change. It can be:
   • ‘in review’, i.e. the change is currently being assessed
   • ‘accepted’, i.e. it is agreed and has been built into plans
   • ‘rejected’, i.e. the project will continue unchanged
   • ‘closed’, i.e. the change has been actioned.
8. Implement any agreed actions regarding the change.
9. Monitor the impact of the change and, if appropriate, take remedial action following the implementation of a change.

Project managers and sponsors must consider the cumulative impact of changes on the project. If there are too many changes, the project becomes unstable and it becomes difficult to deliver. Scope creep is the name for a situation in which the cumulative impact of many changes risks the project becoming unachievable, or the project bearing no resemblance to the original objectives.

Identifying and managing stakeholders

Successful project teams interact with a wide range of people who will be impacted by the project and who have an impact on the project. These are the project stakeholders. Project stakeholders are identified in order to understand and collect requirements, to determine project success criteria, and because they are an integral part of any change following project completion.

1. Identify the stakeholders in the project:
   • Who will benefit from the project?
   • Who will suffer from the project?
   • Who else is interested in the project?
   • Think about internal customers, internal suppliers, users, financiers, staff and anyone else who will benefit or lose from the project. For some projects you should consider stakeholders external to the firm (customers, trade unions, suppliers).
2. Review the set of potential stakeholders with the project sponsor. Amend list accordingly.
3. Assess the power, influence, attitude towards the project and openness to change of each of the stakeholders:
   • Power or influence: how capable is each of the stakeholders of disrupting or helping this project?
   • Attitude: how likely is each of the stakeholders to help or disrupt the project?
   • Openness to change: people with fixed ideas can be powerful supporters but difficult objectors.
4. Categorise the groups of stakeholders:
   • High power and influence + positive attitude to the project: try to get them actively supporting the project and working to overcome any resisters.
   • High power and influence + negative attitude to the project: try to overcome their objections. If this is not possible, use your supporters to block their influence.
   • Low power and influence + positive attitude to the project: try to choose your project team from this group.
   • Low power and influence + negative attitude to the project: use general communications and presentations to try and convince them.
5. Identify which stakeholders and groups of stakeholders you will actively manage as part of the project. Concentrate on those stakeholders with the strongest positive or negative views on the project or abilities to influence project outcomes – and those stakeholders you are capable of managing or influencing.
6. Determine how to utilise the various stakeholder groups that you will manage.
7. Build stakeholder needs into project activity plan, especially the communications plan. (See pages 89 and 98).
8. Periodically review stakeholders’ views. Attitudes can change as projects progress, and the variety of stakeholders can also evolve as the project impacts on different people.

A key part of stakeholder management is expectations management. This involves communications to ensure that stakeholder expectations are in line with what the project will deliver. By managing expectations, project managers avoid many problems. Key points about expectations management are:

• Understand that expectations management is an important task. Although it may not directly affect delivery, it has a significant impact on the interpretation of project success.
• Start managing expectations from the very beginning of the project.
• Regularly communicate with all key stakeholders. Explore their expectations and try to influence them to be in line with the reality of the project.
• Always try to under-promise and over-deliver.
• Try to avoid surprises on the project – surprises indicate you are either not in control or you are not telling the full truth. Either will lead to reduced trust and negative expectations.

Estimating and managing a project budget

A budget must be agreed at the initiation of a project to provide the funds for the project. (Also see pages 89 and 235.)

1. Identify what components of the project must be paid for. There are many items which are obvious, such as the resources to be bought for the project. For some items it is less clear whether they have to be budgeted for or not. If you are unclear discuss with your finance department. For example:
   • Staff time – is this charged for? If so, at what rate and how is it tracked?
   • Internal facilities and consumables, e.g. meeting rooms and printing facilities.
   • Indirect cost allocations. Is a percentage of indirect costs added to the project (e.g. overhead, and general and administrative costs)?
   • Capital investments made by the project.
   • In-life and operational costs once the project has gone live. These are usually picked up in operational budgets, but sometimes a project is expected to pay them for a certain period, e.g. until the end of the current financial year.
2. Based on the project plan, determine how much of each resource must be paid for.
3. Add contingency. The percentage of contingency should be related to the level of risk in the project.
4. Create a draft budget.
5. Have the draft budget reviewed by the project sponsor and the finance department. Update according to feedback.
6. Determine if the project is already budgeted for or not in an operational or line manager’s budget:
   • If it is budgeted for, ensure that the allocated budget matches what the project requires.
   • If it is not budgeted for, determine where the project budget will be allocated from.
7. Seek approval for the budget, using normal approval processes.
8. Amend budget and project plan according to approval. If less is approved than required, the project strategy or scope needs to be reviewed.
9. Track usage, e.g. even if a bill has not been raised, you have effectively spent money as soon as you have committed to using a resource.
10. Track progress against the budget. The aim is for the budget to decline at no faster rate than progress is being made (taking account of exceptional purchases). (See page 107.)
11. Seek approval for additional spend or to access contingency funds if required.
12. Release any funds remaining at the end of project.

Other considerations when planning or managing a project budget are:

• The effects of an organisation’s financial reporting cycles.
• The ways in which finance departments track expenditure and progress, which may be quite different from the way in which project managers track them.
• Approval processes to spend money within a budget. Although a total budget is approved, individual items of significant expenditure may still require approval.
• The accounting treatments and the associated implications for different types of budget categories (e.g. opex (operating costs) and capex (capital costs)).
• Handling multiple budgets and the need to allocate project costs across different cost centres.
• Accounting practice in terms of what is and what is not expected to be accounted for in a project.
• Purchase requisition (PR) and purchase order (PO) processes, and the associated approval timeframes.

Project performance metrics

There is a wide range of performance metrics to assess projects. This list provides a sample of them. Metrics are used to support the management of an individual project and to compare projects. Whichever metrics are used, care should be taken to ensure that sources of data are accurate. While performance can be indicated by a metric, it usually requires interpretation and contextual information.

There are three types of measures to assess project performance:

• measures which quantify project progress, e.g. 60 per cent of project tasks are complete
• measures which quantify delivery, e.g. 60 per cent of project deliverables have been created
• measures which quantify outcomes, e.g. 60 per cent of expected benefits have been achieved.

Potential metrics for comparison between projects or assessing overall performance are:

• delivery to time and cost
• percentage of expected benefits delivered
• return on project investment
• stakeholder satisfaction levels
• staff satisfaction and staff assessment of learning from project.

For the management of a project:

• performance at a point in time:
  • progress versus plan
  • number of open issues
  • number of open risks
  • cumulative risk level (if using quantitative risk assessments)
  • number of change controls raised
  • schedule variance and cost variance (if using EVA − Earned Value Analysis)
  • percentage of expected benefits delivered.
• Progress trends:
  • activity completed versus planned
  • actual spend versus planned spend
  • percentage contingency use versus percentage complete
  • number of open issues over time
  • number of risks over time
  • number of change controls over time
  • cumulative risk level over time (if using quantitative risk assessments)
  • schedule variance and cost variance over time (if using EVA)
  • progress towards overall benefits targets

Additional and more advanced project management techniques and tools

A book of checklists is a reduced version of the richness and variety of project management approaches. This table contains references to more advanced project management techniques.