There are a few things involved in managing project risk:
1. Define Risk
The difference between a "risk" and an "issue" is as follows:
a) Issue - A problem that you as the PM cannot do anything about but somebody else (your boss perhaps) can do something about. Therefore, issues should be logged and escalated to the person who can address or eliminate them.
b) Risk - A potential problem that nobody can do anything about. A risk, by definition, is just there. You can't remove it. If you could, it would be an issue. But you must think about the risk and prepare for it in case it occurs.
2. Log the Risk
Just as a PM would keep an Issues Log, you must keep a Risk Log. Record all of the risks that you and your team can think of.
3. Prioritize the Risks
Prioritizing risks involves analyzing two things:
a. How likely is the risk to happen?
b. To what extent would the risk adversely affect the project if it occurred?
If you establish a scale of 1 to 100 in terms of adversity (1 being almost no effect; 100 being an utter disaster) and establish the probability of the risk somewhere between 0% and 100%, you can produce a risk index or score. For example, if the risk would score 70 on the "adverse effect" scale but it only has a 10% chance of happening, that risk would score 7 (10% of 70). If another risk scored 40 on the "adverse effect" scale and had a 50% chance of happening, that risk would score 20 (50% of 40). Even though 70 is worse than 40, the lower probability means that it would likely be a waste of time to spend much time and attention on something that is so unlikely to happen.
4. Develop a Risk Mitigation Plan
After you have logged and prioritized your risks, you must develop a Risk Mitigation Plan for each risk in accordance with its effect and probability. In other words, a risk with a high score would demand you and/or your team to spend some time thinking through and documenting a plan to mitigate the risk whereas a risk with a low score may only require a cursory thought of what you would need to do if the risk were to occur.
5. Execute the Risk Mitigation Plan (if necessary)
Remember, by definition, risks cannot be eliminated; they can only be mitigated. Therefore, a risk with a high score may require you to execute your risk mitigation plan for that risk (as opposed to just having a plan waiting in the wings "just in case").
6. Monitor and Manage the Risk Log and Risk Mitigation Plans
It is easy to forget about project risks for at least two reasons: a) you will have other more pressing concerns; b) the risks may never happen. However, it is a good practice to review the Risk Log on a regular basis (perhaps every week) and refine it (add, change or delete items on the Risk Log). It may be appropriate to deputize one of your junior project team members as the "Keeper of the Risk Log" so that you won't forget to review and manage it.
The Risk Log looks very similar to an Issues Log. I include the following columns in my Risk Logs (which I keep on MS Excel or MS Word):
1. Risk ID Number
2. Risk Name
3. Risk Description (include the potential adverse effects)
4. Date (the date you put it on the log)
5. Identifier (the name of the person who identified it)
6. Probability (in terms of a percentage)
7. Adverse Effect (in terms of a numeric scale; usually 1-10 or 1-100)
8. Risk Score (Probability x Adverse Effect)
9. Mitigating Action (list the actions that you are taking now or will take in the event that the risk occurs)
8. Other Comments
Good luck.