Project Assumptions: A Complete Guide

What happens when you are putting together your project plan and you don’t have all the answers?

One way to deal with that is to use assumptions: an educated guess. An assumption is a way to simplify or otherwise fill in missing pieces of a project.

Those gaps happen for a variety of reasons, and many often exist before a project begins. Perhaps some information or details are either only partially available or just not fully defined yet. It’s normal to begin a project without absolute certainty because the organization expects some progress to be made.

You assume that the information will be available when it’s needed, or you’re simply using common sense to draw a conclusion about the most likely situation. But just because it’s obvious to you, doesn’t mean it’s obvious to anyone else.

And that’s why we talk about and document assumptions.

Understanding the key project assumptions is also helpful for documenting the project scope in a proposal or for a contract.

In this article, we will discuss the different types of assumptions, their links to other parts of the project, the real reason why you need to have them documented, and how to manage them during the project lifecycle.

Common assumptions

Here are a few categories of common assumptions and how they may impact your projects.

Financial/Budget

Sample assumptions:

• Currency conversions rates will stay the same throughout the project
• Resource costs will stay the same throughout the project
• There will be no contractual billing rate changes throughout the project
• Costs for materials will increase at 3% per year

Currency fluctuation can impact the project budget and margin. To mitigate this, you can assume a fixed currency conversion rate for the duration of the project. The rate to use for conversion may be determined at a business unit level instead of at a project level, although maybe project-level might be appropriate.

If you’re working on a project that involves multiple entities in different countries, you will likely also have a financial contact who will provide additional support on this.

Changes in the cost of resources, cost escalation, and changes in contractual billing rates can also have a similar impact on the project’s financial status. This becomes more important for multi-year projects where escalation and changes in contract rates are more likely to occur.

You can manage this by assuming that resource costs will be constant, and that price escalation will not occur. However, by doing that we are essentially reducing the project’s profit margin every year that cost increases occur.

Alternatively, assume a certain percentage of annual escalation (for example 3% – 5%) and account for that in the overall project price.

Resources

Examples of assumptions:

• Resources are available to be assigned to all tasks
• Customers will be available to attend quarterly demos
• The client will be able to attend a site visit during the first week of every month
• Environmental conditions will be appropriate for the time of year so resources can access the site as planned

Resource availability assumptions could refer to internal or external human resources needed during the project.

Internally we might assume that a project is supported and resources will be available and assigned to do the work. Or that resource allocation will happen in a timely manner and line managers will tell us who is assigned to a task.

Externally, resource availability is also important, especially when customers are involved. Customers will likely need to be part of regular discussions like weekly, monthly, and quarterly meetings and communication.

You will also need to have certain team members and key stakeholders present at milestone meetings and project review meetings to make effective decisions. To mitigate this need, you can assume that all required resources will be available for key project meetings.

Note: It’s equally important to document the impact on meetings and/or milestones associated with lack of customer availability. This gives traceability for conversations and updates with customers and other stakeholders.

Scope

Possible assumptions for this category:

• The client will provide all brand information according to the dates specified in the schedule
• We will use the current business brand guidelines
• We will use the current regulations

Client or consulting projects often require specific documents and design information from the customer in order to complete the project scope statement.

Missing data or taking additional time to gather information may impact project efficiency and add time or cost.

Manage this by assuming (for example) that the customer will provide all required information, design data, and so on and that it will be available at a specified time and accurate. That should avoid the need for updates and rework later.

Another nuance to project information is the potential use of specific industry practices, design specifications, company, business unit or site-specific requirements, technical bulletins, etc. It is common for documents such as these to be updated from time to time.

In some cases, those updates can result in changes to the design of work products on a project. In order to help mitigate this, a simplifying assumption could be to use a single set of fixed or “frozen” guidelines for the duration of the project.

Environment

Examples:

• We will use the existing IT architecture
• We will be able to get planning permission in a timely way
• The facilities will be open at the weekend to allow the team to do the project work

These types of assumptions relate to the context of the project: the technology, facilities, infrastructure, and general environment in which you will be carrying out the work.

These are important to document because things you think might be there (e.g. toilets on a building site for female members of the team) might not be there (and they weren’t… true story).

Equally with IT projects, building on the existing architecture is a lot cheaper than having to spin up new servers and find racking for more kit. So it matters.

How assumptions link to constraints, dependencies, and risks

Assumptions, constraints and dependencies are often talked about at the same time. You’ll see sections about all three in project documentation. But how do they link together?

Here are some examples of how constraints and dependencies might connect with assumptions on your project.

Impact on project planning

During the project planning process, you want to become very familiar with the project assumptions, as they will need to be reflected in your project plans. Dependencies and constraints also affect the project timeline, so it makes sense to have the complete picture before you start scheduling.

Understanding the project assumptions will also give you some additional insight into the project constraints and dependencies.

Assumptions and constraints

Here’s an example. Let’s say that you make an assumption that all necessary resources will be available for the project. That implies the project will not be delayed due to schedule conflicts – there won’t be any, because you’ve planned on the basis of your assumption that everyone is available all the time.

In reality, it’s common for people to not be available at some point, for some reason. The schedule would get delayed if someone was not available, unless you’ve also factored in buffer time (additional time) to the baseline schedule.

This would be a resource constraint for the project, assuming there isn’t someone else who could backfill. Your assumption might flag up the need to think critically about resourcing.

Note: Some assumptions may be used to achieve an optimistic schedule. This may be required to achieve a project deadline driven by a fixed date or constraint. An example of a schedule constraint would be the first day of a refinery shutdown, where delays could impact multiple projects, resources, etc.

Assumptions and dependencies

You should also understand if there are dependencies on your project where you might rely on other projects, contracts, or people, and how those might tie back to your project.

For example, let’s say you are building something that requires a deliverable from a different project. Your project schedule might reflect the fabrication, shipping, and receipt of that deliverable. You might assume that this deliverable is going to be available at the required time.

Your project schedule is built on the assumption that receipt of project deliverables will happen as planned. If the dependency on the other project starts to look shaky, that is going to affect your assumption and the rest of the schedule is under threat.

Another example of a dependency is a software project that requires a software integration or API to communicate with and retrieve data from a server. The integration itself may be developed by a third party, so your project would have a dependency on the third-party project and the software integration’s projected completion date.

Assumptions and risks

Assumptions can also flag potential risk. Look through your list of assumptions and see what project risks your project is open to as a result of things you are expecting to happen – because they might not!

The real reason you document assumptions

In reality, these are fluid conversations and experienced project team members would immediately make the link between a late deliverable from another project and a schedule delay. It’s not rocket science. We’re spelling it out here for the purposes of helping you manage project documentation, and because sometimes you have to spell it out for clients and other stakeholders.

The point of documenting assumptions is not because people are too stupid to work out the connection themselves. We do it so we can justify schedule delays, needing extra resources, and so on. When assumptions are transparent, you can say:

• “We assumed that project X would complete their work on time and give us that widget, but it hasn’t happened. As a result, we need another three weeks.”
• “We assumed we’d get branding information from the client within a week, as specified in the contract, but they’ve taken three weeks to get it to us and now our marketing lead has gone on maternity leave so we need another resource to pick up the work.”

Documenting assumptions helps you think through the work that needs to be done AND justify project changes later… because the assumptions you made (that hopefully everyone agreed to and was clear on) did not turn out to be the case.

No one can 100% accurately predict the future, so assumptions help us plug the gaps. They can help avoid major problems with communication and ensure everyone is on the same page.

Tracking and managing assumptions

So where do we document assumptions?

A project assumptions list appears in different places and for different reasons in a project. Here are some examples of common places and ways to track and manage them.

Contracts and proposals

A good starting point is the documentation that has already been prepared for the project.

Contracts, proposals, and Scope of Work documents are common places to document the basis and assumptions for a project. You can also find them in the project charter and business case.

In each of those documents there is usually a section dedicated to outlining basic project information and the assumptions. This is important to define up front, so if there are changes later then the change from the original project basis or baseline is clear.

In a contract, it is common to list out the specific project assumptions to ensure common understanding and alignment between all parties.

To avoid doubt and uncertainty about the project or assumptions, be sure to list these out and review and discuss before signing a contract.

Outlining assumptions in a contract is also important as changes to the basis, for any reason, can potentially impact cost, scope, effort, and more. For changes with a more significant impact, this can lead to project change orders.

Key decisions and assumptions log

A Key Decisions and Assumptions Log is, as it sounds, a list of project assumptions.

Unlike the assumptions listed in a contract, which tend to be ‘fixed’ once the contract is executed, a Key Decisions and Assumption Log is more dynamic. It is the place where the team will document the result of decision making on the project and any new assumptions that may be identified throughout a project’s lifecycle.

As assumptions change, it is also important to document why, how, and when. Additional information can be easily captured in a log. Here are the fields to include:

• Number or ID for reference
• Brief title
• Description
• Date raised
• Assumption owner
• Action/management plan (if any at this point)
• Any other notes.

Maintaining and updating project assumptions in one central place helps, especially as the project evolves or circumstances change.

How to validate project assumptions

Validating project assumptions is a key project activity. When an assumption is identified, the project manager may enlist the project team’s support to document the potential impact and validity of an assumption.

For example, a key assumption on the basis for design may only be valid until updated information is available. At that point, if the assumption is no longer required, the new information can be utilized going forward.

Ideally, the review and validation of assumptions occur throughout a project.

To summarize…

Assumptions are used to help simplify and provide boundaries for the project scope and deliverables. They can be documented in a variety of ways throughout a project’s lifecycle.

The validity and impact of an assumption should be documented, tracked, and maintained throughout a project.

If used properly, assumptions are another useful tool to help project managers manage scope, keep projects moving along, and ultimately ensure the success of your project and a smooth delivery.

FAQ

Your next steps

• Review existing project assumptions in any contracts or current project documents.
• Check if they are still valid and if they give rise to any project dependencies, constraints, actions, risks or anything else.
• Review your risk register and see if any risks include hidden assumptions that should be called out and discussed as a team.
• If you don’t have any existing assumptions documented, review your plans and see if you should have!
• Read this next: The Ultimate Guide to Dependencies and Constraints
• Need somewhere to document your project information? Here’s the workbook I use.