In the forums I’ve been participating on recently, I’ve seen an awful lot of questions regarding the above terms. It seems there’s a lot of ambiguity around these points. Today I’m going to throw my two cents out regarding the differences. Ultimately, I believe they’re different steps along the same continuum, which is probably why there’s so much splitting of hairs regarding which is which.
On the surface, the response is simple:
- An assumption is anything you “assume” to be true.
- A risk is anything that could go wrong.
- An issue is anything that has gone wrong.
However, I just finished having a 30 minute argument with my partner while discussing this post (and I’m likely sleeping on the couch tonight). It indicated to me that on the surface the definition of these three items seems very simple, but the relationship between the three has a fair bit of complexity beneath the surface.
Assumptions
A lot of people don’t like these, and will always quote Samuel L. Jackson from The Long Kiss Goodnight (I love that movie) by saying, “When you make an assumption, you make an ass out of you and mption”. However, the reality is, nobody has all the answers. If they did, there would be no need for us project manager schmoes at all because everybody would automatically know what everyone else was doing. We’d be out of work!
When you go into a project, there are certain points you have to accept as given to be able to make certain decisions, even without all the facts. It’s true, those assumptions may later prove to be false, but if you’re too afraid to make them, you’ll be paralyzed. The effective manager picks up a stake, drives it into the middle of the boardroom table saying, “we’re going to assume X until it looks like we’ll be proven otherwise”, and everyone else at the table cowers away from the shining beacon of holy light that is the PM. (Okay well that never happens to me…I’m having a good day when my shirt tail isn’t sticking out of my fly, but you get the idea.)
As to what an assumption is, it’s any unsupported statement that people believe to be true. Period. Assumptions have no good or bad, they just are.
Risks
Like assumptions, risks are theoretical. They haven’t happened. However, risks have very specific properties that should be noted. First of all, a risk has consequences attached to it. These are usually phrased as “something bad”. If you’re going to consider “something bad”, then you need to think of how likely that bad thing is to happen, and how bad it would be for you if it did happen (impact).
Because I’ll be criticized later by all the smarter-than-me folks with PMPs and stuff, I should point out that the opposite of a risk is an opportunity. Opportunities have the same properties as risks, but you can replace “something bad” with “something good”. Just like risks, opportunities need to be called out for what they are if you’re to take advantage of them, and plans put in place to make the most of them.
From a definition perspective, a risk is something bad you think could happen, measured by likelihood and impact.
But a risk is also the antithesis (not the opposite) of an assumption. If you make an assumption that something is safe, there is always a risk that it is not safe. That’s because the underlying assumption, by definition, is unsupported by facts. Here’s where we start to run into confusion.
If you proceed with a course of action knowing that a risk exists, you are making an assumption that it’s safe enough to proceed anyway. Whether you call the assumption out for what it is doesn’t change the fact that you made it. As stated above, assumptions are necessary to make decisions; risks need to be identified to protect yourself.
Issues
Issues are not theoretical. They’re full-on happening and in progress. Once they’ve cropped up, issues have a tendency to continue to get worse until they’re dealt with (snowball), so your approach to them needs to be completely different from managing risk.
In an ideal world, you would have worked out your approach to issues beforehand during risk analysis; in practice, issues come out of the woodwork to bite you in the ass.
By definition, an issue is a bad thing that has happened. It needs to be dealt with. Again, here’s where the confusion lies…
If you identified the issue as the consequence of a risk, then good for you, you have a strategy to deal with the issue and get rid of it quickly. However, if you didn’t identify the issue as a risk consequence, that doesn’t change the fact that the risk existed, whether you thought about it or not.
From a functional perspective, you need to identify assumptions and risks at the onset of the project. As the project progresses, you need to continue to challenge your assumptions and risks. Issues, on the other hand, because they’ve graduated to actual, need to be handled tactically. That means, get people working on a resolution as quickly as you can.
Ultimately, the reason (as I see it) that there is confusion among the three terms, is because they are all directly related to one another, but that relationship is often only recognized in hindsight. It would be super great to have a time machine to go back and prevent problems, but for us humans, all we can hope to do is the best we can.
