competition strategy

time management, problem selection, and team dynamics for math modeling competitions. distilled from HiMCM, MCM/ICM (Meritorious, top 10%), M3, MTFC, and USAYPT (2nd nationally).

the meta-game

modeling competitions aren't just about math. they're about project management under extreme time pressure. MCM/ICM gives you 4 days. HiMCM gives you ~2 weeks but the effective work window is much shorter. the teams that win aren't always the most mathematically sophisticated — they're the ones that manage their time, divide work effectively, and produce a polished paper.

time allocation

for a 4-day competition like MCM/ICM, my rough allocation:

day 1 (first 8-12 hours): problem selection, research, problem-framing, initial model design. this is the most important day. a bad framing wastes the entire competition.
day 2: core model development. get the math working, get code running, generate initial results.
day 3: refinement, sensitivity analysis, additional models or extensions. start the paper structure.
day 4: paper writing, polishing, proofreading. no new math on this day — if it's not done, it doesn't go in.

the biggest mistake teams make: spending too long on the model and not enough on the paper. judges read the paper, not your code. see mathematical-writing.

problem selection

when given multiple problems (MCM/ICM offers 6):

pick the problem your team can model, not the one that sounds coolest. FOMO (fomo-trap) applies here — the "exciting" problem might be outside your team's strengths.
prefer problems where you can validate. if there's real-world data to compare against, your paper is stronger.
avoid problems that require domain expertise you don't have unless you can learn it fast. you can't become a climate scientist in 4 days.
read all problems before choosing. obvious but teams often anchor on the first one that catches their eye (information-gathering).

team dynamics

for a 3-person team (standard MCM/ICM):

one person owns the paper. always. writing by committee produces garbage. one person writes, others contribute sections and review.
parallelize where possible. one person on the main model, one on a secondary approach or sensitivity analysis, one on research and paper structure.
sync frequently but briefly. 15-minute check-ins every few hours beat hour-long status meetings.
disagree early, commit fast. the worst outcome is spending day 3 debating something that should have been settled on day 1. see reversible-vs-irreversible — most modeling choices are type 2.

the summary page

in MCM/ICM, the summary page is the most important page of the paper. first-round judging often only reads the summary. it needs to:

state the problem clearly (as you interpreted it)
describe your approach concisely
present key results with actual numbers
highlight what makes your approach novel or strong

don't create suspense. don't narrate your process. state your conclusions upfront. this is not a mystery novel; it's a technical report.

when things go wrong

they will. models fail, code has bugs, team members disagree. the perseverance page is relevant here, but so is knowing when to pivot. if your approach isn't working by the end of day 2, pivot. don't spend day 3 trying to save a broken model (sunk-cost-and-quitting).

the teams that do well aren't the ones that never hit problems — they're the ones that recover fast.