Technical Project Management - Risks, Issues, and Actions

In project management, risk equals action.  Too often, risks are looked at as things to watch out for in the future, meaning - stick them in a list somewhere that rarely gets reviewed.  The primary goal when a risk is identified should be to generate an action.  As a simple example, a pure risk would be "single point of failure. server may be down in the future."  This would be typically listed in a project status report or something similar.  If the intention is to monitor the server, that becomes the action.  But if it is an accepted risk, does it still deserve action?  If it is accepted, it does not need to be tracked.  It needs to be documented and stored somewhere.  That is the action.  This reinforces the strong tie of risk and action.

Effective project management involves cataloging issues and risks.  The distinction is often made that an issue is something that has occurred, whereas a risk is something that has the possibility of occurring.  I believe this to be a meaningless distinction.  Take the risk above as an example: "single point of failure. server may be down in the future."  Classically, it might be a risk, as nothing has happened yet.  This leads project managers to, again, put it on a list and shelve it.  But since action is required, what is the point of making a distinction?

This becomes more obvious when it comes to tracking, classifying, and prioritizing risks and issues.  An issue may occur that affects a single user.  For example, a user is not able to access their email.  Is this more or less important than a risk that affects all users, such as our single point of failure above?  Again, the action is what is relevant here.  It is more important to track issues and risks in one list, so that they can be properly prioritized according to the action that must be taken.