A sponsor points at slide 14 and asks where the $4.2 million comes from. Your teammate opens the model to show them, and the cell says $3.8 million. Nobody in the room knows which figure is right, including the person who built it.
That failure is almost never caused by bad analysis. It's caused by six people editing a quantitative artifact with no rules about who changes what. The fix is four things: one canonical file, one person who owns its structure, a deck that cites the model instead of restating it, and a tie-out before submission where every number on a slide is traced back to a cell.
Why the number drifts in the first place
Three mechanisms, and they're boringly consistent across teams.
Parallel edits. Two people open the same file from a shared drive within the same hour. Both save. One version wins and the other disappears silently. Whoever lost the coin flip finds out days later, by noticing a number they remember changing has changed back.
Emailed copies. Someone attaches "latest model" so a teammate can look at one tab. The instant that file leaves its canonical location it is a fork, and forks get worked in. By Friday there are three models and the argument is about which one is current, not what the answer is.
The 1am hardcode. A link broke, or a formula threw an error, and someone typed 0.07 over it because the deliverable was due in six hours. The number was right for that one build. It is now permanently wrong and structurally invisible—it looks exactly like every other cell, and it will never announce itself.
The deck amplifies all three, because slides restate numbers instead of pointing at them. A figure typed into a text box on Tuesday has no relationship to the model on Thursday. Nothing breaks, nothing warns you, and the two quietly stop agreeing.
One file is canonical, everything else is stale
Pick one file, in one location, and name it where you wrote your working agreement. Then say the second half out loud, because it's the part teams skip: every other copy is stale by definition. Not "probably a bit behind." Stale. That includes the one in someone's downloads folder and the one attached to Tuesday's email. It has to be that absolute, because the moment a copy is treated as "probably fine," someone works in it.
The deck then cites the model rather than restating it. Every number on a slide gets a pointer in the speaker notes:
Slide 14 headline: $4.2M NPV
Source: Summary!C18, model v04
Two minutes per slide, and it turns an unanswerable question—where did that come from?—into a lookup.
Name a model owner, and accept that it feels bureaucratic
One person owns structural changes: new tabs, changed formulas, restructured driver logic. Everyone else requests them.
On a five-week project with six people, this feels like process theater for about ten days. Then someone wants to add a churn assumption at 11pm and the queue feels absurd. Hold the line. The cost of the rule is hours of latency; the cost of skipping it is the Q&A scene above, in front of the person grading you or funding you.
Keep it narrow so the latency stays small. The owner gates structure, not inputs—anyone can change a value on the assumptions tab as long as they log it. This is exactly one accountable owner per deliverable, applied where shared editing does the most damage.
One variation genuinely doesn't work: rotating the owner mid-project. The second owner inherits formulas they didn't write and can't defend.
"Let's all just edit the live version" trades a loud failure for a silent one
Simultaneous cloud editing does solve the merge problem. No model_v7_FINAL_final.xlsx, no lost saves, no argument about which copy is current. Take that win—your canonical file should live in cloud storage.
Then be clear about the trade. A version conflict is a loud failure that stops you and forces a decision; a silent overwrite is not. When six people can change any cell at any time, changes happen with no review, no author, and no stated reason. Yes, the platform keeps revision history—but nobody reads a diff of four hundred cells at midnight, and it still won't tell you why the discount rate moved.
So add back the two things simultaneous editing removed:
- A structural gate. The model owner, above.
- A change log. One line for anything that moves an output: date, cell or named range, old value, new value, why. Same instinct as keeping a decision log for async work, applied to numbers instead of choices.
If writing that line feels like overkill, it's usually a signal the change wasn't as small as you thought.
Build a model someone else can defend
Separate inputs, calculations, and outputs onto different tabs—not just different colours on one sheet. Then:
- One assumptions tab, holding every hardcoded number in the model. Every one.
- A source column beside it. Not "industry research." "10-K p.42." "Sponsor call 3/12, CFO." "Team estimate, no source." That last one is legitimate, and far more useful than a blank cell.
- No magic numbers inside formulas.
=B14*0.85is a landmine.=B14*Assumptions!$C$7is defensible. - A colour convention. Blue for values a human typed, black for formulas, green for cross-tab links. Standard on the sell side, and it earns its keep here for one reason: a blue cell in the middle of a black column is the 1am hardcode raising its hand.
Alone, each item is ordinary modelling advice. What changes on a team is who has to use it. The person presenting is almost never the person who built the model. Hygiene is what lets a teammate open a tab they have never seen, with a sponsor waiting, and answer correctly.
Freeze versions, and never edit the one you present from
Name files so they sort themselves:
2026-03-14_model_v04_jm.xlsx
Date first, then version, then the initials of whoever saved it. Chronological order for free, and you always know who to ask.
At each milestone—sponsor check-in, dry run, submission—copy the file into an /archive folder and don't touch it again. Then the rule that matters most: the version you present from is frozen at the end of rehearsal. Case competition teams already understand the deck freeze; the model needs the same rule an hour earlier, because the deck is downstream of it.
If someone finds an error after the freeze, there are two options and both are whole-team decisions: present the wrong number and disclose it upfront, or unfreeze and re-rehearse. What you never do is quietly fix the model at 7am and send the presenter in with a deck that no longer matches.
The tie-out is a named step, with an owner and a time
Put it on the calendar. Sixty to ninety minutes, the day before submission, one person's name attached. "We'll double-check the numbers" is not this step—it's how teams describe not doing it.
Two people work it, out loud. One reads every number off the slides; the other traces each to a cell and says the reference back. Everything counts: axis labels, exhibit footnotes, and the number in the executive summary nobody rechecked after the model changed on Sunday.
It catches three distinct problems, and the third is the one that detonates in Q&A:
- Stale numbers. The slide says what the model used to say.
- Rounding drift. $4.2M on one slide, $4.24M on another, presented as the same figure.
- Numbers with no cell at all. Someone computed a percentage in their head, and it's off by two points.
The tie-out owner should not be the model owner—the builder's memory papers over gaps a stranger's eyes won't. Keep the output, too: that list of slide-to-cell pairs is your Q&A sheet.
Make the number that matters a switch
There is always one assumption the sponsor will push on—the adoption rate, the discount rate, the ramp. It should be a single cell that changes everything downstream, not a value you re-key across four tabs.
Test it weekly: change the cell, watch the outputs move. Anything that doesn't move is a hardcode you didn't know you had. Thirty seconds, and it's the cheapest audit in the model.
The payoff is the moment your team looks strongest. Someone asks what happens at 15% instead of 20%, and rather than promising to follow up, you change one cell and read the new answer off the screen.