Your Project's Constraints Are Upside Down

Most of what slows a project down isn't a real constraint. It's a rule nobody remembers deciding on.

"Physics is the law. Everything else is a recommendation." — Elon Musk

Musk says this when his engineers tell him something can't be done. If thermodynamics says no, you stop. If a supplier, an industry convention, or "the way we've always done it" says no, you've only been handed a recommendation, and recommendations can be argued with.

You don't have to be a fan of the man to find the sentence useful. I'd argue it's one of the most practical ideas a business analyst can carry into a requirements workshop, because most of us spend our working lives surrounded by recommendations dressed up as laws. And, strangely, we tend to treat the real laws as if they were open for negotiation.

A rule nobody decided to keep

Picture a claims modernization program at a mid-sized insurer. It's a composite, but if you've worked on a transformation, you'll recognize every piece of it.

Four months in, the design for claim approvals is almost finished. The rule is that any claim over $10,000 needs sign-off from two senior adjusters, so the team has specified eleven workflow variants, a delegation matrix for when people are on leave, three integrations and a full audit trail. It's the most expensive single component in the build.

Meanwhile, to protect a go-live date the sponsor announced at a town hall, user testing has been cut from six weeks to two. Nobody likes that decision. Everybody has agreed to it.

Then one of the analysts, doing a last pass through the design, asks the question nobody had asked: Where does this rule actually come from?

It takes her two days to find out. The adjusters shrug and say it's in the manual. The manual turns out to be a PDF with a 2011 date in the header, written after a fraud case by a claims director who left the company years ago. Then she finds a 2019 internal audit memo sitting in a shared drive. It replaced blanket dual approval with risk-based sampling, and the audit committee had endorsed it. Nobody ever updated the manual. The adjusters followed the manual, the project team documented what the adjusters did, and the vendor priced what the team documented.

For eight years, a rule that nobody had decided to keep was obeyed by everyone.

I don't think anyone in that chain was careless. Each of them did the reasonable thing and trusted the rule. It just happened to be a recommendation that had outlived its author, its reason and its authority.

Now look at the two decisions sitting side by side on that project. The team was treating a dead policy as untouchable and a testing window as something it could squeeze. That's the pattern worth naming. The constraints were upside down.

The laws we try to negotiate

Projects have physics of their own. Bent Flyvbjerg, who has studied more than 16,000 projects, found that fewer than one in ten came in on budget and on time, and only about one in two hundred also delivered the benefits they promised. That isn't a comment on anybody's competence. It's closer to a natural force. People underestimate complex work, reliably, and the error compounds.

A few other laws are just as stubborn. If you squeeze scope, time or cost, the pressure goes somewhere, usually into quality, where it stays out of sight until go-live. Bad data moved into a new system is still bad data, just more expensive to fix. And people change how they work on their own timetable, driven by their workload, their confidence and what they're measured on. A requirement that says "users will switch to the new process at go-live" isn't really a requirement. It's a hope, and analysts are well placed to call it one.

Steering committees argue with these laws all the time. "We'll absorb it." "The team will find a way." Every one of those phrases treats physics as a suggestion. The project manager who says a date can't be met usually gets cast as the obstacle, when they're often the only person in the room taking reality seriously.

The recommendations we treat as sacred

The other half of the problem is where analysts earn their keep.

Some phrases should make any analyst's ears prick up. "The system requires it" often means someone configured the system that way a decade ago. "Compliance requires it" often means someone once read a regulation cautiously, and their reading became the rule. Go back to the actual legislation and the gap can be startling. "The business wants it" sometimes means one senior person mentioned it in a meeting and nobody felt able to push back.

Then there's the most expensive sentence in any transformation: Let's just replicate current state in the new system. It sounds safe. In practice it's a decision to take every rule that has built up over the years and pour it into software.

And software is where recommendations go to become laws.

A rule in a manual can be questioned, ignored or quietly dropped. A rule in a configured workflow gets enforced on every single transaction until someone funds a project to change it. That makes the analyst, who sits between the manual and the configuration, the last person who can question the rule cheaply.

AI makes this more urgent. Teams can now produce requirements, process maps and working automations in a fraction of the time. That's a gift when the rules underneath have been checked. When they haven't, it simply turns recommendations into laws faster than ever. My worry isn't that AI will build things badly. It's that it will build the wrong things very well, and very quickly.

The Law-or-Recommendation Test

To make the idea usable, it helps to grade every constraint by how hard it really is.

The question that does most of the work is simple: Who can change this, and how quickly? As Walter Isaacson tells it, Musk insists that every requirement carry the name of a person rather than a department, because you can't cross-examine a department. If the honest answer is "nobody, ever," you're looking at physics. If the answer is a person, you're looking at a recommendation, and your next job is to go and find them.

A recommendation isn't the same as a suggestion

There's a careless way to use this idea, and it can do real damage: if it isn't physics, bulldoze it. That's how organizations tear out controls they don't understand and later find out, painfully, why they were there. Plenty of safety rules, privacy protections and financial controls were written after somebody got hurt.

G.K. Chesterton put the right instinct well a century ago. If you come across a fence in a field and can't see why it's there, don't pull it down. Go and find out why it was put up. Once you know, you're free to remove it.

So "recommendation" doesn't mean "optional." It means someone owns it. The analyst's job is to trace every rule back to its owner and its reason. Sometimes the reason is still alive and the rule should stay. Sometimes, as at the insurer, the reason retired years ago and the rule simply never heard.

What to try this week

Put a person's name, not a team's, beside each of your top ten requirements, and check that each person still stands behind theirs.

Go through the dates in your plan and mark which ones are driven by something real, like a contract ending or a system going out of support, and which are promises someone made in a meeting.

Every time you hear "the system can't," ask which system, and who says so.

Before any process is automated, question it first. Automation should be the reward for a process that has survived scrutiny, not a way of skipping it.

Back to the fence

The analyst at the insurer didn't delete the dual sign-off on her own say-so. She took it to the head of internal audit, who confirmed the 2019 change and that no regulation required the old control. The rule came out, the workflow shrank from eleven variants to two, and the cost of that component dropped sharply.

The part I like best is what happened next. The team didn't just bank the savings. They used them to buy back four weeks of user testing. The system went live about a month after the date announced at the town hall, and it worked on the first day. In claims processing, people remember that for a long time.

Musk's line is the hook, and it's a good one. But the real hero of that story isn't a principle. It's a question that most of us are a little too polite to ask in a room full of senior people. The most valuable requirement on any project is often the one nobody writes down:

Where does this rule come from?

Author: Olam Osah

Olam Osah is a seasoned Project Manager and strategic leader with a strong foundation in business analysis and information systems. He holds a PhD in Information Systems from the University of Cape Town, along with Honours and Masters degrees from the University of the Witwatersrand, Johannesburg. Olam specializes in leading complex projects that bridge technology and business, delivering impactful solutions across public and private sectors. Known for his ability to turn vision into actionable plans, he combines academic depth with real-world execution to drive results. Connect with him at [email protected].