Introduction to Project Risk & Control
Project management has become the principal discipline for effecting change, either in implementing strategic initiatives or simply developing new products and services. It is essential for those organisations and leaders who wish to stay ahead of the competition.
The application of project management techniques has advanced in recent decades from primarily hard projects (well-defined, physical, tangible) so that it now encompasses soft projects (more elusive, behavioural, business change). The world has moved on and so has the necessary approach to project management.
Figure 1 Types of Project and Risk
Projects and project management operate in an environment broader than that of the project itself. The project management team must understand this broader context – managing the day-to-day activities of the project is necessary for success but not sufficient – hence the importance of both strategic planning and risk management.
Because projects are unique undertakings, they involve a degree of uncertainty. Organisations performing projects will usually divide each project, or group of projects (or programmes), into several project phases to provide better management control and appropriate links to the ongoing operations of the organisation.
Well-defined principles and policies for project work create the climate which ensures that a project functions well. Questions that should be answered include:
- What is the corporate and line management’s responsibility for the project work?
- Who is responsible for committing resources?
- What are the tools and methods to be used for the management of the project?
- How are co-ordination and co-operation to be achieved?
- What are the policies for project work, in other words the fundamental guidelines for directing each project, including risk and issue management?
- What are the procedures and documentation requirements for project work?
The management of risk transcends all 6 of these questions – a fundamental project control mechanism to manage the inherent uncertainty of a project.
Control is more than just monitoring and reporting progress. In many projects, control merely means writing a few familiar quotes to the project manager on the current status or extending some lines on a bar chart to show how far the project has progressed. Perhaps the project manager reads what he gets and then conscientiously files the report, but that is where it ends. Reporting becomes a ritual you do because you are told to, rather than an activity you take seriously. Serious control means evaluating the consequences of deviations from the plan and acting upon them, often referred to as corrective action.
Key characteristics of an effective control systems include:
- Decision centres. The information should enable managers to control their area of responsibility and should be presented in a form which shows clearly when corrective action is required.
- Reporting deviations quickly, whereby project risk reporting effectively communicates to management where actual performance differs from that planned.
- Critical activities. Attention should be drawn to critical success factors. An unnecessary number of controls over relatively unimportant activities can do more harm than good.
- Flexibility. As projects are dynamic, so too should the control systems. Whilst you should periodically review your control process, too much change can be damaging as it is difficult to score when there are moving goal posts.
- The human factor. Control often provokes an emotional response from those affected, particularly where corrective action is taken, and the management challenge is to ensure staff remain well motivated.
Figure 2 Typical Risk Management Cycle
Types of Risk
Two aspects of risk should be identified and managed within each of your projects or programmes. Firstly, business risk, which reflects the priority of the project to your organisation’s business strategy. Secondly, implementation risk, which reflects the risk that you will not successfully complete the project. Typical sources of implementation risk include changes in requirements, design errors and omissions, poorly defined or understood roles and responsibilities, poor estimates and insufficiently skilled or numbers of staff.
Whilst the level of business risk may often remain fairly static, unless there is a major shift in business strategy, implementation risk is dynamic. There is the opportunity to deliver ahead of schedule (thus minimising risk), or contingency time in a project’s critical path is used (thereby reducing confidence and hence increasing risk). This means that it is important that levels of implementation risk should be regularly reviewed and updated.
Figure 3 The 4 Quadrants of Business Risk
A) Business Risk
Business risk identifies the priority of each workstream and/or project in your programme relative to the organisation’s business strategy. As an example, a simple classification for IT application projects could be as follows:
- Survival – systems which directly support core business activities which cannot be undertaken via manual workarounds for even short periods
- Critical – systems which are core to the business or are used extensively by customers where failure could be tolerated for a fixed period without losing control of the business
- Desirable – systems which facilitate operation of key margin or revenue enhancing business operations, but which could not be recovered after a longer-term period of manual operation. Or systems which are used by and preferred by customers, but they are not dependent upon
- Other – systems which are used internally which could be replaced by manual operation for an indefinite period, albeit at increased operational cost, or which could be readily outsourced, or which relate exclusively to marginal non-strategic business.
Whatever classification you choose, it is important that it is agreed at the initiation of the project and maintained in some form of static data source.
B) Implementation Risk
It is important to identify the level of implementation risk for your workstream, project or programme. The intention is to identify the aspects of projects that are particularly exposed to risk, so that the project manager can assess whether he or she wants to take action. When the completion date is an absolute deadline, a risk assessment must be as comprehensive as possible. In addition, the possibilities for reducing the level of ambition along the way should be evaluated, in case you fall behind schedule. Some examples of typical implementation risks include:
- The plan itself may have aspects of risk. Is the plan based on a realistic view of resource requirements, access to resources and calendar time? Inadequate planning may lead to gaps in the plan or bravado on the part of a project manager may give rise to excessively optimistic plans. Projects often have a slow start, while the progress plan is based on a fast pace from day one. Has the scope of the project been described in such a way that it will not grow out of control? An ineffective change management process can allow scope and plans to shift without authorisation reducing the effectiveness of performance reporting.
- Technical areas of high risk, including internal dependencies such as the availability of adequate documentation and IT infrastructure capacity (particularly for testing), and external dependencies such as reliance on third party suppliers.
- Decisions are often critical for progress. Which decisions are most important in the project? What happens if these are not made in time or if they must be made again? Can the project live with the decision-making structure and still meet deadlines? Are decisions likely to be communicated as and when they are made and how are inconsistent messages handled? Is there a poor level of management commitment, in terms of visibility, continuity, decision-making, and leadership?
- Resource requirement estimates are always an area of risk. Which resource estimates are most critical in relation to elapsed time? When assessing risks is it sufficient to concentrate on milestones which require a high level of resource input? It may be necessary to obtain minimum and maximum estimates for activities most exposed to risk. This gives an indication of the sensitivity of these activities.
- Access to appropriate resources and skills. Review skill sets required (particularly for remediation, implementation and ongoing support of new technologies). Can complete loyalty to the plan from the line be counted on, or will there be resistance? Will the project be regarded as important by key experts, or will they downgrade project work in favour of everyday line work? Are there particular areas that are vulnerable if all the required expertise is not obtained?
See later Section for many more examples of risk.
The Management of Risk
Any new venture or project involves risk. While the estimating and planning processes normally provide a contingency fund and float to cope with unexpected problems that arise, it pays to prevent problems in the first place. It also pays to concentrate the prevention effort in those areas where the risk is highest and the impact greatest.
Risk assessment and management begins by identifying the threats to project success. Each threat is then categorised based on the probability of the event occurring and its effect should the event occur. A broad spectrum of threats must be assessed from both internal and external sources. Many threats are outside the project manager’s direct control.
Figure 4 Sample Risk & Issue Log
Risk assessment and management enables early mitigation of the impact of threats to the success of the project, but all threats should be assigned to a risk owner responsible for monitoring and reporting changes etc. However, the majority of threats arise from uncertainty that is due in most cases to lack of information. These can be reduced by better information, communication and controls.
A risk management plan should be prepared as early as possible. It must cover the following key areas:
- Types, and identification, and impact of threat
- Probability of particular events occurring and impact if each does occur
- Proximity (how soon might the risk materialise)
- Contingency plans
- Risk reduction actions
- Roles and responsibilities in risk management.
- The plan should be maintained as work proceeds.
A risk assessment should be carried out during the initiation stage of each project and reviewed or redone as each new project phase starts. The identified risks must be assessed and an action plan agreed, including the probability and the impact on the plan or cost if appropriate. During the assessment process for each project, you can assign scores to each risk as a way of weighting the level of implementation risk within each project. The effectiveness of your project risk management then hinges on your ability to mitigate these risks, as well as proactively identifying new ones as they appear.
Figure 5 Sample Risk Matrix
A simple method of weighting uses the two variables, probability (or likelihood of occurrence) and impact, such as those shown in Figure 5. Multiplying the assignment of probability and impact scores gives a priority weighting to that risk. For example, if you deem that, for example, the risk that a project will not have to access to a skilled resource to be likely (score 3) and the impact of that risk occurring is severe (score 4), then this identified risk has a score of 12.
Many people differentiate issues from risks… but we advocate that issues are dealt with in the same way as risks, as they are simply risks that have materialised with a proximity of NOW. They need to be suitably categorised in the same way to determine the right priority for effective resolution, the timeline for which may be right away and rapid, to keep a project on track. This third dimension of risk, Proximity, is the key to really staying on top of your both your risks and your issues and is possible to show to key stakeholders to bring timeline into the equation, such as the Sample Top 10 Risks Report in Figure 6.
Figure 6 Sample Top Risk Report showing Impact, Probability & Proximity
The assignment of scores is a necessarily subjective process but it creates a consistent and logical framework for determining the level of risk within a project. This information can be used in two ways.
Firstly, to identify projects which may need a greater degree of supervision and/or further action if they are to be completed successfully. Secondly, to identify key risks requiring further action. Those risks scoring, say 15 and above, require specific focus and mitigating action. These key risks may require swift escalation through the management structure to ensure continuing proactive management of project or programme risks. This can reduce the implementation risk across all projects if used consistently across an organisation’s project portfolio.
Responses to risks generally fall into three categories:
- Avoidance – eliminating a specific risk usually by eliminating the cause. The project management team can never eliminate all risk, but specific risk events can often be eliminated.
- Mitigation – reducing the expected impact of a risk event by reducing the probability of occurrence.
- Acceptance – accepting the consequences. Acceptance can be active (e.g. by developing a contingency plan to execute should the risk event occur) or passive (e.g. by accepting a delayed completion date if some activities overrun).
The risk management action plan should document the procedures that will be used to manage risk throughout the project. In addition to documenting the results of the risk identification and risk quantification processes, it should cover who is responsible for managing various areas of risk, how the initial identification and quantification outputs will be maintained, how contingency plans will be implemented, and how risk will be periodically reviewed.
Combining an effective classification of the two types of risk (business and implementation risk) across projects allows you to focus on those projects that have the greatest impact on your business in the event of project failure and identifies the key risks that you need to respond to.
Figure 7 Simple Portfolio or Programme Risk Management Matrix
One simple method used to combine the classification of business risk and implementation risk within each project is to create a portfolio or programme risk management matrix, such as the one shown in Figure 7. As each new project is initiated, classifications of each risk are assigned to the project and logged in the matrix. This allows the portfolio or programme management team to view and manage the project relative to all other projects underway. Management can focus on those survival and critical projects with high implementation risk (projects 2 and 4 in Figure 7), whilst maintaining a watch on medium and low risk and non-critical projects. Contingency plans can be prepared, and effort prioritised for business-critical projects, with subsequent effort on high-risk projects. This tool may also be used to re-allocate resources from non-critical projects to critical projects, or from low risk to high risk.
Whatever method is used, the level of implementation risk assigned should reflect the overall level of confidence that the deadline for implementation will be met, with the project benefits and outcomes delivered as expected within the cost and quality envelopes set.
Complexity & Risk
One Namaste Management tool, which we have found to be particularly valuable when setting up or assessing the risk of a workstream, project or programme is our complexity analysis, which combines business and integration risk in detail, yet is quick and easy to use. We all know that financial scale is not a reliable indicator of ‘how difficult’ a project will be to deliver, so it is important to look at a much broader range of factors. The tool can also be used as part of a health check, or standalone, when mobilising your team.
Figure 8 Complexity Analysis Factors and Sample Results
The complexity tool is designed to promote team discussion to quickly compare and highlight the relative complexity and risk inherent in your workstream, project or programme. It allows comparison across entire programmes and/or each of the workstreams of an individual project. This analysis also provides a reliable assessment of the risk, as well as the level of skill and capabilities required to deliver a workstream, as the weighting and scoring within it is based on the experience of hundreds of projects and programmes.
The value of these types of analyses and the actions they drive is, of course, wholly dependent upon the deep experience of the team.
Examples of Risk
Project implementation risks are potential issues that may arise during the execution phase of a project, threatening its successful completion. These risks can be categorised into several groups:
1. Technical Risks
Definition: Risks associated with technology, tools, systems, or processes used in the project. Examples:
- New or untested technology not working as expected.
- Integration failures between systems.
- Inadequate infrastructure or system performance.
2. Operational Risks
Definition: Risks related to day-to-day operations or procedures involved in project implementation. Examples:
- Inefficient workflows or resource allocation.
- Lack of standard operating procedures.
- Process disruptions due to equipment failure.
3. Financial Risks
Definition: Risks involving the project’s budget and cost management. Examples:
- Cost overruns or underestimated costs.
- Delayed funding or cash flow issues.
- Unexpected financial liabilities.
4. Schedule Risks
Definition: Risks that may cause delays in the project timeline. Examples:
- Inaccurate time estimates.
- Dependencies causing bottlenecks.
- Delays from third-party vendors or regulatory approvals.
5. Resource Risks
Definition: Risks related to the availability and allocation of human, material, or technical resources. Examples:
- Key personnel leaving mid-project.
- Shortages in critical materials.
- Conflicts in resource assignments.
6. Stakeholder Risks
Definition: Risks involving project stakeholders, including sponsors, customers, or partners. Examples:
- Misalignment of stakeholder expectations.
- Conflicting stakeholder interests.
- Lack of stakeholder engagement or support.
7. Legal and Regulatory Risks
Definition: Risks stemming from legal issues or non-compliance with laws and regulations. Examples:
- Violation of industry regulations.
- Issues with contracts or intellectual property.
- Changes in laws affecting project scope or feasibility.
8. Strategic Risks
Definition: Risks that affect the alignment of the project with broader business goals or strategies. Examples:
- Shifts in market conditions or corporate strategy.
- Projects becoming obsolete or misaligned with business priorities.
- Mergers or acquisitions affecting project relevance.
9. Environmental and External Risks
Definition: Risks originating outside the project, often beyond control. Examples:
- Natural disasters or pandemics.
- Political instability.
- Supply chain disruptions.
10. Communication Risks
Definition: Risks related to the flow of information among project stakeholders. Examples:
- Misunderstandings due to poor communication.
- Incomplete or inaccurate reporting.
- Failure to keep key stakeholders informed.
Finally, for those of you running Merger or Acquisition Integration Projects, Figure 9 shows examples of common integration risks that we have seen occur regularly across many different transactions. The Integration Team must have a robust risk identification & mitigation process, to ensure roadblocks can be cleared ahead of time, but if they do become Issues, there are also clear forums to resolve them quickly.
Figure 9 Common M&A Integration Risks
Namaste Management is pleased to offer the following tools in our Shop:
- Risk (and Issue) Log & Matrix (Add URL)
- Complexity Tool (Add URL)
