How Much Risk You Are Willing to Tolerate?
Every project manager deals with risk assessment and risk management. If done right, the project manager will ensure the overall project plan includes a risk management plan early in the project. The risk management plan is typically guided by the risk attitude of the project stakeholders, which is determined by their risk appetite, risk tolerance, and risk threshold.
The PMBOK Guide offers detailed definitions and guidance for each of these factors. For this discussion, we will use simplified descriptions:
Risk appetite is the level of risk that an organization is willing to accept to reach its goals and objectives. Risk appetite is typically culturally determined within the organization.
Risk tolerance tells you how sensitive the organization or the project stakeholders are to risks, their willingness to accept or avoid risk. Risk tolerance is variable, if not fluid, from person to person.
Risk threshold is the level of impact, typically a clear figure, beyond which the organization will no longer tolerate the risk. Risk threshold is a negotiated or determined quantified limit.
Project stakeholders are hardly ever asked what their individual tolerance level is. They agree on the risk management plan, but transfer their trust and expectations to the project manager. Stakeholders may understand the risk, but they may not fully grasp what acceptance of the risk means in practice.
When this happens, the true tolerance level associated with a risk is not understood. Then, if the project goes wrong due to the impact from an exposed risk, it’s the project manager in the hot seat.
There are 5 project components that consistently warrant a dedicated risk tolerance discussion between the project manager and stakeholders.
Risk 1: The Steering Committee
A poor steering committee can bring down any project. On the other hand, a well-functioning steering committee is a necessity to give any project a chance to succeed.
Think of the steering committee as the board of directors for a project; the sponsor is the chairman of the board; the project manager is the CEO.
If the project manager determines the steering committee may not have the right players and capabilities to support the project, she needs to share her concerns with the sponsor. Symptoms may include: shallow commitment to the project, no skin in the game, questionable respect or support for the project team, refusal of ownership for change management, poor attendance to steering committee meetings, no familiarity with the project objectives and desired effects.
Few organizations have perfect steering committees all the time. However, continued focus on project delivery and success will improve the quality of steering committees. Project managers have a responsibility to play a role in this change process. A poor committee makes for a very unpleasant journey, and a likely project failure.
Therefore, the project manager needs to decide how much risk tolerance she is willing to deal with when it comes to the quality and performance of the steering committee. This may be difficult, but not extraordinarily complex.
Risk 2: The Change Control Process
To govern changes to project scope, organizations often use a change control process and a change control board that applies the process.
It is critical for the project manager to assess:
- the maturity of the process
- the track record of the change control board
- the project manager’s personal tolerance level for scope changes and ability to effectively manage the project given the conditions
If the maturity of the change control process is below expectations, discuss improvement opportunities with the chair of the change control board.
If the track record of the change control board is poor, discuss the matter with the steering committee and suggest implementation of operating guidelines to limit project disruptions caused by the change control board.
If the number of expected scope changes is too high, consider the feasibility of setting stricter change control guidelines and/or criteria to reduce the level of changes.
The project manager needs to be personally tolerant of the risk level presented by the change control process. Early discussions of any red flags will avoid potential disappointments.
Risk 3: The Testing Phase
Determining your testing phase risk tolerance is not an easy task. The tendency is to plan the testing phase as if everything will be fine when testing comes around.
Early in the project, you may not have enough data to work with. It is especially important to draw from past experience with similar projects in this case.
New testing methods, automation tools, and diverse participants give the project manager a much richer menu of approaches to choose from during project planning.
To control for the risk of delays from testing:
- include developers in the testing process
- use feedback tools
- use error tracking approaches
- use automated testing tools in addition to manual testing
- use exploratory testing
- include more resources, early and often, to increase the testing feedback level
Based on agreed-upon methods, tools, and resources, the project manager should develop a solid software test strategy to manage her own risk tolerance level in this area. It is prudent to keep your risk tolerance margin narrow from the start, and stick to it.
Risk 4: The Issues Escalation Process
Every experienced project manager has seen both of these extreme scenarios happen: Escalate every issue, and the stakeholders lose patience and eventually ignore even the critical requests; don’t escalate enough issues, and the project run into delays.
Determining risk tolerance for a project’s issue escalation process is tricky. Knowing when to escalate issues, and how to do it right, will help minimize risk for this aspect of a project.
The following questions (credit to Hrishikesh Karekar) will help set the proper context and guide the decision when the time is right to escalate.
- Have you made a sincere attempt to reach a resolution and are you at a dead end?
- Is this an issue that your manager would expect you to handle or to escalate?
- Do you have all the know-how to make the decision, or does another SME or stakeholder need to be consulted?
- Can you approach these SMEs or stakeholders directly without going through an escalation route, or is escalation the only way to get their input?
- Have you exhausted all other options and any further delay that could have a detrimental effect on the project outcome or deliverables?
When the time is right, the project manager should:
- Escalate to the right person with the power to influence
- Escalate via the proper channel
- Escalate to an appropriate level
- State the right problem very clearly
- State explicitly what is needed
- Follow up (the project manager still owns the issue)
- Use the right, respectful content in communications
- Escalate in a mature and respectful manner
Escalation is as much of an art as it is a science. Properly managing the process will allow the project manager to control a narrow tolerance level for this risk.
Risk 5: Communication
Communication often falls to the bottom of everyone’s to-do list. It’s an unfortunate byproduct of today’s rapid-fire business environment. Meetings get canceled, reports get ignored, and questions go unasked. Every project manager understands the risks associated with this behavior.
But good communications keep stakeholders engaged and project teams motivated. PMI research (Communications: The Message is Clear) indicates that organizations that communicate more effectively have more successful projects. Thus, a reduced risk!
The project manager can control the tolerance for communications risk to their own comfort level by creating a communications plan as part of the overall project plan. A proper communications plan outlines what needs to be communicated and to whom, how often these exchanges should happen, in what format delivery is delivered, and why they are necessary.
Remember, communication is not just talking; it also includes listening.
The project manager can even dial down the risk level via daily informal communications with stakeholders and business users. Don’t underestimate the power of informal communications; it keeps you one step ahead of the rumors and “alternative facts.”
When the client and stakeholders are kept up to date on progress, risks, and potential issues, it creates trust that the team is delivering to expectations, and it makes it easier to solve problems when they arise.
Building a communications plan and consistently executing against the plan is critical to keep communications risk in check.
Project managers should keep an eye on their risk tolerance dashboard to make sure the various risk areas stay within their predefined limits.
Use solid project management best practices, complemented with some personal touches, and start planning and managing risk tolerance early in the project.
In preparation for this article I researched several articles and reports to nourish my thoughts on this topic. Special acknowledgements go out to: