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, kbondale.wordpress.com)