Most feasibility models treat rework as a contingency line item. That's the wrong approach and it's costing developers money they never see.
The Standard Approach is Fundamentally Broken
Here's how most feasibility models handle rework risk: they don't. Or more precisely, they fold it into a 5-10% contingency line and move on. That number is usually based on gut feel, historical averages from previous projects, or honestly, what looks defensible in front of an investment committee.
The problem is that rework isn't a uniform cost spread evenly across a project. It's highly specific to phase, trade sequence, and design maturity at the time construction begins. A 7% contingency doesn't tell you whether you're exposed in the foundation pour or the MEP rough-in. It just tells you someone thought something might go wrong.
Why Rework Is Hard to Model - and Why That's Not an Excuse
The reason rework doesn't get properly modeled is that it's genuinely hard. It requires you to think probabilistically about sequences that haven't happened yet. You need to ask: what's the probability that a design change in week 8 cascades into a structural rework in week 14? What does that do to the critical path? What does that do to returns?
Most Excel models aren't built to handle that kind of conditional logic. So analysts skip it. They write in a contingency, flag it in the notes, and call it risk management.
It isn't.
What Proper Rework Modeling Actually Requires
Genuine rework cost modeling needs three things most feasibility models don't have:
- Phase-specific cost disaggregation breaks construction costs down not just by trade, but by sequence and dependency. Which activities are on the critical path? Which has a float? Where does a delay in one task create idle time (and cost) for another?
- Design maturity inputs at the feasibility stage, design is often 30% complete. That's fine. But the model should reflect that. The less resolved the design, the higher the probability of downstream rework. That correlation should be visible in the numbers.
- Cascade logic when rework happens, it's rarely isolated. A footing dimension change doesn't just cost the extra concrete. It costs the re-survey, the revised structural drawings, the delayed floor slab, and three days of idle framing crew. Models that capture only the direct cost miss 60-70% of the actual impact.
What This Looks Like in Practice
Consider a mid-density residential project with a partially resolved structural design. Traditional model: $2.4M construction cost, 8% contingency = $192K buffer.
A model that properly accounts for rework probability might look like this: 15% chance of foundation rework ($85K direct + $40K cascade), 22% chance of MEP coordination conflicts ($60K direct + $55K cascade), 8% chance of facade revision ($30K direct + $20K cascade). Expected rework cost: ~$68K. But the tail risk if two of those hit simultaneously is $290K.
Now you're not just working with a contingency number. You're working with a distribution. And that's a completely different conversation with your lender.
How AI Changes This
This is exactly the kind of problem where AI-assisted feasibility modeling has a real edge. Not because AI is magic, but because it can hold more conditional logic simultaneously than a human analyst building a spreadsheet by hand.
Tools like FeasibilityPro AI are designed to handle this by building pro-formas that disaggregate construction costs at a level of detail that makes rework modeling tractable, not theoretical.
The goal isn't perfection. You're never going to model rework with 100% accuracy at the feasibility stage. But you can model it well enough to stop pretending a single contingency line is doing the job.
Top comments (0)