Should we ban the term “constraint”?

From the Easy in theory, difficult in practice Blog
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

What's blocking your benefits realization?

Is your project information system of record the grapevine?

What's in YOUR sprint backlog?

Lessons in agility from wine tasting…

Control partners should have skin in the game!

Categories: Project Management

The term constraint ought to be banned when teaching modern project management!

To clarify this shocking statement, there’s nothing wrong with establishing targets or acknowledging the relationship between key project variables such as scope, time, resources, cost or quality – it’s strictly the misuse of the word that offends me.

A constraint represents a hard limit on one’s ability to extend one of these variables.  Unfortunately, there are extremely few cases where this is practically true. Don’t get me wrong – there are some projects where one or more variables are truly constrained – Y2K remediation projects are one example of a valid time constraint.

In most cases, when I’ve asked clients what tends to be the limiting factors for their projects, they might initially indicate schedule, cost or resources but when pushed, their project customers can tolerate some schedule slippage, some budget overruns or they are able to free up resources at the eleventh hour.

It might sound like I am nitpicking over semantics, but the impacts of blind adherence to constraints can be dire.  If a project manager believes that scope is a hard constraint, this may cause the project team to ignore change opportunities that could reduce risk, stress on the project team or increase the probability of project success.

This is not an invitation to ignore the relationships between the variables entirely – if we do, then we are as guilty as those customers that demand fast, good & cheap without something “giving”. 

A PM should never assume that a project is as constrained as it appears to be – negotiation is a critical, but often overlooked, soft skill.

(Note: this article was originally written and published by in December 2010 on my personal blog,

Posted on: February 05, 2018 07:07 AM | Permalink

Comments (11)

Please login or join to subscribe to this item
Good point Kiron.

Let's ban that term. I never liked the use of that term.

Constraint - which is an important factor in project and as you rightly said it is loosing its position in the process of project movement. but without any initial assumption or constraints we cannot plan the project or list out the requirements. As a part of progressive elaboration, constraints will shape in a better way with all the stakeholders my view changes in a constraint by considering all the risk assessment is on positive note... but surely it should be as early as possible in life cycle of project....

I don't look too much into the meaning of the word itself, but I do make a straight swap between the areas of scope, schedule, cost, quality etc. and equate these with the term "constraints", simply because it has been used for so long, and outside the project management world, business also understands this term. Further, I see constraints as something that can and does have some slack, some slippage. Often the meaning of constraint means "forced" liked backed into a corner, but another meaning is "severely restricted". So although very limiting, it's not a death sentence.

Thanks Drake, Shanthi & Sante - often the fences we encounter are those we've built ourselves!


Good article, Kiron
I think that constraints are outside of my control. Actually they are imposed by the client, organization, or by any government regulations.

Thanks Anish - let's just make sure those constraints are truly "firm" and don't be afraid to ask for the "why" underlying them if it is not clear.


a rose by any other name is still a rose

I personally am a bit ambivalent about this. If, as a PM, I do not recognise and adhere to constraints, there is a good chance that I will not meet project objectives.

I do get the point that the objectives, themselves, may be constrained - and give rise to constraints when managing projects. But the end point is that if I have a set of objectives that dictate a constraint, it would not be wholly responsible of me to adhere to that constraint.

The examples in the post of schedule slippage, etc., are decisions being taken by project stakeholders and not individual PMs. Yes, the objectives can be modified so that the constraints are relaxed - but this just gives us a new set of looser constraints.

It is an interesting point of view, though - and one that can be illustrated to stakeholders when freezing the project objectives.

Everything is relative and when you ask "why" few times you can even change something that initially looked as a non negotiable constraint.

Please Login/Register to leave a comment.



Vendor Events

See all Vendor Events