Triple Constraint: Fast, Good, Cheap (Speed, High Quality, Low Cost)

Speed.  High quality.  Low cost.  However you phrase it, we live within these parameters every day both in our personal and professional lives.  The goal for most is to have all three together. But when you step back and look at what you are actually requesting, it can be explained by the cliché:  You want to have your cake and eat it too…and not get fat.

Fast, good, cheap. Speed, high quality, low cost. These terms combined are known by a variety of names often referred to as the “Project Management Triangle”, “Triple Constraint”, or “The Iron Triangle”. I definitely do not know everything there is about this topic, I can just speak to my personal experiences.  What I want to do is help give an awareness and present something for you to think about that will hopefully drive you to perform some research of your own.

Take a quick look and you will see there is tons of information on the subject.  Many argue that you can completely have all three, while others think that is unattainable. Both sides of the argument are defendable. I tend to side with the argument that you cannot have all three in perfect harmony, there is always some type of tradeoff. Even though you can have a project that is perceived as fast, good, and cheap, I interpret the triangle to say you cannot MAXIMIZE all three together. There is always a compromise between the constraints.

What do you notice about the terms fast, good, and cheap?  Are they concrete?  What/who defines fast?  How do we know if something is cheap?  If it is good, can it be better?  The terms are relative and can be subjective.  Each requires an established benchmark to determine if the goal has been met or exceeded.  Once you have that benchmark in place, it is oftentimes difficult to determine if the parameter has been truly maximized.  My experiences in production and projects have opened my eyes to the different constraint combinations. This experience has helped me determine which to maximize, because there is always a tradeoff, for each application.

In production, we wanted all three but would often tradeoff quality for the other two.  This was common because we had a higher tolerance for quality than for cost and speed.  The quality tolerance allowed for saleable products with some variation.  The main goal was to be efficient: high speed with low cost.  This was true for the production environments I experienced, but I do understand it can be quite different in other industries.

In the business of projects and project management quality is rarely, if ever, intentionally sacrificed.  Quality outlives the project life cycle.  Speed and cost are “here and now” parameters, while quality is present for the entire post-project existence.  Days to years after the completion of an EPC project, people will continue to either criticize or complement what they see in the field.  Operators who use the results of the project will curse those who made the operability difficult. They will praise those who provided a clean, understandable, sound design and installation.

Quality is a given.  So where does that leave speed and cost?  I have found these are the two constraints that are most commonly discussed at the start of a project.  We always want to know:  What is more important, speed or cost?  From this exchange, proper decision making can take place and a project can meet (or exceed) the expectations of its stakeholders.

We live in a world of constant balance, always trying to do things better, faster, smarter, and stronger.  When working for or with a company, the ability to understand and accept constraints as reality is crucial.  By listening to clients to figure out the right mix, the chances of successfully completing a project and building lasting relationships increases.

‍