project constraints

You might want to understand what project constraints are and how are they different from assumptions, dependencies and risks.

A project constraint is any factor that hinders or restricts the options of the project team. There are six primary constraints in project Management viz. Scope, Time (Schedule), Cost (Budget), Quality, Resources, and Risk. Out of these the first three are considered as triple constraints of project management.

I have written this article to define and explain project management constraints with the help of a few examples. I have also talked about the relationship and differences between constraints, assumptions, dependencies, and risks.

Project Constraints

Definitions – What are Project Constraints?

A simple way to understand project constraint is to look at its English language definition. Merriam Webster says a constraint is “the state of being checked, restricted, or compelled to avoid or perform some action”.

Similarly, the PMBOK Guide defines a constraint as “a limiting factor that affects the execution of a project, program, portfolio or a process”.

PMI’s definition is very broad as it talks about project, program, and portfolio. A much simpler definition could be

Restrictions imposed by project stakeholders or environment that limits the options of a project team.

It means that, a project team is always working under some limitations and restrictions. The team does not have complete freedom to perform their actions. Some of these limitations are imposed by the project stakeholders but many others are intrinsically present in the environment.

You can also look at Max Wideman’s Glossary for a few more definitions of project constraints.

In an ideal world, there would be no project constraints and project teams would have unlimited options but in the real world teams must find ways to work within the known limitations. Project managers must create a project plan to consider and balance the known project constraints.

Constraints in Project Management

The PMBOK Guide defines following six types of constraints:

  • Scope – It includes the work as defined in the contract.
  • Schedule – It includes the deadlines imposed by the customer.
  • Budget – It includes the funding limits imposed by the Sponsor.
  • Quality – It includes organization or quality standards like CMMI.
  • Resources – It includes unavailability of skilled & competent people.
  • Risks – It includes threats and opportunities e.g. threats due to natural calamities.

Project management involves balancing these limitations or constraints for successful completion of a project.

Apart from the six constraints mentioned above, there could be numerous other type of constraints e.g. constraints arising because of Government policies, industry regulations, organization culture, and procurement guidelines.

Example of a Project Constraint

“A formal approval of design artifacts is needed from the customer before moving ahead in the project.”

The project team has a limitation. The project cannot go to the next step until there is an approval from the customer.

How Project Constraints are Different from Assumptions, Dependencies, and Risks?

The above four terms are used interchangeably in day to day conversations but they are not same. These terms are related to each other but they have different connotations in project management. They should be appropriately used while managing projects.

I have written a few other posts to describe Project Risks, Project Assumptions, and Project Dependencies. You should read these posts to completely understand the difference between these terms but let me tell give you a quick overview.

Typically same event can be categorized as any of the above terms – it depends on how the event is worded. Let’s use the above example and reword its statement. It will help you in understanding the differences.


“Project cannot move ahead without a formal approval.”

The above statement is a constraint as it limits the options of the project team.


An assumption is something that is believed to be true but may or may not occur during the course of a project.

“A project manager believes that the approval will come within two weeks.”

The above statement is an assumption as it may not come true. The approval might come after two weeks or may never come. But unless and until the approval comes, project cannot move ahead. The project manager will have to wait for the approval even if it is delayed.

A constraint is generally comes because of factors that are not within the control of a project. On the other hand, the project manager is generally at liberty to assume certain things.


A dependency is defined between two tasks. A task could be dependent on another task.

“Project task ‘alpha’ is dependent on ‘approval’.”

The above statement is an example of dependency. It came because of a constraint but a dependency can exist without a constraint also. Typically these are called discretionary dependencies.


A risk is an uncertain event, which can impact one or more project objectives. A risk is a type of constraint.

“Project may be delayed if the approval is delayed.”

The above statement is a risk as it is uncertain and it has an impact. The approval may or may not be delayed but if the approval is delayed the project is also likely to get delayed.

Final Thoughts – Key Points about Project Constraints

Project constraints can be imposed by stakeholders like customers or they could be present in the Environment e.g. because of labor laws of a state or country.

Project management involves balancing competing project constraints e.g. a schedule constraint might force project team to compromise on quality. Discovery of new constraints can lead to modification of the project plan.

It is very important to document project constraints properly without which a project can suffer. It is also very important to communicate the constraints to the stakeholders as communication failure can lead to project failure.

Over to you

How do you use the term ‘project constraint’ in your organization? In what form, do you document project constraints? Do you maintain a formal constraint log?

I would love to hear your comments below.

Similar Posts


  1. 2.2.3 Project Success
    Since projects are temporary in nature, the success of the project should be measured in terms of completing
    the project within the constraints of scope, time, cost, quality, resources, and risk as approved between the project
    managers and senior management. To ensure realization of benefits for the undertaken project, a test period (such
    as soft launch in services) can be part of the total project time before handing it over to the permanent operations.
    Project success should be referred to the last baselines approved by the authorized stakeholders.
    The project manager is responsible and accountable for setting realistic and achievable boundaries for the
    project and to accomplish the project within the approved baselines.

  2. Thank you for the information. The challenge I have is differentiating Constraints from realized or potential Risks. For instance, the example you provided of ‘Resources – e.g. unavailability of skilled & competent Human Resources’ would seem to be as much a Risk as a constraint.

    I tend to list some item in both areas, as the Risk Register keeps the ‘constraints’ visible to the team and allows me to track & update them.

    Do you have any comments or insight regarding this practice?

  3. Hi Jim,

    Firstly, a constraint is not a risk but it can lead to a risk. “unavailability of a resource” is a constraint but examples of risks could be:
    1. Project may be delayed due to unavailability of a resource
    2. Project quality might suffer due to unavailability of a resource

    But it is also possible that there is no risk due to a particular constraint. Even if there is a risk, you may choose not to put it in risk register if the impact is negligible.

    Secondly, risk might come due to other factors like estimation, assumptions, requirements etc.

    Thirdly, you can definitely put constraints in risk register but the wording should be different (see the examples above)

    Hope it helps.

Leave a Reply

Your email address will not be published.