Projects Flex in Three Dimensions: The Cost of "One Small Change"
A few years ago, I had a team within days of shipping a significant new API. The finish line was in sight, the telemetry was green, and the champagne was on ice. Then, the Project Manager walked in.
"I want to change the name of the API," he said, with the breezy confidence of someone who doesn't have to touch a compiler. "That should be easy, right?"
Because he believed it was easy, he had already committed to the change with marketing and external partners. He’d signed a contract with reality that his engineering team couldn't cash.
Spoiler alert: It wasn't easy. A "simple" name change in a late-stage project is like trying to swap the foundation of a skyscraper while the tenants are moving into the penthouse. It’s not a find-and-replace job. It’s a cascading failure of documentation, client libraries, unit tests, and integration endpoints. If you miss one reference, you don't just have a typo; you have a broken protocol.
The lesson? Don't make assumptions. Ask the people holding the tools. This brings us to the fundamental physics of software: The Three-Dimensional Flex.
The Minimal Acceptable Floor
Before we talk about levers, let’s talk about the floor.
In every project, there is a temptation to treat Quality as a flexible dimension—"We’ll just fix the bugs in the next sprint." In my world, that’s a non-starter. Once you drop below the minimal floor for quality, you aren't "flexing"; you’re just printing counterfeit code. You’re accumulating technical debt that will eventually bankrupt your roadmap. For this discussion, we assume the quality floor is made of reinforced concrete. It doesn't move.
The Physics of the Flex
If the floor is fixed, you only have three levers to pull. If you move one, the others must react. If you try to keep all three static while the environment changes, the project snaps.
Time (The Deadline): The cold, hard date on the calendar.
Resources (The Capacity): The brains and budget you have in the room.
Features (The Scope): The actual "stuff" the user gets to do.
Scenario A: The Clock is Winning
If the deadline is fixed and the work isn't done, you have two choices:
Add Resources: Throw more capacity at it—but be careful. Brooks’ Law is real: adding people to a late project often makes it later.
Remove Features: Brutally prioritize. Cut the "nice-to-haves" to save the core mission.
Scenario B: The Team is Thin
If you lose a key engineer or a budget line gets slashed:
Flex the Timeline: Admit the date is gone and move it.
Flex the Features: Reduce the surface area to match the hands you have left.
Scenario C: The "Simple" Request (Scope Creep)
When a new feature—or a "simple" name change—gets added:
Flex Time: The date moves out to accommodate the new complexity.
Flex Resources: You bring in more help to absorb the hit.
The Myth of the "Free" Feature
Product Management loves the siren song of "squeezing it in." There’s a persistent myth that a small change can be slipped in without moving the date or hurting the team.
It can’t go in for "free." Every addition consumes cognitive load and testing cycles. When we pretend these changes are free, we are just playing another round of Schedule Chicken—stealing from the quality floor and hoping nobody notices until after the launch party.
The Post-Mortem: "Was This Knowable?"
To stop the cycle of "oops, we forgot about this," we ask one clinical question during our post-mortems:
"Was that knowable?"
If it was Knowable: Why wasn't it in the plan? Was this a failure of discovery or a lack of technical grooming? If it was knowable and we missed it, we have a process problem to solve.
If it was Not Knowable: This is the nature of the beast. You don't always know how a user will break a product until they touch it. In these cases, we accept the change, but we apply the flex. Even a legitimate, unknowable pivot requires a trade-off. You can't change the destination mid-flight and expect to land at the same time with the same amount of fuel.
The Bottom Line
Agile isn't magic; it’s a way to manage uncertainty. The goal isn't to have a perfect plan—it’s to have an honest one. When the dimensions of your project change, have the executive courage to move the levers openly. Anything else is just waiting for the crash.