Do you consider assumptions and constraints risks themselves or drivers of risks or not risks as all?
Assumptions carry risk, but a priori assumptions are not really the domain of risk management applied to the project management field. Risks are project variables to be managed; assumptions, on the other hand, are foundational expectations which may invalidate a project or plan if they do not hold true.
A risk is something that falls into one of two categories:
- Quantitative risk, which can be measured and (often) assigned a dollar value.
- Qualitative risk, which is more subjective and largely based on interpretive assessments of threats and consequences.
Generally speaking, a risk is something that you can control, transfer, or accept. Risks don't inherently invalidate a plan or project; they are simply variables that may impact the project's budget, schedule, or level of success, and should be managed accordingly.
While an assumption carries risk (e.g. that the assumption will not prove true), the use case is different. An assumption is an a priori input into the planning process, in order to allow the project planning process to proceed. In general, I find that assumptions are best used as contracting or scoping tools, and carefully spelled out in the most explicit way possible.
As an example, a contract to deliver widgets might include some necessary planning assumptions such as:
- Widget goo is readily available to the project as a resource.
- The widget stamper is not part of the widget-project budget.
- The organization has the necessary expertise to build widgets.
If any of the assumptions are false, then the project goals, deliverables, budget, and schedule may need to be reassessed. Unlike a typical project risk, an assumption is a driver for the planning process and a stated expectation, rather than something that can be controlled for within the plan. For example, if widget goo is no longer available anywhere in the world for any price, any plan that assumes the existence of widget goo would no longer be viable.
In my experience, failed assumptions require a big "reset button" rather than process slack or additional variance controls. Another way of looking at it is that an assumption, unlike a risk, can invalidate a project plan.
Consider this (admittedly contrived) example: Your project assumes that Earth is an airless moon, and the project can't succeed when performed on a planet with an atmosphere even with the aid of vacuum chambers or other technical controls. The fact that Earth has an atmosphere isn't a risk that you can control, transfer, or accept in a meaningful way because the failed assumption violates the project's foundational expectations; it places the whole premise of the project into question.
That's what a project management assumption is: something so basic to the premise of the project that, if it doesn't hold up, the project as a whole should be reviewed for viability.