The Project Management Triangle—not just for Project Nerds

When it comes to project management, I'm a minimalist. To this end, one of the things I do is teach non-project professionals the essentials of project management. "Just the facts, ma'am", as Joe Friday used to say (but in fact, didn't, as it turns out). After all, if you're not planning on making project management your profession, there's no need to delve too deeply into esoteric PM principals and frameworks. No one reads the PMBOK for fun.

Project Management Triangle showing the triple constraints of time, scope, cost, and their impact on quality.

That said, anyone doing anything with projects must understand the basic premise of the project management triangle, because it elegantly illustrates the key constraints of project management: Time, Cost, Scope, and Quality. (Project management is elegant, you say? Correct! Look how much we're learning.) A project manager needs to balance each of these competing constraints in order to produce the desired output—the project deliverable. Every project has to balance these inherent constraints.

Let's use an example to illustrate. Imagine that you're creating a new app. Your project constraints are:

Time: 1 month

Cost: $100

Scope: A dating app that lets users find romantic matches and communicate with them by in-app text chat. (Note: Scope is the description of your project 'boundaries', so this would be a useless scope for a real project! I'll talk about scope, and its evil twin brother, scope creep, in future blog posts.)

Now, let's say your client drops by and drops a bombshell—they want the app to include text AND video chat. Argh. Your scope has now expanded. But, let's say you still need to deliver within the same time frame and at the same cost, so what do you do? You'll have to adjust the quality. Maybe your text chat was on its way to being this super cool chat with custom fonts, animated avatars, and fancy sound effects. Now, it will be a plain text chat, since you have to "make" time to add the video chat.

Obviously, this is very simplistic, plus you'd be a terrible project manager if you simply accepted being boxed into this situation. In the real world, you wouldn't "eat" this type of scope change. You'd talk to the client about how this scope change will impact their project. Then, as the problem-solver you are, you'd figure out a solution, whether it be more money, more time, more resources, or change other parts of the scope, etc. Also, keep in mind that lowering deliverable quality will not always fix the constraints problem, nor it is always a viable solution or a way to client happiness. I'll touch on this topic in future blog posts.

The bottom line: Every project has to balance the constraints of scope, cost, time, and quality. If one of these elements changes, there will always be repercussions among the other constraints. It's up to you, as the PM, to figure out how to mitigate the effects of any scope change, manage scope creep, and keep the lines of communication open with your client, so you can figure out solutions together.