"No matter how great the talent or efforts, some things just take time. You can't produce a baby in one month by getting nine women pregnant."
Warren Buffett wrote that in Berkshire Hathaway's 1985 shareholder letter. He was talking about investing, but it is one of the clearest descriptions of custom software development we have ever read. Some things cannot be parallelized. Some processes have a minimum duration that no amount of money, talent, or headcount can compress. Understanding which parts of your project fall into that category, and which do not, is the difference between a build that ships and one that spirals.
The Triangle
Every software project runs on three constraints: scope (what gets built), time (when it ships), and budget (what it costs). This is sometimes called the project management triangle, the iron triangle, or the triple constraint. The name does not matter. The physics do.
You can lock any two of the three, but the third has to flex. Fix the scope and the deadline, and the budget will be whatever it needs to be. Fix the budget and the deadline, and scope is whatever you can fit. Fix the scope and the budget, and the timeline extends until the work is done. There is no fourth option where all three are fixed and the project still succeeds. This is not a pessimistic view of how projects work. It is just math.
The projects that go wrong are almost always the ones where all three sides were locked before anyone understood the work well enough to lock them. A fixed quote, a fixed timeline, and a fixed feature list. When reality shows up (and it always does, in the form of an integration that is harder than expected, a requirement that was not surfaced in the initial conversations, or a dependency that changed), there is no room to move. The project does not adapt. It breaks.
The Mythical Man-Month, 50 Years Later
Fred Brooks was the project manager for IBM's OS/360, one of the most ambitious software projects of the 1960s. It shipped late, over budget, and with significant quality issues. In 1975, he published The Mythical Man-Month, a book that diagnosed why. Fifty years later, the diagnosis still holds.
Brooks's central argument is that the "man-month" is a myth. A man-month assumes that people and time are interchangeable: if a project takes 12 person-months, you can staff it with four people for three months, or six people for two months, or 12 people for one month. Brooks showed that this math only works when tasks can be perfectly partitioned with no communication between workers. Software almost never works that way.
Two factors make the math break down. First, new people need ramp-up time. They need to learn the codebase, understand the architecture, absorb the business context, and figure out the team's conventions. The people teaching them are the same people who would otherwise be writing code. Every person you add temporarily slows down everyone who was already productive.
Second, communication overhead grows faster than headcount. Two developers have one communication channel. Three have three. Four have six. Ten have 45. The formula is n(n-1)/2, and it is unforgiving. At some point, the team spends more time coordinating than building. Brooks used almost the same metaphor as Buffett: "The bearing of a child takes nine months, no matter how many women are assigned to it."
This is why "just add more developers" is almost never the right response to a project that is behind schedule. It is also why the budget side of the triangle has diminishing returns. Doubling the budget does not halve the timeline. Past a certain team size, it can actually extend it.
How the Triangle Actually Works
The triangle is not a constraint to fight. It is a tool to use. When you understand it, every difficult conversation about a project becomes simpler because the options are always the same three.
- Scope grows. A new feature surfaces mid-build, or an existing requirement turns out to be more complex than anyone realized. The options: extend the timeline to accommodate it, or add budget (with the understanding that more budget means more people, which means diminishing returns past a certain point). The wrong answer is to absorb the new scope without adjusting either of the other two sides. That is how teams end up working nights and weekends to hit a deadline that was set before the scope was understood.
- Budget is fixed. Many organizations, especially those funded by grants, investment rounds, or annual budget cycles, have a hard ceiling on what they can spend. When budget is the fixed side, the choice is between reducing scope (building fewer features, or building simpler versions of the planned features) and extending time (spreading the same budget across more calendar time with a smaller team). Trying to fit a $500K scope into a $300K budget by cutting quality or skipping testing is how you end up with a product that ships on time, on budget, and does not work.
- Timeline is fixed. A regulatory deadline. A conference launch. A competitive window. When the ship date cannot move, scope is the only lever. This is where prioritization becomes the most important skill on the project. What are the features that must ship on day one? What can follow in a fast-follow release? What can wait for version two? The teams that answer these questions before development starts are the ones that hit their dates. The teams that treat every feature as equally critical are the ones that ship nothing on time. We wrote about how we measure whether those answers hold up in practice in our post on how we track project performance.
Why Fixed-Bid Projects Break
A fixed-bid proposal locks all three sides of the triangle simultaneously. Here is what we will build (scope), here is when it will be done (time), and here is what it will cost (budget). This feels safe to the client because the risk appears to be on the development partner. In practice, the risk does not disappear. It gets redistributed in ways that hurt everyone.
When the scope turns out to be larger than the estimate (and it almost always does, because estimates are made with incomplete information), the development partner has three choices. They can eat the cost, which is unsustainable and leads to cutting corners. They can file change orders for everything that was not explicitly specified, which erodes trust and turns the project into a contract negotiation. Or they can deliver exactly what was specified, ignoring the spirit of what the client actually needs in favor of the letter of what was written down. None of these outcomes is what anyone wanted when the contract was signed.
The alternative is to fix two sides and let the third flex. Fix scope and budget, and let the timeline adjust. Fix timeline and budget, and scope gets prioritized ruthlessly. Fix scope and timeline, and budget is whatever is required. The client and the development partner agree on which two sides to lock, and they collaborate on managing the third. This requires more trust upfront, but it produces dramatically better outcomes.
Discovery Exists for a Reason
The single most common mistake we see in custom software projects is locking the triangle before anyone has enough information to lock it responsibly. A client describes what they want. A development partner estimates what it will cost and how long it will take. Both sides commit. Then the work starts and everyone discovers the things that were not visible from the outside.
Discovery exists to surface those things before commitments are made. A good discovery phase produces a clear understanding of what needs to be built (scope definition), a realistic assessment of how long it will take and what it will cost (estimation based on actual investigation, not guesswork), and an explicit conversation about which side of the triangle is flexible (so everyone knows how the project will adapt when surprises arrive).
Discovery is not a delay. It is the fastest way to avoid the kind of mid-project crisis that actually delays things. The two weeks you spend in discovery save the two months you would spend renegotiating scope, rebuilding features, or unwinding architectural decisions that were made with incomplete information.
Brooks knew this too. One of the less-quoted observations from The Mythical Man-Month is that "the hardest single part of building a software system is deciding precisely what to build." Not building it. Deciding what to build. That is what discovery is for.
What This Means for Your Project
If you are evaluating a custom software project, whether it is a new product build, a platform modernization, or a system integration, the triangle gives you a framework for every conversation you will have with a development partner.
- Which two sides are fixed? Ask which two sides they recommend fixing and which one should flex. If the answer is "we can fix all three," be cautious. That is either a partner who has not thought about what happens when the plan meets reality, or one who has built enough padding into the estimate to absorb surprises (which means you are paying for flexibility whether you know it or not).
- What happens when scope changes? Not if. When. Every project discovers requirements that were not visible at the start. The question is whether the engagement model has a mechanism for handling that discovery gracefully, or whether it turns into a change order fight.
- How big is the team? If the proposal involves a large team to compress the timeline, ask how they manage the communication overhead Brooks identified. Small, focused teams with clear ownership boundaries will almost always outperform large teams with shared responsibilities. More people is not the same as more velocity.
- Is there a discovery phase? If the proposal jumps straight from a conversation to a fixed estimate without an investigation phase, the estimate is a guess. It might be a good guess. It might not. You will not know until the money is already committed.
The triangle is not a limitation. It is the clearest tool we have for making honest decisions about software projects. The teams that use it well ship better software, on more predictable timelines, with fewer surprises. The teams that ignore it learn the same lessons Brooks documented 50 years ago, the hard way.
If you are planning a custom software project and want to have the triangle conversation before locking in a proposal, that is how we start every engagement. Get in touch.
