Project Management Central

Please login or join to subscribe to this thread

Topics: Innovation, Organizational Project Management, Risk Management
Is this considered as project risk or project issue?
Dear Everyone,

Recently there are some debating regarding the risk or issue in my work. Appreciate if you can help me to assess the scenario and provide your opinion.:)

Scenario Description: There is an engineer A assigned to a project. Let's say his assigned work will start on 1st July, and finish on 10th July. In June, the project manager notices that engineer A seems to have been overloaded by too much work recently. If this continues, engineer A may not be able to complete the work on time which will come in early July later. Then the project manager tries to discuss with A's functional manager to find a mitigation method. for example offload A during his task period, etc. At the meantime, the project manager reports this as a "project RISK".

Then another colleague disagrees to report it as project risk, but think need to report it as a project issue. The reason he gives is that he is already overloaded. This is something already happening so it's not a risk. Risk should be something which has not happened yet.

However, I have a different point of view. In this case, he is indeed already overloaded at this point in time. However, his work in the project has not started yet. He has not really delayed the schedule yet. The project schedule, for now, is still on track. It's just a risk that he will delay the schedule. If he continues to be that overloaded until July, then he will really delay the schedule and it will turn into an issue.

If scenario changes, engineer A is already overloaded, he is already doing the project task, and A's project task has already been overdue for 5 days. Then it's an issue because the negative impact has already occurred.

In summary, here is my understanding.
An issue is something which has already imposed a bad impact to the project (schedule already delayed, budget already overrun, scope already creep..etc)
A risk is something which will potentially and might impose a bad impact to the project in future regardless of whether it's happening now or not. However, at this point of time, the project performance baseline has not deviated. We can still apply risk mitigation to avoid a bad impact on the project.

If you face this scenario, will you report it as a project risk or project issue? Any opinion is welcomed.
Sort By:
Page: 1 2 3 next>

If there is a chance that the schedule will be overrun it is listed as a risk. A risk is something that has not happened yet, no matter how likely it is. Once it happens it becomes an issue. So if the schedule is overrun then it is an issue and not a risk anymore. So your summary is correct.
1 reply by LIJUAN LI
Jun 20, 2019 1:08 AM
Thanks a lot Anton. I am the poster.

Jun 20, 2019 12:32 AM
Replying to Anton Oosthuizen
If there is a chance that the schedule will be overrun it is listed as a risk. A risk is something that has not happened yet, no matter how likely it is. Once it happens it becomes an issue. So if the schedule is overrun then it is an issue and not a risk anymore. So your summary is correct.
Thanks a lot Anton. I am the poster.

Agree with Anton.

Agree with Anton. It seems it is a risk for the project

Agree with Anton

Your provided scenario is very clear. It's not an Issue yet. Realization of risk becomes an issue. Thus it's should be reported only as risk.

Agree with Anton. Also can rate the risks in a matrix - likelihood, and impact. Any risks above a specified threshold would have a mitigation plan in place. So, for this particular scenario shared, would certainly have that plan at the ready.

This is a risk, but it sounds like it has a high probability of occurring. Calculate the risk score (risk probability x risk impact), then deal with it accordingly.

Yup, it's risk as it has not been happened as of now.

Everything should be evaluated within the context of your project. As you yourself summarized, the "issue" of A being overloaded belongs to someone else. It is only a risk on your project.

This can be difficult to assess for both risks and issues. At the end of the day, you have to ask yourself: "what project outcome is impacted by the issue or risk?" If you can't answer the question, it's not your risk or your issue.
1 reply by LIJUAN LI
Jun 23, 2019 10:53 PM
Hi Stephane,

I agree with you.

There are many things or issues going on in the organization. However, if they are not now or will not intersect with the project in the future, it basically has nothing do with the project. Those are neither issue or risk to the project. If they are imposing an impact to the project now, they are project issue. If they are not imposing an impact to the project now but will impose an impact to the project in the future, then it's a project risk. We can still use mitigation strategy to avoid, reduce, or accept the risk based on the scenario.

Actually, you have BOTH an issue and a risk. The issue you have is closely related to the risk, but they are not quite the same.

To clarify this, you have to look at the PMBOK® Guide's definitions of issue and risk:

Issue - a current condition or situation that may have an impact on the project objectives.

Risk - an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives.

Issues and Risks are similar in that they may affect project objectives. They are different in that issues are CURRENT conditions or situations, while risks are UNCERTAIN events or conditions. An issue is something that has happened, or is happening. A risk is something that might happen.

You have an overloaded engineer. That's an issue. It's current, and it may affect project objectives. It needs to be added to the issue log, and assigned to someone to deal with it.

Your overloaded engineer might not deliver on time. That's a risk. It may or may not happen, but if it does, it has an effect on project objectives. (Assuming that late delivery of this engineer's work will indeed affect project outcomes, which it might not if it's not on the critical path.) It should be added to the risk register, prioritized using qualitative risk analysis, risk responses planned, and assigned to someone.

This issue and risk are closely related, and have the same root cause, and should probably both be assigned to the same person. You will at least need to coordinate them, and you may want to manage them together using just risk management (which provides more tools & techniques for managing them), and use the issue log simply to keep a record of the occurrence.

Also note that the PMBOK® Guide (p.96) describes the issue log saying "Throughout the life cycle of a project, the project manager will normally face problems, gaps, inconsistencies, or conflicts that occur unexpectedly and that require some action so they do not impact the project performance."

Notice that these are things that occur UNEXPECTEDLY, meaning that they were not identified risks. At a minimum, this means that the issue log includes items that were not identified as risks, and so did not go through risk analysis & response planning.

Some may argue that risks that occur don't belong in the issue log because they were expected, and are being managed in the risk register. Personally, I like to have them in issue log in order to have a single place that lists all current situations, whether expected or unexpected.
3 replies by Sanjay Kumar and Stéphane Parent
Jun 20, 2019 6:59 PM
Stéphane Parent
I think the new definition of issue in the sixth edition of the PMBOK Guide is unfortunate. If you take it literally, you will have an awful lot of issues in your issue log. The problem with the definition is the word "may".

The butterfly beating its wings on the other side of the planet may impact your project objectives.
Jun 20, 2019 7:05 PM
Stéphane Parent
I believe that a risk with a contingency plan does not belong in the issue log when triggered. Your contingency plan will go in the schedule then you have planned activities that need to be managed.

Adding the trigerred risk to your issue log will mean that you cannot close the issue until resolved, in this case completing all contingency plan actions. My goal is to resolve issues as quickly as possible, not leave them on the issue log as a memory jogger.
Jun 24, 2019 5:16 AM
Sanjay Kumar
Agree, but only on definition of the issue and description.

However PMI also says that even if certain, but hasn't occurred cannot be categorized as Issue. It will remain as Risk (even if probability of the occurrence is 100%) until realized.
Page: 1 2 3 next>  

Please login or join to reply

Content ID:

While hunting in Africa, I shot an elephant in my pajamas. How an elephant got into my pajamas I'll never know.

- Groucho Marx