Your spreadsheet is doing requirements discovery.
Read the formulas, exceptions, and reconciliation work before buying an internal tool that erases what your operation knows.
A spreadsheet with colored cells and an alarming filename can contain more useful requirements than a polished software brief. Someone has made room for the awkward cases. Someone knows why a total excludes a row that looks perfectly ordinary. The workbook carries those decisions, however badly it explains them.
Calling it “just a spreadsheet” is a convenient way to stop listening to the people doing the work.
Treat the workbook as a working model of the operation before deciding what deserves a replacement. It may need a better home. It does not need a developer arriving to declare that cells are embarrassing.
Watch the work before cleaning the file
Ask the person responsible for the sheet to walk through a normal update, then a troublesome one. Use a copy with sensitive information removed where practical. Resist the urge to reorganize tabs during the walkthrough. The apparent mess is what you came to understand.
Follow an item from arrival to completion. Note where its identifier comes from, which fields people type, which values formulas derive, and what happens after someone changes the status. Ask which cells nobody else should touch.
A pasted value over a formula deserves attention. It might be a mistake, an approved exception, or a workaround for a calculation that never matched reality. Those possibilities require different software. Blindly converting the formula into application logic only makes the wrong answer harder to edit.
Keep a separate question list. “Why is this blank?” belongs there until someone explains whether blank means unknown, irrelevant, or waiting for approval.
Translate the odd bits into rules
Create a rule map with these columns:
| Workbook clue | Question to resolve | Requirement to capture |
|---|---|---|
| Manually colored row | Does the color change anyone’s work? | Named status and allowed transitions |
| Overwritten formula | Who can authorize this exception? | Override permission and recorded explanation |
| Duplicate-looking rows | Are these errors or separate events? | Record identity and matching rule |
| Hidden reference tab | Who maintains these values? | Managed lookup list and responsible role |
| Separate month-end copy | What must remain fixed? | Reporting cutoff and correction procedure |
These are prompts, not automatic translations. A yellow cell might mean “call today,” or it might mean somebody likes yellow. Software should not immortalize arbitrary formatting as company policy.
For every confirmed rule, record the role that owns it and an example that demonstrates it. Separate the person who enters the data from the person who can change the rule. When colleagues disagree, leave the question open rather than letting a developer settle it through a dropdown menu.
Follow the reconciliation
Ask how people decide the sheet is right. A tidy total is weak reassurance if nobody can explain what it should equal.
Identify the source records, the reporting period, and the person who investigates differences. Capture whether a total includes canceled items, partial completions, or adjustments entered after the cutoff. Record how unmatched items stay visible until someone resolves them.
Compare individual records as well as totals. Equal and opposite mistakes can cancel each other out. Decide what counts as a match before commissioning a replacement, including how to handle records without a reliable identifier.
This work defines the migration problem too. Old inconsistencies need a disposition: correct them, preserve them with an explanation, or exclude them deliberately. A fresh interface will not launder dirty data into truth.
Turn the map into a narrow brief
The brief should describe one recurring job, not a browser-shaped replica of every tab. Use this structure:
- Job: Who needs to complete what task, and what currently obstructs it?
- Scope: Which records and stages belong in the first version? Which stay in the workbook?
- Rules: What calculations, states, and exceptions must the tool support? Attach examples and unresolved questions.
- Ownership: Who enters, approves, corrects, and maintains each kind of information?
- Reconciliation: Which source records and totals must agree, for which period? Who handles differences?
- Boundary: Where does the tool receive information, and where does its responsibility end?
An illustrative scope might be a queue for resolving unmatched incoming records, while the existing workbook continues to handle planning. That is a coherent internal tool. “Replace spreadsheets” is a procurement mood.
Review the brief with the people who maintain the sheet. They should recognize their difficult cases without needing to decode software terminology. Keep the workbook if its flexibility remains useful; replace the parts whose ownership or controls have become painful. The discovery has done its job when you can explain that choice without insulting the file that taught you how the business works.