Quantify the problem before you fix it
A simple way to size an operational problem before starting a technology project, so the right thing gets fixed first.
Ask a team what is broken and you will get a good list quickly. Ask which item costs the most and the room goes quiet.
Without a rough number, a problem loses every argument against whatever is loudest that week, and technology gets pointed at the wrong thing.
Describe what happens, not who is at fault
Write the problem as a sequence: what triggers it, who does what, which tools are involved and where it goes wrong. This is also the most useful thing to bring to a first conversation about a project.
Size it with evidence you can show
Rough is fine. Invented is not.
- How often it happens, per day, week or month.
- How long it takes each time, and how many people are involved.
- What a mistake costs, a refund, a missed follow-up, a re-do.
- Where the evidence lives, a report, a spreadsheet, a sample of real cases.
Compare before committing
Size two or three candidates the same way. The best first project is usually frequent, clearly understood and contained, not the most ambitious one on the list.
Bring it to the first conversation
A short description, a rough size and a few real examples are enough to recommend whether the answer is configuration, an integration, automation or custom software.