Assumptions

Much of what we do at work and indeed in our personal life is based on assumptions.  Assumptions are defined by the PMBOK Guide as

“factors that, for planning purposes, are considered to be true, real, or certain without proof or demonstration.”

In other words assumptions are effectively beliefs that we know to be true but are unable to prove.  The challenge that we encounter on projects is not understanding the working definition of assumptions but rather ignoring it.  We intuitively understand what assumptions are but when it comes to planning we often don’t understand how to apply them.

In my training workshops I tell the participants if we know that something is actually untrue we simply can not build an assumption that it is true.  Alternatively, if we want to achieve a certain objective or we “hope” to have some stakeholder’s support we can not simply assume that the support will materialize.

One of my favorite poor assumptions set by project teams is something like:

“we assume that management will support the project”

or

“we assume that the project has executive support”

These are not effective in terms of setting assumptions because it is imperative for the project manager and the team to find out if there is management support or if they need to go build management support.  Creating a plan and executing a project with the hope that management will support it is a recipe for disaster.  Let me illustrate what I mean by this very powerful quote by Miguel Angel Ruiz that applies to assumptions on projects:

“Don’t Make Assumptions. Find the courage to ask questions and to express what you really want. Communicate with others as clearly as you can to avoid misunderstandings, sadness and drama. With just this one agreement, you can completely transform your life.”

The point here is that we do not want to confuse the role of planning with making assumptions because we are lazy as far as getting to the bottom of hard questions that are inputs to our plan.

Another important point to keep in mind also is that if there are issues or decisions that we know to be true, we can not assume otherwise.  For example, if we know that the organization has set a budget of $500K for a project we can not assume that the project budget will increase once execution starts.

We also do not want to confuse assumptions with constraints.  Contraints are factors that bound the scope, cost, and time of the project.  As such, they are very different from assumptions.  Assumptions on the other hand are a major source of risk on the project.  Since we can not prove for a fact that an item exists, then there is a risk that our belief is inaccurate.

One of the most important elements in dealing with assumptions is a recognition that the project manager must continually evaluate whether project conditions have resulted in assumptions materializing or becoming irrelevant.  Throughout the project lifecycle there will be events that will either prove assumptions to be wrong or will reinforce our belief.  Once these events take place an assessment must be conducted to determine the impact of the project.

As I said the concept of assumptions makes sense on paper but is likely a lot more complex in terms of practice.  This is where experience and lessons learned become invaluable to enhance project team performance and chances for success.