What Are Project Assumptions? + How to Manage Them Effectively

All projects are built on assumptions, whether we like it or not. The only thing we can control is our attitude towards assumptions.

Are we aware of what assumptions we’re making?

Will we check to see whether or not they are correct?

If they remain uncertain, will we check in periodically to verify changes?

Good project managers perform all of these actions.

But, before you can manage assumptions, you first need to know what they are and what they’re not.

In this guide, we will cover:

• What assumptions are (in general),
• What project assumptions are,
• How project assumptions are different from project constraints and project risks,
• Different types of project assumptions, and
• How to manage project assumptions.

What are assumptions in general?

They say it’s rude to assume, but this isn’t always the case.

We make unrude assumptions all the time — assumptions that are essential to our everyday lives and that we couldn’t properly function and keep our sanity without!

In case you think this is an exaggeration, here are some examples to convince you otherwise:

• You go to bed assuming your alarm will wake you up on time for work in the morning (“on time” is also based on the assumption that your car will start!).
• You send your kid to the store with a list of groceries and enough cash to buy them because you assume that the prices of said groceries haven’t suddenly doubled in price. 

But, are you wrong to assume any of this? 

No!

You make these assumptions because you have no reason not to. If we questioned these assumptions at all times, we’d all be:

• Stocking up on food and supplies everyday in fear of the next pandemic or inflation, or
• Using roosters instead of alarm clocks to wake us up early in the morning (effective only under the assumption that roosters actually cock-a-doodle-do at daybreak, as they do in cartoons).

What are assumptions in project management?

It was important to first explain how we can’t function without everyday assumptions because project assumptions are basically the same thing as assumptions in general — only project related.

The definition of project assumptions in the Project Management Body of Knowledge (PMBOK® 7th Edition) explains them as “factors that are considered to be true, real, or certain, without proof or remonstration.”

In other words, project assumptions are things we assume will be the case when pitching, planning, and managing a project.

For example:

• We assume that the project will solve the problem it was designed to solve.
• We assume the project product is something people will want to buy.
• We assume that project team members will have access to equipment needed to accomplish their tasks.
• We assume that the office will not have electricity and/or Internet connection problems.

This list could go on. 

The key takeaway is that assumptions are necessary for project planning.You just have to be aware of which assumptions you’re making.

What project assumptions are not

Reading the definition of project assumptions in isolation makes it seem like assumptions are straightforward, but — in practice — they are often confused with other project management terminology, most notably:

• Project constraints, and
• Project risks.

To help you distinguish between assumptions, constraints, and risks, let’s look at the definition of each and see where the key differences lie.

Project assumptions vs project constraints

If you wanted to argue semantics, you could say that project constraints — time, budget, and scope — are just assumptions.

We assume that these limited resources (budget) will enable us to do the work (scope) necessary to create the final deliverable before the designated project deadline (time).

But project management isn’t a place for arguing semantics — clear boundaries must be drawn for both assumptions and constraints to be used in project planning and documentation without causing confusion.

Once again, we will default to PMBOK’s definition of project constraints, which describes them as “limiting factors that affect the execution of a project.”

It follows that the key difference between project assumptions and project constraints — as they are understood by the majority of the project management world — is that constraints define and impose project boundaries:

• Deadlines define how long you have to complete the project,
• Budgets define what resources you can use to complete the project, and
• Scope defines what the final deliverable is supposed to accomplish and look like.

Project assumptions, on the other hand, don’t define the project’s boundaries — regardless of whether they’re correct or incorrect.

For example, when you decide on a vendor, you’re making an assumption that they will be able to provide the things you need to keep the project moving. This is not an unreasonable assumption — the vendor wants your business (and they likely have a penalty clause for late deliveries in their contract).

But none of this guarantees that their deliveries will arrive on time. Whatever the reason — supply issues, price spikes, or the vendor closing shop — late deliveries will cause delays in your project schedule.

This, however, won’t necessarily affect your deadline — you’ll just have to find a way to get the project back on track.

Project assumptions vs project risks

We can define a project risk as anything that has the potential to impact a project, both in positive and — more often — negative ways.

These impacts could range from inconsequential to catastrophic (or fortunate, should the pendulum swing in the other direction). 

In extreme cases, the impact of a negative risk can be so severe that shutting the project down is the best response plan.

While still not synonymous with one another, project risks bear a much closer resemblance to project assumptions than project constraints do.

They’re both things that may or may not happen that can affect the project.

The main difference is in our attitude towards them:

• Negative risks are things we don’t want to happen,
• Positive risks are things that we’d like to happen (but that aren’t necessary), and
• Project assumptions are things that we need to happen (or be true).

How to communicate project assumptions

A lot of the time when we make assumptions, we don’t do it consciously.

You don’t actively think to yourself: “Hmmm, I’m sure electricity won’t go out at the office tomorrow. It’d be weird if that happened.” 

No, you just assume, subconsciously.

But, unlike regular assumptions, project assumptions have to be stated. Ideally, they should even be written.

This is because you don’t know that other stakeholders aren’t making different assumptions about the same thing.

Maybe the project sponsor and project manager assume that different features should be given the highest priority.

To make a plan based on different assumptions like this is to set the plan up for failure.

Therefore, it is crucial to identify and manage project assumptions.

We can borrow a lot from risk management to manage project assumptions.

But, before we can walk you through the steps needed for managing project assumptions, we have to talk about the different types of assumptions and how they can affect projects.

Types of assumptions

There are many assumption models out there, but in this guide, we’ll use (a part of) the assumptions model devised by Daniel Kies, professor emeritus at the College of DuPage, Illinois. 

While not made for project management specifically, this model is simple enough to convey everything you need to know to start systematically thinking about project assumptions.

Kies analyzes assumptions by asking whether or not they are:

• Supported, and
• Written.

Combining these 2 sets of descriptors leaves us with 4 possible combinations for each assumption:

• Warranted and explicit assumptions: This is how you want all your project assumptions to be — supported by evidence that lends credence to the assumption and documented. These assumptions can still be incorrect, but they’re less likely to cause problems than any other assumption type.
• Warranted and implicit assumptions: These assumptions are just as likely to be correct as the warranted, explicit ones, but can still cause issues due to their undocumented nature. Unwritten assumptions aren’t shared among project team members and stakeholders, so it can be tricky when, say, the project manager and project sponsor have conflicting unwritten assumptions.
• Unwarranted and explicit assumptions: These assumptions aren’t supported by any evidence. However, so long as the documentation is reviewed regularly, these assumptions don’t present a huge risk to projects as chances are someone will notice that the assumption is unsubstantiated and point it out.
• Unwarranted and implicit assumptions: This is the worst kind of assumption that can happen to a project — there’s no evidence to support it, yet it’s impossible for anyone to notice this and point it out.

How to manage project assumptions

To quote Neville Turbit: “[Assumptions] are typically documented at the start of the project and filed in a safe place. Aside from helping to pad out the project charter, they are usually ignored.”

It is best to manage project assumptions every step of the way, as you would with project risks.

As PMBOK apparently has nothing to say on this matter, we’ve analyzed the works of experts who have written on the topic of managing project assumptions — like Neville Turbit and John Kinser — and arranged their tips into the following steps:

1. Identify project assumptions
2. Analyze project assumptions
3. Assign ownership of project assumptions
4. Monitor project assumptions
5. Document for posterity

Step #1 — Identify project assumptions

First things first, you need to identify what assumptions you’re making.

In his paper Don’t make an ass out of you and me—using assumptions effectively, John Kinser stated that 4 of the 9 assumption identifying techniques from Assumption Based Planning (ABP) by James A. Dewar can be applied to project management, which he dubbed:

• Storytelling,
• Looking for “wills and musts”,
• Rationalizing the plan, and
• Asking the journalist’s questions.

Technique #1: Storytelling

To identify project assumptions through storytelling is to use descriptive language to paraphrase the objective statement from the project charter in as many words as you can.

For example, let’s say our project statement reads: “The goal of this project is to create a team communication tool for our company so that we can have direct control over our data.”

That’s a decent project statement — it’s got the what, the who, and the why.

But let’s see what assumptions are hidden in this statement by using storytelling:

“Our company is unsatisfied with the team communication tool it’s using, as the provider has recently been hacked, leaving our confidential data exposed. It now considers keeping internal communication data on 3rd party servers of any kind a risk no longer worth taking. We will develop a team communication tool that will offer higher security than anything available on the market.”

What assumptions can we glean from this?

The one that stands out the most is this: Our team communication tool will not use 3rd party servers.

This isn’t just an implicit assumption, but it’s probably unwarranted as well, given that even many tech giants like Twitter don’t use their own cloud servers.

Real-life examples will have more context to draw from for even more detailed descriptions.

Technique #2: Looking for “wills and musts”

Looking for “wills and musts” is meant to be understood quite literally. 

You go through all project documentation and search for all instances of the words “will” and “must”. You’ll be surprised by how frequently these words are used. You can use them to identify assumptions made while these documents were being written.

Technique #3: Rationalizing the plan

Sometimes, you’ll find that project documentation contains planned actions that don’t correlate to any explicit assumption. 

As Dewar says “planners do not usually plan useless actions. Figuring out why an unconnected action is being planned usually reveals an assumption about the future that has yet to be explicitly stated.”

To rationalize the plan is to go through documentation and look for these instances of planned actions that aren’t linked to any explicit project assumption.

Kinser does point out that, of the 4 methods for project assumption identification, this one is the most difficult, as it cannot be performed until the project has a comprehensive plan. Nevertheless, it’s worth taking a mental note of this strategy.

Technique #4: Asking the journalist’s questions

Lastly, you can ask the so-called journalist’s questions::

• What,
• When,
• Where,
• How,
• Who, and
• Why?

Dewar adds a slight twist to these questions by suggesting to cut out the sixth question — “why” — and instead compound it to the first 5 questions, so that you get:

• What are we going to do and why?
• When are we going to do it and why?

The same goes for where, how, and who.

Explaining the “why” for every question should bring some previously implicit assumptions to light.

Before we get any deeper into discussing step 2, we need to point out that assumption identification is not something you should only do once, at the start of the project. 

It’s a continuous and iterative process. As you update or write new documentation, make sure to check what new assumptions are being made.

Step #2 — Analyze project assumptions

Now then, whenever you identify an assumption, you should analyze it.

To do this, you can borrow from risk management.

In risk management, we rank each risk by: 

• How likely it is to happen, and 
• What the consequences of it happening would be.

When analyzing project assumptions, just flip the script:

• How likely is this assumption to not be true?
• What are the consequences of it not being true?

Analyzing assumptions like this will help you prioritize them, which you’ll have to do, given how many assumptions a lot of projects rest on.

Step #3 — Assign ownership of project assumptions

Because of the sheer number of project assumptions that proper assumption identification can uncover, it can be difficult for project managers to keep track of all of them.

That’s why, in many cases, project managers will assign ownership of project assumptions to project team members.

As mentioned, just because an assumption is warranted, doesn’t mean it’s true. Project members should periodically — ideally at predetermined intervals — check up on project assumptions to verify them. 

You often won’t be able to verify if an assumption is true as soon as it is identified, which is why returning to it several times to see if anything has changed as the project progresses can be beneficial.

Step #4 — Monitor project assumptions

The whole point of this entire process is to monitor project assumptions. Whether the project manager assigns ownership of project assumptions to project team members or not doesn’t change this.

As with all things nowadays, monitoring project assumptions is best done through software. Not all project management tools have dedicated assumption management features, but if you use a customizable platform like Plaky, you’ll be able to do this effortlessly.

In Plaky, users can create an unlimited number of custom boards and tweak the appearance of each one by adding relevant fields.

In the picture below, we can see how a Plaky board can be made to give you a clear visual state of project assumption tracking by showing:

• The name of the assumption (you don’t have to use numbers),
• Whether or not it’s been verified,
• The likelihood of it not being true,
• The consequences it can have on the project if not true,
• Who the assumption owner is, and
• When they are scheduled to perform the next assumption verification check-up.

Step #5 — Document for posterity

Last, but not least, make sure to document the assumption management process throughout.

Once again, we can look to risk management to glean some ideas, such as creating an assumptions log — a document that will contain a list of all project assumptions identified in every project organized by the company.

The log shouldn’t merely be a bulleted list of project assumptions, but instead, it should cover each entry in detail.

Sometimes, assumptions may only become clear when conducting the post-implementation review (PIR), also known as the project post-mortem.

This log can be used to facilitate assumption identification and tracking in future projects.

Conclusion: Don’t avoid assumptions, analyze them

Assumptions in project management are not something that can be avoided — turning a blind eye to them can only make things worse.

To increase the chances of project success, you should try to maximize the number of warranted, explicit assumptions.

This is done by identifying, analyzing, and monitoring them, ideally through a project management platform that can support assumption management, like Plaky.

What experiences have you had with project assumptions? And is there anything we’ve missed in this guide? Share your thoughts by contacting us at blogfeedback@plaky.com, and we may include your answers in this or future posts. If you liked this blog post and found it useful, share it with someone you think would also benefit from it.