Phase one is not "MVP" as an excuse for half a process
Phase one should be complete for one slice: a user can finish a real job without a shadow spreadsheet. It is not a login screen plus a database while quotes still live in email — that is website versus operations thinking applied to a build. The vision can be ambitious. The first ship must change a Tuesday someone can name.
Teams kill visions by boiling the ocean in phase one. They also kill adoption by shipping half a workflow and calling it agile. The fix is a thin, complete path with a written defer list — not hope dressed up as a roadmap.
How we cap scope without killing the vision
The target is one measurable win in ninety days: faster quote turnaround, fewer re-keys, one report the room trusts. Pick a metric leadership will notice if it moves, not a technical milestone nobody outside IT cares about.
An explicit defer list matters as much as the build itself — written, shared, and dated. "Phase two: multi-site inventory sync" is a decision. "Phase two: everything else" is a junk drawer. Stakeholders sign the defer list so that "why isn't X live yet" has an answer that is not political.
Set entry criteria for phase two before you build phase one — for example, 95% of jobs running in the tool for four weeks before you fund the next module. The first 30 days after a build matter more than sprint velocity. And name an owner for adoption at go-live, following the same thinking in ownership that ships. If nobody owns adoption, phase one becomes a demo environment.
Anti-patterns that feel like progress
Phase one that only works with a hero in the room is telling you something. If one person's absence breaks everything, the scope is wrong or training was skipped. Phase one that duplicates the old tool rather than replacing one handoff means you now maintain two sources of truth. Phase one with no export or rollback story means finance will veto go-live at the last hour — and they will be right to.
Building integrations for every edge case before the happy path is stable is another common trap. Automate the stable slice first and let exceptions stay manual with a named owner until the pattern is clear — the when to automate guidance covers that decision in more depth.
Keep the vision visible without funding it early
A one-page north star diagram on the wall is fine. Funding every box on that diagram in quarter one is not. Tie phase two to proof, not enthusiasm after a good demo. The custom software worth it calculation should include the cost of a half-shipped process — often higher than waiting one quarter to do one slice properly.
Finance and ops must sign the slice
Phase one fails when finance expects full ledger parity on day one while ops only got job tracking. Align on what Monday looks like: which reports still come from the old tool, which handoffs must be complete in-system, and what parallel running is acceptable for two weeks. Write it in the defer list so nobody can claim surprise at month-end.
Include migration rules for open work — the data migration honest checklist is relevant even when phase one feels small. Half-migrated open jobs are how shadow spreadsheets return.
Book a systems review to shape phase one with someone who will say when the vision should wait. Build when the slice is honest, and care after go-live so the habit survives the next busy season.