Jason’s face was totally blank and his eyes were still. He looked completely disinterested in the proceedings. Jason (name changed) is a senior project manager with a small IT services company based in Canada. Jason was a well-respected figure in his company. His subordinates loved him, and his seniors had a very high regard for him. He had a reputation for successfully delivering his projects.
I had often wondered if Jason’s another name was “Problem Solver.” He loved to take on projects that were on the brink of disaster. And, almost always, he single handedly turned them around and delivered them.
I was hired by Jason’s company as a consultant to setup their PMO. Jason and I were participating in a weekly PMO meeting when I observed an expression on his face indicative of his losing his patience. From past experience, I knew he never liked these type of meetings. On this day in particular, I had a funny feeling that Jason was ready to explode.
I asked, “Jason, what is the most critical risk in your project?” Even before I asked the question, I knew it may have been the right question, but that I’d asked it to the wrong person. Or maybe, it was the wrong question to ask to the right person. Regardless, since I was chairing the meeting, I had to ask.
Jason seldom differentiated between risk and issues (aka problems), so his answer was, “One of the senior team members has left the organization.”
“But Jason,” I responded, “that is not a risk. It is an issue.”
Jason’s reply was “Risk. Issue. You call it what you like, but it has to be solved.”
Now, most of us understand what is a risk and issue, but very few people use these terms in the correct context. Let me throw some light on the issue (no pun intended).
Project Risk vs. Issue
The PMBOK Guide tells us that a risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives, whereas an issue is a current condition or situation that may have an impact on the project objectives.
It is clear from the definitions provided to us from The PMBOK Guide that an issue is current, whereas a risk may occur in the future.
Since an issue has already occurred, it should be tackled and resolved. However, a risk may or may not be resolved based on many factors like probability, urgency, and severity.
You can look also at these PMI (https://www.pmi.org/learning/library/risks-vs-issues-project-failure-2328) and Simplicable (https://simplicable.com/new/risk-vs-issue) articles that succinctly explain the difference between these terms.
Let’s take a look at the Jason’s statement again: “One of the senior team members has left the organization.”
Is it an issue? Obviously, yes. The event has already happened.
Let’s consider if Jason had made another statement: “One of the senior team members is likely to resign from the job.”
This would be a risk. The event is likely to occur in future, but has no happened so far.
Both risk and issue have an impact on the project. This impact can be estimated. Issues and risks are resolved (managed) in order to reduce this impact. Since issues are current, they should be resolved immediately. On the other hand, the resolution of a risk can be postponed.
How Are Risks and Issues Handled in the Corporate World?
Do you think the resolution of a risk or an issue ends up providing “bigger bang for the buck”?
Consider this. A project is on fire because of a severe issue. The project manager, with all his skills and experience, resolves the issue and douses the fire.
Will senior management appreciate the effort of the project manager? Of course. The project manager will be appreciated, even if he himself (or his team) was responsible for causing the issue in the first place.
Consider the alternative. There is risk that is likely to cause an issue in a month or so. The project manager highlights and escalates it to the senior management. He asks for more time and money to plan for and resolve the risk.
What will happen? Most likely project manager’s request will be denied.
Sponsors, customers, and senior managers don’t like to tackle risks proactively. They categorically tell the project manager to concentrate on “Issues at hand.” They say that we can take care of the risks later.
Why Do Most Project Managers Ignore the Difference Between Risk and Issue?
Let us take a look at two hypothetical projects (X and Y). Let’s assume that both the projects are similar in size (effort and cost) and land in the middle on the basis of complexity.
Project X
The first project was assigned to project manager, Alpha. He is a proactive project manager.
Alpha plans the project carefully. He meticulously understand the requirements, defines the scope, creates WBS, and lists the tasks. He estimates the duration and cost of each task before assigning it to an appropriately skilled resource.
Alpha also prepares a proper risk management plan and risk register. He proactively resolves the risks and regularly monitors the health of the project.
In the end, the project is completed successfully within the allotted time and budget.
During the course of the project, Alpha did not report any major issues. Since the project ran smoothly, senior managers presumed that the project was really simple.
Project Y
The second project was assigned to project manager, Beta. He is an action oriented person, always full of energy and passion.
Beta’s motto is “doing is more important than planning.” He believes that execution is paramount, and planning is not as important.
Beta creates a sketchy plan and pre-empts the project execution. He does not bother to consider a risk management plan or risk register. To his credit, he regularly monitors how the project is proceeding.
Due to lack of planning, the project repeatedly encounters a lot of issues. Beta reacts to the issues and manages them as they come. The team must expend extra effort to overcome these issues that could have been avoided.
In the end, the project is completed successfully albeit a bit late and over-budget.
During the course of this project, Beta makes a lot of noise about the issues. Everyone in the company is aware of what’s coming up. Senior managers think that the project was extremely difficult, but that Beta overcame the odds through persistence and hard work. They believe that the project was really complex, and that Beta did an excellent job.
Which project manager do you think would be rewarded at the year-end appraisal?
Conclusion
The truth of corporate life is that execution is given more importance over planning. Risk identification, analysis, and resolution are an important part of planning, but isn’t given due importance in the corporate world.
Instead, no one wants to spend time or money on probable future problems (aka risks).
Senior managers reward project managers who overcome the issues, even if they came about because of the project manager’s goof-ups. Somehow, meticulous planning and proactive risk management goes unrecognized.
The project manager in me does not support the current situation. Even though I know Jason’s approach to project management is wrong, I can understand what he is doing.
Whenever I take up project consultancy assignments, I always take note of the project risks before doing anything else. During my training sessions, I tell my students to identify, analyze, and resolve risks proactively.
What are your thoughts about the current corporate world scenario? Who do you think follows the right approach for managing projects? Alpha or Beta? And, how do you deal with risks and issues in your job?
I welcome your comments below.
David Squires
Praveen, good observations. There’s a reason 24 of the 48 processes (50%) in PMBOK are Planning processes. This is because the focus of project management should be on trying to foresee and plan the future (risk management included). Executing a well-planned project is straightforward work. Good project managers aren’t really managers—they’re prognosticators.
But most companies do not share this view. In fact, most companies do not want to invest the time, people and resources to do proper planning. But they always find the extra money to fix problems later which ends up costing them much more money than if they had planned properly in the first place. I’ve pondered this over the years, and I think it’s because there is a human bias towards action. It’s hard to sit down with an already busy team and have them ponder and plan. And senior management won’t ever support this approach unless they’ve personally experienced the benefits (which is very rare).
What usually happens is just what you’ve said: projects are left to chance, and the busiest PMs are lauded as they run around chasing their tails while the completion date slips and costs skyrocket. Contrast this with the PM with open books spread across his desk, staring out into space pondering the future and how to prevent past organizational sins: he’s told to get off his ass and to start running around like his “busy” peers.
Oliver Gildersleeve, Jr.
To have a Risk Registry and no Risk Reserve in the schedule would be inconsistent. To have a Reserve, the Registry needs to include each risk’s potential delay and likelihood after mitigation. Then, the necessary Reserve can be calculated using DPRODUCT. Use the unlikelihood of the risk, e.g. if the likelihood is 20%, the unlikelihood is 80%. The criteria are the Reserve, e.g. >1 day, >2 days, >3 days, etc.
Enter a Risk Reserve as a lag on the product delivery task’s predecessor. Manage the Reserve manually when a risk actually occurs or when a risk can no longer occur. For example, if there is risk of a key resource being unavailable to begin their first project task, then after on-time arrival, the Reserve can be reduced since the resource can no longer have begun late.
Issues are managed by Change Management, not Risk Management.
Estimating uncertainty can be included in a schedule by copy/pasting the column of High estimates into the Work column to get the product delivery date, then pasting a column of Median estimates into the Work column, and taking half the difference in product delivery dates as a buffer. Implement the buffer by a Start No Earlier Than constraint on the product delivery Start date. Thus, the buffer is dynamic. If the project penetrates the buffer by 1/3rd, plan recovery; if penetrated 2/3rds, compress the schedule to recover the buffer using fast-tracking, crashing, crunching, or defer scope to an enhancement project.
If a Risk Reserve is used, the estimates need to disregard risks to avoid double counting them. Implement the Risk Reserve before the estimating buffer so that the buffer does not eat up the Reserve.