Hi,

I'm a new user of PPM6 and also I'm introducing PPM6 into the company wich I'm working for. Many members of my proyect are confused with the terms "Issue" and "Risk".

As far as I know an "Issue" is a present problem that needs inmediate attention in order to be solved and a "Risk" is an uncertain situation that could o not happen and if it happens could have a positive or negative impact to the project's goals.

I would appreciate if you could help me with some opinions in order to have an easy way to dintinguish a Risk from an Issue.

Thanks.

The simplest explanation I've available is an Issue is something which is causing an obstacle right now.  It's defined, it's measurable and it's having an impact at this moment.  Task X can't be completed because of Issue Y.

A Risk is the opportunity for an obstacle to be achieved. Risks generally have mitigation plans to cover the “what if” scenarios. Once the "What if" is encountered, some people move the risk to issues, others mark them as a "realized" risk and attempt to execute the mitigation plan (if one was developed) Task X Might be impacted because of Risk Y, then again, it might not.

I agree with Luke.  A risk is a potential for something to happen and has a trigger event to watch for.  If that event happens, you can manage as an issue or action item.  A risk is something with the potential of happening.  You may say we have the potential of labor problems if we can't get a contractor by the end of the design stage.  The trigger is if you don't have the team named and your action will be to get involved at that time. 

An Issue is something actively happening that needs to be managed and escalated at times to resolution.  This issue can be stated as something you need to take action on such as budget or labor problems.

All the information is correct as above. Another key point is that (significant) risks MUST have mitigation strategies and a mitigation owner / manager. Issues on the other hand also MUST have a due date for resolution (in addition to a mitigation strategy and owner). Issues must either be resolved or accepted by a specific date.

I'm afraid I have to disagree. The problem I have with most of the responses is that "Risk" is being defined as an event similar to an issue. The Risk is the impact of an issue/event occuring. For instance, there are many things that can go wrong on a project that will impact the schedule. Plugs aren't right, and you have to order new ones; A PO is sitting waiting for an approval; Your resource was overcome by the Bubonic Plague and had to be quarantined. These are all issues, but the associated Risk is Delay to the Project. The risk of not fixing these issues is that the project will suffer from delays, and the project will not be done in the time expected, or planned. The mitigation plan to avoid these risks is to expedite shipping once a PO is cut; Move equipment to where there are proper outlets, or again, expedite shipping of the plugs; or hire a backup resource; OR modify the end date of your project (if schedule is not the primary concern).

 I like to categorize risk by the 4 main ingredients of project management: Cost, Schedule, Scope, and Quality. A cost risk involves the various events that could occur that might send the budget the way of the DoDo. A schedule risk are those described above, those that will positively or negatively impact the schedule. (Yes, there are positive risks too! You just might finish early if your resource is miraculously healed by a traveling witch doctor!) Likewise, a Scope risk is if the requirements are vague, and there is a great chance that new requirements will creep up during execution of the project plan. And of course if your project is under extreme pressure to be completed on time, no matter what, there is a great risk that the quality of the product will suffer as a result, with more attention being focused on getting it done quickly rather than getting it done right.

Kevin,

On your first point, I am going to have to disagree.  A Risk is something you need to watch for with a potential of impacting a project if you hit a trigger event or the risk actually happens.  The Issue/Action Item is something actually occurring, can be assigned for resolution/escalation, and can be outcome of a Risk once the trigger occurs. 

I have modified my Issues application to make it my RAID (Risk-Action Item-Issues-Decision) application in my environment for a number of reasons

1) It is the only application showing up in the Executive tab

2) It is a native application and allows you to make assignment if you hit the trigger item

3) You can easily morph something you are monitoring (Risk) into something you are doing (Issue/Action Item) for assignment and resolution. 

Here is how I have set up the input screen for my RAID solution

Perhaps "impact" is the word you disagree with. While your form is very nice and appropriate for capturing the details of a "risk", I stand by my assessment that a risk is not an issue that "happens". A risk exists. According to Mirriam-Webster, risk is defined as:

1: possibility of loss or injury : peril2: someone or something that creates or suggests a hazard3 a: the chance of loss or the perils to the subject matter of an insurance contract ; also : the degree of probability of such loss b: a person or thing that is a specified hazard to an insurer <a poor risk for insurance> c: an insurance hazard from a specified cause or source <war risk>4: the chance that an investment (as a stock or commodity) will lose value