The term constraint ought to be banned when teaching modern project management.
To clarify, 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 constraint 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 absolutely limited – Y2K remediation projects are an obvious 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.