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 Iron Triangle
The concept of the Iron Triangle has emerged over time out of these general assumptions:
- You can develop something quickly and of high quality, but it will be very costly to do.
- You can develop something quickly and cheaply, but it will not be of high quality.
- You can develop something of high quality and low cost, but it will take a long time.
Let's look at each of these statements and what they mean for product development.
Cheap and fast
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.
Good and cheap
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.
Good and fast
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.
Issues with the Iron Triangle
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.
What is an example of the Iron Triangle?
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 scope of the work (i.e., the functions and features necessary to deliver a working product)
- The necessary resources (i.e., the team members and budget for delivering and executing the product)
- The time it takes for the team to go to market and release the product
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:
- Accept a later release date (time)
- Add more people to the project, ultimately raising the overall costs (resources)
The lean startup method
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.
Applying the lean process
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.