I hate issues! Issues are risks that have materialized. A risk is something that might go wrong, while an Issue is something then has already gone wrong and is impacting the project result. Time, Cost, Scope, Quality.. even morale. Risks are good, Issues are bad.
I am terrified of Dependencies! A dependency is a connection between your project and a factor that you do not have control over. A typical excample is being dependant on a deliverable from another project to be able to move on. A dependency is a risk, just like any other risk. It can (and should) have mitigation plans, and should be monitored on regular basis. The difference is that dependencies are tightly related to people and communication, or lack thereof. You’ll typically have good visibility within your own project, but how confident are you that you are getting the necessary information (in a timely manner) from another project?
Communication is usually not a problem when things are going well. Weekly status updates, and ad-hoc synchronization could be sufficient. But what about crunch time? Go-live in a week, multiple critical defects, last minute decisions with impact to both time and deliverables… How likely do you think it is that the Project Manager will pick up the phone just to chat about the change of plan? I wouldn’t put a lot of money on it. This is natural. He has other priorities than you. And he might not even understand (or remember) to what extent he is impacting you. But even if he does give you a call, and let you know that unfortunately he’ll be a few weeks late - your risk has materialized, and turned into an Issue.
Let me summarize: Risks are good. Issues are bad, Dependencies are damn scary.
So what to do? Create a risk log! Lots of fancy tools out there, but excel works just fine. Give each risk a unique number, a simple name and a short description so it’s understandable for someone external to the project (and so you don’t look stupid when asked what it’s about).
Then estimate the likelihood of it occurring (0-100%) and the impact if it should occur. 0-100 is fine here as well. We could get into lengthy discussions on how to classify and measure impact, but I find that simple is better. No impact = 0, project failure = 100, and anything else falls somewhere in between. Multiply the two and you get your risk grade.
Example: If a risk occurring will cause a 2 week delay on a task that is not on critical path, I’d give it an impact of 50%. Let’s assume it has a 70% chance of occurring – you risk grade would be 50%*70% = 35%
Do this to all your risks, sort them by risk grade, and you have your very own prioritized risk list. Now work through your risk list starting from the top. Give a short description of the potential impact. Don’t overdo it, but don’t sugarcoat it either. The next one is optional, but I like to include a trigger description, stating what will turn it into an issue (e.g. Business Requirements not delivered by end of month).
Finally you need to come up with one or more mitigation plans. These should be formulated as proactive action plans that you or your team will execute to avoid a risk from turning into an issue. And this is important. You need to execute your mitigations before the risk becomes an issue. If it’s already an issue you are already being impacted. Depending on the risk grade I try to have at least a few mitigations for each risk. For the risk of business requirements being delivered to late, a few potential mitigations could be:
- Make sure project X understands the impact of a delay (over communicate), and secure frequent status updates.
- Re-plan project tasks to reduce impact of late delivery. (Is there something else we can do first?)
- Work with early draft or assumptions until final version is available
- Ask management to add more resource to speed up project X’s delivery
And now for the fun part: Start executing your mitigations. Again, use common sense. Depending on your experience and sense of empowerment, you should probably not go running to management unless it has a high risk grade. Start with the things you can easily do yourself without wasting too much resource. Most of the time this will eliminate the risk, and you will be a hero for running issue free projects.
But if the risk grade keeps increasing, escalate to a steering group or a sponsor, by stating what the risk is, and what you have done so far to mitigate it. Follow up with your recommendations, and the impact of not doing anything. This will give whoever is in charge enough information to make informed decisions, and if you bring it up before it turns into an issue you will most likely get the help needed to make it go away, or at least get a free pass out of jail.
On my weekly status update I always include my top three risks, and a one liner describing what I am doing to mitigate it. This is primarily to keep everyone informed, and is a good talking point when discussing your project. “The project is going well, and we are mitigating the following key risks…” I try to plan escalations for regular steering group meetings, but have sometimes had to call extraordinary meetings when I need help.
Go ahead, make a risk list, and start executing your mitigations. It will probably feel like a time consuming activity, but once you get used to it, it’s fairly simple to keep up to date. Do this for a while and you will start reaping the rewards… and I bet in a month or two you will surly agree that risks are great and issues are bad…
Good luck!
