In classic project management parlance , every project is a combination of money, scope and time.

1. Here's what we're going to do
2. Here's how much time we have to do it
3. Here's how much money we can spend doing it.

These three factors are all related. If you pull on one "edge" of the triangle, the other sides have to give. If we cut the budget in half, we can't do as much, so scope has to give. That's why it's often called the iron triangle.

In software development, the terms are a little different, but the underlying meaning is the same. We use Time, Resources, and Functionality.

Sometimes all three dimensions of the triangle are locked. If you're given three people, four months, and a non-negotiable budget of $300k to build software, then that's what you do. But how is this possible? Something still has to give. There's an unstated fourth ingredient in the iron triangle: quality.

Once you add the fourth ingredient, the triangle metaphor breaks down. Sam Guckenheimer calls it a tetrahedon. But my co-worker Susan has an even better analogy: it's a stool.

At least for software development there's still some debate as to whether or not the stool really is made of iron:

Although widely practiced, [the iron triangle] paradigm does not work well. Just as Newtonian physics is now known to be a special case, the iron triangle is a special case that assumes the process is flowing smoothly to begin with. It assumes that resource productivity is uniformly distributed, that there is little variance in the effectiveness of task completion, and that no spare capacity exists throughout the system. These conditions exist sometimes, notably on low-risk projects. Unfortunately, for the types of software projects usually undertaken, they are often untrue.

Many users of agile methods have demonstrated experiences that pleasantly contradict this viewpoint. If you improve qualities of service, such as reliability, you can shorten time. Significant improvements in flow are possible within the existing resources and time

It's definitely a good idea to keep the "classic" stool resources in mind. But the highly variable nature of software development means that, if you're careful, you may be able to build your stool out of a more malleable material than iron.