I regularly provide project management advisory and Project Management Office (PMO) related consulting services to my clients. On many occasions, I have found that project managers do not distinguish between assumptions, constraints, and dependencies properly. Many do not think it is essential; however, I don’t think that project managers are necessarily at fault for this. I believe it is something to do with environmental and/or organizational culture.

In many organizations, the terms, assumptions, constraints, and dependencies, are used interchangeably. As such, these terms are thought of as special project management terms having the same or similar meanings, which is simply not true.

Here are the English language meanings of these terms from Merriam Webster’s online dictionary:

• Assumption: a fact or statement (such as a proposition, axiom, postulate, or notion) taken for granted
• Constraint: the state of being checked, restricted, or compelled to avoid or perform some action
• Dependency: something dependent on something else

Now let’s consider the broader meaning of these terms by looking at their importance in the project management context.

Example Statements

Before we fully explore these three terms, let’s consider some example statements. The following are related to two tasks in a project—Requirements Approval and Design System:

1. The ‘Design System’ task can be started only after completion of the ‘Requirements Approval’ task.
2. The customer should be able to complete ‘Requirements Approval’ in two weeks.
3. The project team has exactly four weeks to complete both tasks.

Can you determine which of these statements is an assumption, which is a constraint, and which is a dependency? I will share the answers and explanations at the end of this article.

What is an Assumption in Project Management?

Assumptions are events or conditions that are that are believed to be true. They are stated without any proof or evidence. A project manager must make certain assumptions in order to proceed with any project as there are always factors beyond one’s control.

Assumptions are not supported by facts. They are based on the knowledge and experience of the stakeholders, as well as the information available for a project. They have to be documented and managed throughout the project.

Assumptions are essential for planning a project. A perfect plan can be made only if you have complete information about a project, but that is seldom the case. There are always some gaps, which can be filled only by making assumptions. If you wait too long for all the information to be available, the project will be delayed indefinitely.

It is important to note that since assumptions are not certain and they may or may not come true, they are considered potential risks.

What is a Constraint in Project Management?

Although assumptions are inevitable to some degree, it’s never fair to assume that a project has unlimited resources and/or and unlimited budget. Every project has limited resources and limited money. Generally, a specific number of resources are assigned, and a budget is allocated to a project. The project manager must complete the project using assigned resources and within the available budget.

Project constraints are defined as anything that limits or dictates the actions and decisions of a project team. Constraints restrict the options a team has. The PMBOK Guide lists six project management constraints. They are as follows:

1. Scope
2. Schedule
3. Budget
4. Quality
5. Risks
6. Resources

You can read my article on project constraints to understand the above list in further detail.

In addition to these, the project team might face constraints related to many other things, such as competitors, environment, technology, and government regulations.

What is a Dependency in Project Management?

Unlike assumptions and constraints, dependencies (usually schedule dependencies) exist between two activities. A dependency can be represented as a directional relationship. The two activities are called the predecessor and the successor. They are separated by an arrow in the below figure, which signifies the direction of the dependency.

The above project schedule network diagram depicts a finish-to-start relationship, one of the four relationships possible between two activities. Finish-to-start relationships are the most common. In this relationship, the start of the successor activity depends on the finish of the predecessor activity.

Your project could have dependencies on the activities that are external, such as activities that your client or vendor is responsible for. It is essential to consider all activities in a project, whether they are internal or external.

Differences

The key differences between these terms is that assumptions are stated without proof or evidence, constraints are limiting factors, and dependencies signify a relationship between two activities.

By now, you can probably correctly associate the three example statements (from the beginning of the article) as an assumption, constraint, and dependency.

1. The ‘Design System’ task can be started only after completion of the ‘Requirements Approval’ task. This is a dependency. ‘Design System’ is the successor, and ‘Requirements Approval’ is the predecessor. The ‘Design System’ task can be started only after the ‘Requirements Approval’ task is completed.
2. The customer should be able to complete ‘Requirements Approval’ in two weeks. This is an assumption. The statement is believed to be true, but only time will tell if the customer can complete the job in two weeks.
3. The project team has exactly four weeks to complete both tasks. This is a constraint. There is an imposed time limit of four weeks to complete the tasks.

Over to you

High-level assumptions, constraints, and dependencies should be identified and documented at the start of a project. They are refined and detailed as more information becomes available and the project progresses. They should be analyzed and managed throughout the project lifecycle.

I would love to hear from you. How do you use these terms in your organization? How do you document assumptions, constraints, and dependencies in your project?