What are Project Constraints?


Do you know what the difference between Project Constraints, Assumptions and Dependencies is?

I have written a small series of posts to describe Project Constraints, Project Assumptions and Project Dependencies. Although these terms look simple but sometimes they are confusing in practice. This post is written to describe Project Constraints. You should be able to understand the difference between these terms after reading all 3 posts. These three terms have immense utility in Project Management if they are used appropriately.

What are Project Assumptions

What are Project Dependencies?

What is a Project Constraint?

According to PMBOK® Guide, Project Constraint is “A limiting factor that affects the execution of a project, program, portfolio or a process”.

Another definition could be “Project Constraints are restrictions imposed by Stakeholders or Environment that limits Project Team’s options”.

You can also look at Max Wideman’s Glossary for the definition of Project Constraints.

According to PMBOK® Guide, Project Management involves balancing the Competing Project Constraints. These include, but are not limited to:

  • Scope – e.g. work as defined in Contract
  • Schedule – e.g. Customer imposed completion dates
  • Budget – Sponsor imposed funding limits
  • Quality – e.g. conformance to a Quality Model such as CMMI
  • Resources – e.g. unavailability of skilled & competent Human Resources
  • Risks – e.g. threats due to natural calamities

Project Constraints simply mean that, Project Teams always work under some limitations and restrictions. Project Management involves balancing these limitations for successful completion of Project. In ideal conditions (when there are no Project Constraints), a Project Manager may have unlimited options but in practice the Project Manager must find ways to work within known limitations. Project Manager, along with the Team, creates a Project Plan while considering and balancing known Project Constraints.

Are there any other Project Constraints (other than the six mentioned above)?

Yes. There could be other type of Constraints like Organizational Constraints, Environmental Constraints, Procurement Constraints etc.

Let’s understand the concept of Project Constraints through the same example that I used in Project Assumptions post.
Situation – PM requires an Approval on Design Artifacts from the Customer during the course of the project. Project cannot move ahead without this Approval.

Project Constraint – “Project Team has a limitation. Project cannot move ahead without Customer Approval.”

PM may “Assume” that the Approval may come within 2 weeks. But unless and until the Approval comes, PM cannot move ahead. She/he will have to wait for the Approval even if it is delayed.
Let us talk about few key points regarding Project Constraints.

  • Project Constraints are, sometimes, related to each other and hence Project Management involves Balancing Competing Project Constraints. e.g. a Schedule Constraint might force Project Team to compromise Quality
  • Project Constraints could be imposed by Stakeholders like Customers
  • Project Constraints could be present in the Environment e.g. Labor Laws of a State or Country.
  • Discovery of new Project Constraints can lead to modification of Project Plan.
  • Project Constraints should be well Documented and well Communicated. Poor Communication of Project Constraints can, sometimes, lead to Project Failure.
  • Project Constraints are part of all formal Project Documents but preferably they should be Documented in a separate Project Constraints Log.

But, I still cannot fully understand how Project Constraints are different from Project Assumptions and Project Dependencies?

You will have to read my posts on Project Assumptions and Project Dependencies to understand the difference.

You should also refer to my other articles on difference between similar Project Management Terms.

Praveen Malik, PMP

​Praveen Malik ​is a certified Project Management Professional (PMP®) with a rich 23+ years of experience. He is a leading Project Management Instructor, Coach and ​Advisor. He ​has successfully trained thousands of aspirants for the PM certification exams.

Click Here to Leave a Comment Below

Eng. Mohamed Essam Reply

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.

Jim Reply

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?

Praveen Malik, PMP Reply

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: