We Dutch are cheap, or at least that is what is suggested. In Belgium, it is claimed that the Dutch are buried face downwards to create more slots in which to park our bicycles. I think you can say that we try to avoid spending too much money. If you managed a software project here in the Netherlands, you would see a very strong tendency to save as much money as possible. However, I've never heard of a place where there is an unlimited budget.

My cheapness (from being Dutch) is an illustration for the more earthier matters concerning a project: trying to get a fix on the limited mundane stuff you need to proceed to the more noble cause of building a system. Whatever you have to create, whatever the reason for the project may be, there will always be constraints set for the project. These conditions determine the space in which the project organization may operate. Therefore, you might think of this part of project management as the "party pooper segment", as constraints always spoil the fun.

Project constraints consist of the following elements:

• Cost: This includes everything that costs money, like people and equipment.


• Time: What is the time frame in which every activity should take place?


• Quality: What is the level of quality the project has to reach?

Constraints are not independent from each other. Reaching a higher level of quality will cost you more money. If you want to use less time, you need more people (later on in this chapter, you will see that adding more women to give birth to one child does not shorten the nine-month gestation period; this is rocket science project management). The point I'm trying to make is that constraints are interdependent.

A classic way to show this interdependence is through use of the Project Constraints Triangle, or Iron Triangle. Imagine a 3-D space where the x-axis represents the amount of cost, the y-axis the amount of time, and the z-axis the level of quality for the project.

The project is represented by a triangle within this 3- D space. The size of a project is displayed as the square of the triangle. The size is determined by complexity and the amount of the product to realize. As you might understand, quality is a product requirement, and size can be viewed as the scope of the project.

A project with a constant size can have altering constraints. However, altering one constraint has influence on the others because the square of the triangle stays the same. The constraints are reflections of the stakes of the customer, but keep in mind that regardless of how boldly the constraints are stated by the customer, they are requirements, not stakes, so there is room for some negotiation. Playing with the aspects of the project triangle (including size) may also satisfy the stakes of the customer and therefore are more likely to be accepted.

It seems that every customer wants the best product tomorrow, and it may not cost a penny. I'm sure these customers do exist, but most top managers have a more realistic view of the matter. They know constraints must leave some room to operate. This doesn't mean they will ever admit that.