The Law of the Project Triangle

Boss: “We have to make the deadline on time!”
Developer: “Sure. Do you want to drop features or quality…?”
Boss: “I want all features and no bugs, if that is what you mean by quality!”
Developer: “So you want us to break the deadline? All features with high quality means more time.”
Boss: “No, you heard me: I want all features, no bugs, on time!”
Developer: “But you did not understand me: you can only pick two of those, not all three.”
(developer points to the project triangle diagram to illustrate his reasoning)

This fictive dialogue is a concise version of something I have noticed being misunderstood—intentionally or unintentionally—when it comes to the “bigger picture” of software devepment. With bigger picture I mean things like budgets, project planning, strategic or marketing decisions. Basically anything that involves the management level people in the company: the salespersons, the product owners or any other management or boss figures.

The Project Triangle

The Project Triangle. You can only pick two.

So during a particularly dull meeting with more than one management-level coworker I thought to myself: “This discussion is just going around in circles. There is no solution to this puzzle!”. I decided to try and explain how they are trying to solve an equation with no solution. You cannot have all three – you have to pick two. I did not explain that to them then and there, but instead I drew a diagram similar to the Project Triangle you can find in this chapter.

I called the resulting image “The Project Triangle” since it is related to the project as a whole, not some nitty-gritty details of software development that takes years to appreciate and understand.

First let me explain what I mean with the three ingredients: features, quality and time.


This is the easiest one. It is simply how much time the team spends understanding what they are developing, testing it thoroughly  and refactoring appropriately. Think of it as how much time the team has until the next release. In the project triangle time might be a year, some months, or—if you are really agile—once a week.

If the time frame is fixed, you have a deadline.


This is about how many scenarios, or use cases, you want to bring into the time frame. If you keep answering “yes” when a potential customer, or some other domain expert, asks you if your software can do this or that, you have a feature rich application.


This is the trickiest one, because it is the hardest to measure. From a software engineering perspective, high quality means a lot of effort has been put into making the code robust and having small number of errors. But it is also things like UX—user experience—that is how well the (graphical) user interface and interaction is designed, and how well understood the actual business need is. Is the software solving the right problem? All of those fuzzy, unmeasurable things put together is the quality of the software.

The Law of the Project Triangle

‎”When developing software, one cannot combine having a deadline, producing a high quality end result and cramming in a lot of features. However, picking two of them is realistic.”

The law of the project triangle tells us we can, at most, pick two of the corners in the triangle; we must de-emphasize one of the corners. That does not mean that corner is cut off from the project, it just means we are willing to sacrifice a little bit of it to improve the situation for the other two.

Why is it not possible to combine a strict deadline, high quality and lots of features? You might think of it like this: Features bring more rules into the game. That adds complexity for the developers. To fight that complexity takes time. Either you work long enough to simplify and break down that complexity, or you do not. Of course, not adding so many rules to start with decreases the time it takes to craft high quality.

Now let us go through the three possible combinations that the law states are realistic.

Picking time and features

This means the team focuses on meeting the deadline, and getting all the features running in the software. Focus is not on quality, neither high quality code nor high quality user experience, and in fact not even knowing for sure if the produced features solves the actual business needs of its users.

If you have not guessed so already, this is the least favorable for me personally, and I think that is the case for a lot of developers out there. Sadly, I believe it is also a very popular way of producing software: de-emphasize quality and emphasize deadlines and features.

Picking features and quality

This means that if time becomes a problem (it usually does in software development!), it should not be a hindrance of providing the wanted features and the high quality we are looking for. So deadlines, go and die!

This model can work quite alright for me, but I think it makes the company as a whole nervous, as well as clients that do not really know when to expect the next release of the software.

Picking time and quality

This means if we come close to deadline, we drop features to keep quality and the deadline.

In this model, marketing know the date of the release, and also the most probable features that will go in it (the ones planned for the beginning of the release). Users know when the next release is and can plan for upgrades and so on.

This is the model I have come to prefer. It might sound odd that I, as a developer, want less features. But if you have read this chapter thoroughly, you should see why.

As an old drummers* saying goes: Less is more!

End note – other views on the topic

If you look for ways of explaining how to deal with project management, you will—not surprisingly—find a whole plethora of it. For example, there is a Wikipedia article on the topic “Project management triangle” which discusses quite a lot of different models.

I am not sure if there is a book or article using the three concepts I have explained above, that is the specific division into time, features and quality (and ignoring any other aspect of project management). However, the ways I have found did not fit my head precisely, and a lot of them discussed cost as being one aspect or corner of the triangle. That particular way of viewing (software) project management I think is ill founded.

To me, putting cost in one of the triangles corners reveals a view of software development as if it was a car factory. The car factory analogy is at best a bad analogy. For example, adding a second factory will in fact double the production rate of cars.

However, doubling the number of developers of any software project surely does not double the rate in which software is developed in the short run. In fact I doubt it doubles even in the long run; see the often cited book “Mythical Man Month” for a thorough explanation of why.

* I played drums during my teens and early twenties. I think it is part of why I still do not have back problems or suffer from other body pains even though I have spent at least ten hours a day in front of computer screens for more than twenty years.


3 thoughts on “The Law of the Project Triangle

  1. I’m a fan of the expression: “Fast, good or cheap. Pick two.” This article is one of the better explanations of it that I’ve seen in a while.

  2. Thank you!

    Your division gives three scenarios:

    A. “Fast and good”, which implies not cheap.
    B. “Fast and cheap”, which implies not good.
    C. “Good and cheap”, which implies not fast.

    This fits my head if we’re talking about a “gig”; a clear and well-defined project to do, like a consultant.

    In my post I was assuming a long term project, like a product being developed over years — systems development. Maybe that is something I could have explained better 🙂

    In such a project, just adding more developers–however costly–may or may not increase the development speed (“fast”), in my experience a “it depends” question. Initially because it take a lot of time to get to know the new system–time that is taken from the rest of the team–and in long term because the communication overhead in a team increases quadratically with the number of people.

    Whatever is gained in “linear speed increase” because of the added developer(s), is soon eaten up by the communication overhead constant. Quadratic because in a team n persons communicate with (n-1) persons.

    I think it was in the MMM-book (referenced in post) a formula is put up, something like this, for the speed of development in a team setting. Assuming n equal-level developers of speed S, and a communication overhead constant C, we can define the velocity of the team (could be thought of as the number of features added per week):

    V(n) = Sn – Cn^2

    So regardless of what values we have for S and C, the second term will eat up the first as n increases.

  3. It’s a simple koan but it still applies. Just replace “cheap” with “on budget”, “fast” with “on schedule” and “good” with “stable” and it describes a lot of software projects. 😛

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s