There’s an old saying in software development that goes something like, “Fast, good, or cheap – pick two.” Known as the Iron Triangle, Project Management Triangle, or Triple Constraint, this concept will be familiar to anyone who has ever felt the pressure of weighing the opposing forces of quality, speed and cost against each other.
The general concept is that you have three choices when making a product: Make it quickly, make it cheaply, or make it well. While it has long been believed that accomplishing all three isn’t possible, some are now thinking that it is. Focusing on values and eliminating assumptions are key to the development of a valuable product.
The concept of the Iron Triangle has emerged over time out of these general assumptions:
Let’s look at each of these statements and what they mean for product development.
If you develop something cheap and fast, you’ll sacrifice features or the quality of the product to get it done this quickly. You create an acceptable prototype and can start receiving feedback on it immediately.
This allows you to start receiving feedback and improving your product, but the sacrifice may not be worth it. You could hurt your company’s credibility and create more problems for yourself down the road.
Another option is to create a high-quality product but spend as little money on it as possible. You’ll deliver a better product to your customers, but it could take you a long time to finish it while staying under budget.
If you have the time to do a lot of research and product development in the beginning, this could have better results for your company. But in today’s market, businesses need to be flexible and able to act quickly, which isn’t likely with this method.
Ultimately, since you never received feedback from your customers during development, you may end up creating a high-quality product that they don’t really want.
Finally, you can create a high-quality product in as little time as possible. Out of the three options, most businesses would probably prefer this one. You can create a good product in short time, but it’s going to cost you.
You’ll likely have to invest in a team to help you meet the demands of your timeline – and the extra money spent could be wasted if you have to redo the product.
As you can see, a few problems emerge pretty quickly with these statements. The first issue with the Iron Triangle is the definition of “good,” or the concept of quality.
The triangle assumes that fast and cheap is an option, but in truth, delivering a low-quality product is seldom an actual option. Whether you’re releasing a product to market, completing a project for a client, or delivering on an internal company project, quality is a universal expectation.
The second issue is known as the Mythical Man-Month or Brooks’ law, which states, “Adding manpower to a late software project makes it later.” While Brooks’ law refers specifically to software development, its concept applies to many types of projects.
This is often simplified by the metaphor “too many cooks in the kitchen.” The basic concept is that when you add more people to a problem, the additional communication overhead and complexity of team dynamics often have a negative effect on the timeline as a whole.
That pretty much eliminates the combination of good and fast as a real option. That leaves us with good and cheap, but that means the project is going to take a long time. Thanks to the lean concept, though, that doesn’t have to be the case.
The constraints are thought to be iron because you are unable to change one constraint without impacting the others.
Let’s use the Iron Triangle to look at the constraints in project management for a software development team as an example. These are some of the constraints they’d face:
The goal of the Iron Triangle is to give a product team the necessary information to make trade-offs that ultimately help the business. For instance, if the team has a fixed scope, they may be halfway through the project and realize they are unable to meet the release date.
At that point, these are their options:
The lean startup method is a process for delivering products and businesses developed by Eric Ries in 2008. Chronicled in his 2011 book The Lean Startup: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, it is based on concepts borrowed from lean manufacturing as developed by Japanese automakers in the 1980s.
The lean startup method extols the concept that anything which does not deliver value to the end user is waste. This waste is combated by creating testable and measurable hypotheses, then measuring them against honest and meaningful key performance indicators (KPIs).
The first step is to build a minimum viable product (MVP), which is the simplest version of a product that can test your hypothesis and deliver the maximum amount of validated learning.
After creating your initial MVP, the next step is to iterate over and over, using tools like split testing and the predetermined KPIs. These tools will help you make adjustments to that product with one of two outcomes: Refine it to excellence, or determine failure and pivot.
Under the lean method, anything that isn’t of value to the customer is considered waste. You utilize this method by creating hypotheses that you can test with a simple prototype of your product, allowing you to make improvements with minimal waste.
Armed with what we’ve learned about the shortcomings of the Iron Triangle, it is possible to deliver a project that is fast, cheap, and good by applying the concepts of the lean process. With this process, you keep teams small, because you know that too many cooks are just going to make communication more difficult and limit your flexibility to deal with changing market demands.
Since you are just building an MVP at first, a big upfront investment isn’t necessary. You are testing your hypothesis, so spending a lot of money or investing in other resources would be a waste if you’re wrong.
Keeping teams small and limiting the investment in the MVP lets you keep the project cheap. You’re also building the MVP to gain validated learning as soon as possible and deliver something of value to the end user.
By focusing on those values – and preventing a bloated scope full of assumptions and untested hypotheses – you can build fast. When limiting the work to the MVP, you get to market quickly with something of value.
Once you’ve released the initial MVP, you can continue to follow the lean principles, using validated learning and KPIs to decide what’s working and what’s not, and iterate quickly. The reiterations and meaningful measurements will guide you toward the end goal of delivering a good product.
And there you have it: fast, good, and cheap, all in one project.