How do you deal with assumptions and constraints and managing risks? Do you consider assumptions and constraints risks themselves or drivers of risks or not risks as all? Why or why not?
I know this is bit of a polling question without necessarily a "right" answer; however, I think a bit of inductive reasoning on this topic might be very beneficial to all of us.
Risk is the by-product of Assumptions and Constraints. The entire process of Risk Identification is the examination and review of what we assume is going to happen during the life of the project (Assumptions), and what are the limitations that could cause impact the project, either in execution or expected results (Constraints).
Here I differ with Mark - risk management (and more importantly, risk ID) is the PM's job.
An example - I am currently completing a large public works project. Installation of a portion of my work is dependent on the designer's (external vendor) hydraulic calculations being correct. We can't know if they're accurate until the system is installed and 'start-up' is begun. The Assumption is that the design calcs are correct. The Risk is that they aren't, and I'll have to do some re-work to accommodate for this change.
Constraints work much the same way. I have a Schedule Constraint dictated by the Grand Opening date of the facility. This is non-negotiable. This Constraint makes EVERYTHING upstream of completion a Risk for not being completed on time. A Budget Constraint also means I can't simply crash the project to avoid the risk.
Given this, in my Risk ID I have to review everything, Assumptions, Constraints, Schedules, Budgets, etc, and do my best to avoid or mitigate the Risks.
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:
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:
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.
I think this question makes a simple concept unnecessarily complex.
Assess risk. Assess any risk that you think might affect the project. Risk Management is Project Management for Adults
The definition of an assumption is a statement that you don't have enough evidence to conclusively prove. Isn't that also the definition of a risk? You're just looking at the problem through different lenses. (I'm drawing a blank on which of the big name risk management experts advocates treating every assumption as a risk; although I can't remember the source/citation, this practice is well supported.)
If a constraint has a known, fixed likelihood and a known, fixed impact on the project, then it is an issue, not a risk. If you aren't sure of the likelihood or the impact, then it is a risk.
Begin with a risk assessment; estimate the likelihood and potential impact of the assumption or constraint. If there is a risk arising from the assumption or constraint, manage the risk.
I look at assumptions and risks as two sides of the same coin, as every assumption carries with it the risk that it will fail to hold true throughout the lifespan of the project.
Constraints are a bit different, though you could view them as opportunities ("happy risks") if it turns out the constraint doesn't really exist.
Risks and assumptions are quite different. I like the following definition of a risk from the Risk Register User Guide -
What is a risk?
Before looking at risk management, we need to understand what a risk actually is. The PMBOK gives a good - “an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, or quality.”
When describing risks, we usually want to the cause, the affected area, and the consequences. Let’s look at an example risk given in the PMBOK - “due to the forecast of high winds in our area, there is a risk that the roof of the barn will blow off causing our cattle feed to be ruined and loss of our livestock”. Here we see the cause (high winds), the affected area (barn roof), and the consequences (loss of livestock).
Let’s look at another example, this one perhaps more familiar. “Due to ongoing support demands, there is a risk that the Senior Programmer will be shifted from the project, causing a delay in the schedule”. Here we see the risk cause (ongoing support), the affected area (the Senior Programmer) and the consequences (a delay in the schedule).
