Project Assumptions should not be taken lightly. Or, the importance of identifying and documenting Project Assumptions being critical for project success. Assumptions are in everyone’s head. The individual(s) writing the business case, Scope, Project Plan, WBS, and Estimates, are making assumptions about how the project will play out. Most don’t get documented.
Table of Contents
An assumption definition according to PMBoK 6th Edition: A factor in the planning process that is considered to be true, real, or certain, without proof or demonstration.
An assumption Log is defined, according to PMBoK 6th Edition: A project document used to record all assumptions and constraints throughout the project life cycle.
Assumptions establish the project environment, make decisions, and provide a basis for estimating and planning the project.
Sometimes an assumption is presented as a known fact and isn’t always documented. For example: “This much work will require 2 people for a month.” Another example: “The is the south humidity is always high in the summer. So, of course, we will plan accordingly.” This is the best-case scenario when we have received at least some articulation that points to or refers to underlying thinking.
The problem with making assumptions is that we believe they are the truth. We could swear they are real. ~ Miguel Ruiz
When somebody asks us questions, our responses can have a bunch of unarticulated supporting matter that went into our response. This may not seem like there is something more there, sort of like an iceberg. That articulated is not the entire picture. If the answer is the only thing that matters, perhaps the answer to the question is enough. However, when it comes to projects and project management,
What we know, is the result of every action we have ever taken, every experience, formal learning, informal learning, and many other things. All of this will be part of our answer. Some of these experiences are relevant and helpful, and some, perhaps not at all. To pour over this background information will take time, and perhaps the person we are talking with will lose interest – get to the point sort of thing. However, if we do not ask questions, we will never know what goes into the answer we are receiving. Even if we ask good questions, the answers we are told, or that what we hear, are not necessarily true.
Our brains are pattern detecting machines. They detect patterns, even where there is not a pattern, that is how good they are. These experiences will lead us to conclusions based upon patterns we have witnessed. However, these things below the surface, for the sake of brevity, may forsake. My brother, Shawn P Quigley is fond of saying, seek first to understand. This requires hearing what is said, followed by probing questions to truly know what is being said. This is communication.
The single biggest problem in communication is the illusion that it has taken place. –George Bernard Shaw
We spend a great deal of time writing on communications for PMTips, because a project manager, no matter the industry or scope of the project, will be required to spend a significant amount of effort into communicating. This is not just what is said, but also what is not said but we need to know to understand the risks associated with the subject matter.
Rarely have I witnessed assumptions turn into facts. ~ Sonya Teclai TheGoodVibe.Co
Applicable areas
- Budget
- Methodology
- Resources
- Schedule
- Scope
These are very basic areas and in alphabetic order not in order of importance. A particular project may have other Areas, or these Areas may have sub-categories.
Clarifying Assumptions is where critical thinking comes into plan. The project manager should clarify the assumptions when as presented. Be attentive to the Assumptions and the individual supplying it. Do not aggressively challenge or belittle anyone about their Assumptions. Ask questions, clarify the Who, What, When, Where, Why, & How.
For life in general, and project managers and project management, we should keep in mind Kipling’s six honest men. Whatever you hear, ask questions about it, seek to understand what is conveyed not just your interpretation of what they are saying. By way of another example, when I go out to eat with my family, I ask for sweet iced tea. My family says you live in the south, you will get sweet, iced, black tea. I tell them, if I do not specify the way I do, they could give me green hot tea, an absolute failure for me, and they will have met what was verbalized.
“I keep six honest serving-men (They taught me all I knew); Their names are What and Why and When And How And Where and Who.” ―Rudyard Kipling
Listed here are some types of questions to ask:
- What makes you say that?
- When did this happen?
- How do you know that?
- What leads you to that conclusion?
- How can we find further?
- What data do we have to support that?
- What do we have to refute that?
- What is your supporting information?
- Where did this happen?
- Contingent upon what?
- Depending upon what?
Clarifying the Assumptions may identify some as RISKS. For example, in developing an estimate of hours and schedule. The estimator may estimate a particular deliverable requires 320 hours to complete and assumes two people will be assigned to execute this work. The potential RISK is that only one person is available to execute the work at the beginning or to do the entire deliverable. The impact is in scheduling. Depending on the people available, this work could be 4 weeks or up to 8 weeks.
Just remember there are no bad or good assumptions. We will not know the veracity of the assumption, unless we look for supporting, or more importantly, refuting information. We must take care not to go from an assumption problem to a confirmation bias problem. That is why we keep an assumption log. After the assumptions are logged these are assigned to someone to validate them. Any assumptions that don’t apply can be noted as such.
Assumption log
We document the assumptions, so we know what has gone into that which we are basing the project. We will look for clues to see if these underlying thoughts are valid. We can wait to find evidence, or we can proactively set up experiments to ascertain the validity of the assumptions.
Assumptions are not all equal, some that are incorrect will not have much damage, and others if incorrect will cause great damage. The ones that can cause severe damage if not effectively vetted, will be prioritized for work. We will look for metrics that will tell us if we are correct. We may have to devise experiments to explore and come to the appropriate conclusion.
The Assumption Log informs the project team and stakeholders what was the basis for a particular approach or action. The Assumption Log should contain a “STATUS” column. This is where the result of the validation is recorded. The following are examples of possible STATUS:
- True and will remain as stated
- True if “X” occurs
- No longer true and will be removed
- Not true because of “X”
- Moved to the RISK Log
Developing business cases and project plans for future projects will benefit from having the Assumption Log from similar previously delivered projects. It will tell others why a particular approach was taken and what was the basis for initial estimates.
In years past Assumptions, Risks, and Issues have not had the focus that they should early in the project. Project Managers today are seeing the value identification and management of them brings a great chance of project success. Assumptions create the project environment conditions and why we are doing what we are doing to deliver the project. Assumptions will also drive out Risks not previously considered. Issues sometimes come from assumptions during execution. Even an assumption validated as true can create an issue as stakeholders change or other influences (economic, government, organization changes, etc.) outside our immediate control.
Please reach out to us if we can answer questions.