When I teach and discuss project management issues, I talk about project constraints and project requirements. Most people immediately think of the “iron triangle”: cost, schedule, and quality. But I don’t find that the iron triangle is sufficient when trying to discuss project tradeoffs. Project constraints and requirements have more than three sides.
Project constraints are what your company has imposed on your project. Your company is willing to spend some amount of money to fund the project (cost to market), and is willing to invest in some people (people and their capabilities), and has created some environment in which you can manage the project (work environment). Your company cares about these constraints, otherwise you could spend more money, hire more people, or change the work environment without having to stand on your head and spit nickels, or whatever rigamarole you go through for more resources.
Project requirements are what your customers care about. The customers care when the project will be complete (time to market), what the feature set is, and how good the product will be (low defects).
You can’t create project requirements that don’t fit inside the project constraints. If you try, you have the problem of a 10-pound project in a 5-pound project bag. No matter what you try, you just don’t have enough people, time, money or tools to release a product when management wants it released, with the requested features and without too many defects.
When I last taught a project management workshop, one of the attendees had trouble with these triangles, and helped me with a new picture. Think of the triangle as more of a pyramid, resting on the base of cost to market, people, and environment. Then, if you want to reduce any of the constraints, you can see it’s harder to increase the time, features, or reduce the defects.
If that explanation doesn’t work, try this one. Imagine all of the lines are elastic. If you pull on the center dot, where the customer requirements meet, and extend one of them, you have to shorten or extend others to make the project work.
I have found that when I describe the project tradeoffs to management using these terms and these pictures, they understand why I’m asking for more time or more people or fewer requirements or more schedule. Sometimes, management thinks it’s as simple as the iron triangle, but once they start talking about tradeoffs, they realize the iron triangle is over-simplistic.
Does this make sense to you?
(Updated 4/25/03 making each image a link, so you can actually see it)