Project constraints: Using the wrong terminology?
We're all familiar with the triple project constraints of time, cost and scope and there's been plenty of debate about whether other constraints should be factored in to the constraint triangle but I'd like to take a step backwards and consider whether "constraint" really is the right description and whether we, as a profession, could better describe how a project is actually constrained and what we really mean by the "triple constraints".
When I consider the time, cost and scope triangle I prefer to think not so much about constraints but rather the balance between different success criteria for the project.
We most often use this triangle approach to negotiate with stakeholders about the most important objectives for the project. For instance, there might be a fixed deadline by which the project has to be complete (think Olympic Games, football World Cup – anything where an immoveable deadline is set well ahead).
Objectives such as a fixed deadline will have been agreed in the business case but it's clearly not always time that cannot be compromised. Some projects prioritise quality, for example, think of the development of a new nuclear power station – quality (i.e. safety) has to be paramount so, where necessary, time and cost would have to be adjusted.
In an agile environment we would fix the time and cost elements and then adjust the scope (and possibly quality) to fit with the available resources. With two fixed elements it is then much easier to reach agreement on the objectives for the project.
But let's return to the concept of "constraints". They are restricting factors that constrain the delivery of a project. As a good example, think about building works at a school. Clearly you cannot allow heavy demolition equipment to be in use during exam time because the noise would simply be too disruptive for the students.
Alternatively, for an IT project, use of a particular programming language or database management system may be necessary because it is company policy. Or works that need to be carried out on or near Sites of Special Scientific Interest (SSSI) may not be allowed at all or only at certain times of the year. Factors such as these are genuine constraints – adding time or money to the project, changing the scope or improving the quality of the work would never enable forbidden work to be carried out at an SSSI.
To make clearer the difference between project constraints and project success criteria, sponsors and the project board can decide to delay the launch date, reduce the budget or alter the scope of a project but it is not possible for the sponsors or project board to change a constraint, such as chopping down trees on a site of special scientific interest.
I would be interested in the views of other project management professionals about distinguishing between constraints and success criteria.
Paul Naybour is the Business Development Director for Parallel Project Training. He is a well-known speaker in the APM Branch Network, a Project Management Trainer and Consultant. He is also one of the voices behind the popular series of APM PMQ podcasts.
2 comments
Log in to post a comment, or create an account if you don't have one already.
I agree. It makes much more sense to me to use the term constraint to refer to the restrictions on what you can do or how you can do it while aiming to achieve the project success criteria.
Hi Paul, when teaching the Iron Triangle (or rubber polygon) we refer to the corners more often as Objectives. We don't use the phrase Triple Constraint in the classroom. Clearly if the target is externally fixed then it looks very much like a constraint, although that word is more commonly used to refer to a fixed item at the solution-level, i.e. a limitation on how a requirement is met. Ultimately it doesn't matter what we call things, if we know enough to change the names to avoid confusion if we have to. However, industry seems to like handy mnemonics for things ...