A tool can be imperfect and still be the correct tool. Change is justified when the present way of working causes enough cost, risk, or customer trouble to beat the work of changing it.

• A new tool proposed before the current job is mapped.
• A connection between tools that creates two places with different answers.
• A replacement with no way to take the business data out or train staff.
• Custom software built for a problem that happens twice a year.

• Name the broken outcome, not the disliked tool.
• Measure one week of handoffs, delays, errors, and cost.
• Test the smallest move that fixes the outcome.
• Name ownership, maintenance, migration, and exit before buying.

This is how we scope every systems job. The answer can be no project. That is still a useful answer.

Get a plain-English second opinion