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.