Known Unknowns: A List of Common Project Assumptions (& What to Do About Them!)

Known Unknowns: A List of Common Project Assumptions (& What to Do About Them!)

“We should have known.” It’s such a common phrase to hear when reflecting on a project that’s gone over budget or schedule. Whether it’s materials arriving late, employees quitting, or prices soaring, so often a project goes off the rails because of something that might have been prevented.

In the eager anticipation to get a project underway, it’s common to rush through the planning stage, and then have things go haywire due to unexplored, implicit assumptions.

Just what are assumptions and how does a project manager avoid them? While they’re similar to constraints, they’re more akin to risks than anything else. And addressing them is key to success in any project. Let’s look into assumptions with some common examples, and consider how to address them in project management.

Definition of Assumptions

We make assumptions all the time. In order to get to the office and put in a productive day of work, we assume that the alarm will go off, the car will start and the drive through at Starbucks will be open. Although assumptions oftentimes do not have proof or documentation, generally they’re considered to be reasonable expectations. For example, assuming that a facility will have electricity is almost always a safe assumption.

The project management glossary defines assumptions as: “factors deemed to be true during the project planning process, though proof of their validity is not available. A project’s assumptions can affect its risks and outcomes, so you must consider them carefully.”

Two assumptions that most projects hinge on are the availability of necessary resources and the adequate skill level of employees to complete the deliverable. If these assumptions turn out to be false, the project requires considerable replanning.

Assumptions can be either explicit or implicit. An implicit assumption is taken to be true without proof or demonstration. For example, say an organization uses a certain communication tool for all internal communications. The project manager assumes that this same tool will be used within a given project, without really thinking about it. Every project entails a host of implicit assumptions like this one. If the project manager took the time to look into them all, the project would never get off the ground.

An explicit assumption has been singled out and identified as an uncertainty. While many implicit assumptions should become explicit, making the distinction requires reason and judgment. It means identifying the likelihood and impact of an assumption being false.

For example, say you’re planning a pool party for a spring day. The planning requires many assumptions. You assume that the caterers will arrive on time, the weather will be warm enough for guests to mingle outside and the electricity in your home stays on throughout the party. While some of these assumptions may need to become explicit, others are implicit and don’t require special attention.

An assumption, really, is nearly synonymous with a risk. And so oftentimes assumptions require research and affirmation in order to mitigate the risk of making an incorrect assumption before it’s too late. With the party, you’d probably look at the weather forecast in order to determine if the party can proceed as planned.

It takes some digging to determine whether or not assumptions are accurate. After this research is completed, assumptions either become facts or risks. And those that are risks are incorporated into the project’s risk management plan.

A thorough project manager takes the time to document assumptions. This provides a historical record and is helpful when planning similar projects. Later, we’ll discuss more about the details and benefits of an assumption log.

Assumptions vs. Constraints vs. Risks

Assumptions are often conflated with constraints and risks. And while the three concepts do overlap, each is a distinct component of project management. Let’s briefly define both constraints and risks, and explain how they compare to assumptions.

A constraint, according to the project management glossary, “is a limitation on a project. Among other things, constraints may be financial or based on time or resource availability.”

In the same way that a play pin creates boundaries for a baby and a fence for grazing sheep, constraints create boundaries for a project. These constraints may be either internal or external and include things like regulations, industry standards, a timeline, budget and resources limitations. A resource constraint might be that a certain material isn’t available in the area or during a certain season, or that employees don’t have the skills to use a certain software.

Project management often talks of the triple constraints of a project, which includes scope, timeline and budget (or the quadruple constraints which adds quality to the mix).

Constraints, unlike assumptions, aren’t uncertainties. Rather, they’re givens. While a constraint might be that the budget cannot exceed 10%, an assumption might be that the cost of supplies will remain constant through a project’s duration.

A risk, as defined by the project management glossary, “is the probability of occurrence of a specific event that affects the pursuit of objectives. Risks are not negative by definition. In project management, opportunities are also considered risks.”

A simpler way to define risk is to say that they are uncertainties that matter. An example of a positive risk might be that a project takes much less time to complete than anticipated, or that the price of materials decreases.

Generally, an assumption is a low level risk. An explicit assumption that’s been researched may have little to no risk. However, implicit assumptions may be high-level risks that have been swept under the carpet and ignored.

Risks generally require a management plan, while assumptions (when defined as low level risk) are scenarios where, though not ideal, a project can proceed nonetheless. For example, a risk might be that key employees quit mid-way through a project (this would require a succession plan). However, an assumption might be that all employees will arrive at work each day at 8 am. Even if this assumption proves untrue, and some arrive closer to 10, it probably wouldn’t throw off the entire project.

As you can see, constraints, risks and assumptions are distinct, which is why each is treated separately in project planning. Many of the preliminary project documents such as the business requirements document include a list of explicit assumptions, alongside constraints and risks.

Now let’s consider some strategies for handling assumptions in a project.

An Assumptions Strategy

While many implicit assumptions are low-level risks that don’t require a lot of attention, sometimes the opposite is true. Many assumptions are high-level risks that, if overlooked, can spell disaster to a project. And so assumptions need to be identified, researched and possibly resolved before executing on a project. Using an example, let’s consider four steps to tackling assumptions in a project.

Let’s consider the project of a homeowner building a carport to protect a car from winter snow. The project plans to execute in August and needs to be completed before the first snowfall, which usually is in December. The principal resources required are wood, a plastic tarp, gravel, a backhoe and a carpenter. The project cannot exceed $1,500.

1. Identify Assumptions

The first step in a project is to capture assumptions. This entails scrutinizing the process and the requirements of the final deliverable in order to identify areas that don’t sound quite right.

In the example above, some of the key assumptions are the availability of a carpenter, a backhoe and materials. It also assumes that all these resources will be available at a price that keeps the project under $1,500. It assumes that the carpenter is sufficiently skilled to build a carport that will stand up to winter snow, and that a plastic tarp is sufficiently sturdy to withstand the weight of snow. A final assumption is that the first snowfall occurs in December and not earlier.

2. Check Assumptions

The next step is to look into all of the key assumptions. Are they reasonable? What evidence supports them?

In the example of building the carport, research requires visiting places like Home Depot to determine the cost of materials. It requires reaching out to local carpenters to determine their availability, and inspecting their past work to determine if their skills are adequate.

3. Consider Alternatives

After the research on explicit assumptions is completed, it’s possible that a project looks a whole lot different. Perhaps the scope, timeline, or budget needs to be reconsidered. Perhaps one of the assumptions introduces a lot of risk and should be averted or the initial conceit isn’t feasible at all.

In the example above, some digging might reveal that in order to build a sturdy, long lasting carport, the cost of resources would be twice the initial budget, plus the ideal carpenter wouldn’t be available until November. This would mean reconsidering both the timeline and the budget of the project.

4. Keep an Assumptions Log

An assumptions log is a final step to successfully addressing assumptions. This is a written record of all the explicit assumptions in a project alongside a description and status update.

A thorough assumptions log states the assumption, assigns it a category (clarifying if it impacts the budget, scope, timeline or deliverable), and provides a brief description. Then it rates the assumption according to its probability of being false and the impact if it is false. Finally, it states the status of the assumption. Has it been dealt with? Or is it still “open” and in need of time and attention?

In the instance of the carport, the log would list all of the assumptions mentioned above, alongside any research that’s gathered.

This log provides a valuable overview of the entire project. It highlights those areas that need the most attention, and key risks that need to be mitigated. The assumption log, really, serves as a framework to a risk management plan.

These four steps provide a simple method for tracking project assumptions. Now let’s turn to a list of common assumptions that a project faces.

A List of 7 Common Assumptions

Assumptions fall into various categories, either explicit or implicit, serious or negligible. And they impact different constraints, including the cost, scope and timeline. The impact of an assumption and its likelihood of being false determines whether or not it needs to be addressed.

But just what do assumptions look like specifically? Assumptions vary depending on the project, be it construction, software, or interior design. But a few common assumptions apply across the board. Let’s go over a variety of assumptions along with some guidelines around how to address it.

1. Availability of Equipment, Labor and Materials

One of the most common assumptions in any project is that resources will be available when needed. If they aren’t, the project inevitably is delayed and may well go over budget.

Generally, this assumption requires research. First, it means identifying the final deliverable and all its requirements, and clarifying all the resources required to complete it. From there, it requires reaching out to identify where the materials can be obtained, be they equipment, labor, materials, or even something else like additional office space for contingent employees.

2. Weather

Weather hugely impacts many types of projects, including event planning and construction. Since weather is unpredictable, it’s necessary to consider the impact of, say, assuming sunny weather during an outdoor event. Would it be necessary to take measures should a rainstorm or hail storm occur instead?

The solution to mitigating this assumption may be to put up a canopy, or hold the event indoors instead. Or the project can be postponed and strategically executed during a window when the likelihood of suitable weather is high.

3. Permit Approval

Many projects require permits. A restaurant requires a liquor license, and construction requires permits for plumbing and electrical and structural changes. One common assumption is that permits will be acquired in a timely manner, with no hang ups or complications.

Validating this assumption may entail researching similar processes on previous projects, or talking with people who’ve obtained the same permits, in order to understand the process and so avert delays.

4. Skill Level of Employees

It’s easy to assume a person is capable of work that he or she isn’t skilled in. Maybe a carpenter has a dozen years of experience, but has never built a deck before, or a software developer is only proficient in a few languages. Addressing this assumption first requires a thorough understanding of the deliverable and the skills required to produce it. Then it means correlating work to persons with those skills.

5. The Proficiency of Software

The execution of a project usually hinges on the usability of several softwares. This may include one software to hold remote meetings and another to do the bookkeeping. One common assumption is that the software can achieve its necessary end. Does a video conference platform really allow a remote team to communicate effectively, for example?

Identifying the risk of this assumption may require researching the software before implementing it, or else trial runs with various softwares.

6. Price of Materials

A carefully plotted budget hinges on the price of labor, materials, equipment and other resources. And oftentimes it assumes that this price is stable. One way to mitigate risk of this assumption being incorrect is to lock in a price with a contract. Another way is to research the market and the historical prices to understand how prices may be expected to fluctuate.

7. Budget Tolerance

Most clients have a cap on the permissible leeway in the budget. For example, it may be acceptable if a $2,000 budget hits $2,200 but anything above that is a big no-no. Assuming that a tolerance is at 20% when really it’s only 10% is a sure way to displease the client. Getting a clear picture of the budget tolerance during the planning stage averts the risk of this assumption.