Before you say yes to that “quick” system change

You’re collecting stories instead of requirements.

That insight will save you from a lot of bad projects if you’ve somehow become the person who owns a system. When you get requests like we need a custom expense module or make the new tool work like the old one, it feels easier to say yes than to slow down and ask why.

My friend Niel likes to tell the story of when he did that with a 14-month, $27 million enterprise resource planning (ERP) project. It finished on time and on budget and didn’t deliver any actual value for his business.

Well, he doesn’t really like talking about it – I think he still has some PTSD. But it provides a cautionary tale for what can happen when you charge blindly forward without pausing to consider whether you really should make some of the changes you planned to make.

This article is a short playbook for avoiding that pattern when you’re the accidental owner of a system. Before you customize anything, you’ll walk a simple system discovery path: talk to the people closest to the work, capture what really happens, turn complaints into clear problems, run requests through a quick filter, and make a small plan before you make any changes.

What the system discovery path is

When you hear “discovery” you may think of a multi-week workshop with sharpie markers, sticky notes, diagrams, and very little to show for it.

The system discovery path is not that.

It’s something you can do in a couple of short conversations and a page of notes before you let anyone talk you into just a quick change.

It’s a short checklist you walk through before you say yes to changing a system. You want to make sure the change is worth doing and that you’re not just rebuilding what people are used to.

The path has five steps:

• Talk to the people closest to the work

• Capture what actually happens today

• Turn complaints into clear problems

• Filter requests before saying yes

• Make a small plan before changing anything

You can do all of this with a handful of conversations and a single page of notes. To see what it looks like in real life, we’ll use one piece of Niel’s ERP project: expense reimbursement.

The primrose path of expense reimbursement

One of the messiest parts of Niel’s ERP project was expense reimbursement. The company could have used the standard payables module to handle travel and other expenses. Instead, they kept a home‑grown process, complicated business rules and all, and built a matching custom reimbursement system, then wired it into the ERP.

All that effort didn’t create new revenue, market share, or customer impact. It probably cost money in wasted time and shadow expenses.

If you’re staring at a similarly tangled reimbursement process, here’s how to walk the system discovery path before you change anything.

Talk to the people closest to the work

Start with the people who actually touch expense reimbursement: frequent travelers who submit reports, accounts payable staff who process them, and managers who approve them.

Don’t ask what features they want. Ask them what really happened the last time they went through the process. You’re collecting stories instead of requirements.

Use “Tell me about the last time you…” and then dig into details.

• Frequent traveler: Tell me about the last time you filed an expense report. Where did it get hard or confusing? Did you get reimbursed the amount you expected in the time frame you expected?

• Accounts Payable: Tell me about the last time you processed an expense report. What slowed you down? Did you have everything you needed the first time?

• Manager: Tell me about the last time you approved an expense report. What do you actually look at? Did anything block you from approving it?

You’re looking for friction and situations where no one can explain why the process works the way it does. Both are clues you may not want to just rebuild what you already have.

Capture what you hear in simple notes

As you talk, jot down just enough that you can reconstruct the story later. Focus on four things:

• What each person was trying to get done

• What actually happened

• Where it got hard

• What they did instead (workarounds, spreadsheets, ignoring rules, giving up)

In the reimbursement example, the frequent traveler wants to get reimbursed quickly, Accounts Payable wants to close the books on time, and the manager wants to avoid policy violations.

Take note of concrete examples like missing receipts, confusing rules, and back‑and‑forth emails that could have been a two‑minute conversation.

Turn complaints into clear problems

Now translate what you heard into one or two specific problems. You may have been asked to “rebuild the reimbursement system as a custom module that mirrors the old one,” but you still don’t know why.

From your notes, you may come up with problem statements like:

• The problem of slow reimbursements affects frequent travelers, who end up carrying card balances and getting frustrated; a good outcome would be reimbursement within three business days.

• The problem of incomplete or incorrect expense reports affects Accounts Payable, who do extra manual checking; a good outcome would be fewer incomplete or incorrect submissions.

Once you can explicitly state the problem, you’re in a better position to decide whether a custom build is worth it at all.

Filter the request before saying yes

With clear problems in hand, step back and ask whether they’re worth solving right now. Anchor this in the business outcome that justified the project. In Niel’s case, the ERP was supposed to help the company close the books faster each month.

Use that as your first decision filter: “Will changing expense reimbursement help us close the books faster?” If the answer is no, you have a strong case to park the request. If yes, add decision filters based on your problem statements to evaluate potential solutions:

• Will this help us reimburse expenses within three business days?

• Will this reduce incorrect and incomplete reports?

Any solution you consider should pass all of your filters, not just one. That’s how you avoid spending months on changes that feel important but don’t move the outcomes you care about.

Make a small plan before changing anything

If a change passes your filters, make a one‑page plan before you touch the system.

For expense reimbursement, that plan might look like:

• Workflow being changed: employee expense submission and approval

• What should be true if this works: expenses reimbursed within three days; fewer incomplete or incorrect reports

• Key questions: which rules are real constraints (compliance, audit) versus historical preferences? Can the standard ERP module handle the must‑have rules with configuration only?

• Discovery work for the next week or two: map current rules, tag them as must‑have or nice‑to‑have, and pilot a simplified flow with standard ERP components.

• Decision point: after the pilot, decide whether any remaining gaps truly justify targeted customization.

The goal is to limit your discovery to the minimum needed to pick the simplest solution that actually helps the business.

When to walk down the path

You don’t need the full system discovery path for every tiny tweak. It’s most useful when people ask for new tools, new automations, or custom builds and can’t clearly explain the problem they’re trying to solve.

In those moments, a few conversations, a quick pass at your notes, and one problem statement are usually enough to decide whether to move forward or say “not now.”

If you remember nothing else.

Before you change a system, walk a simple path: talk, capture, clarify, filter, and plan. It takes a bit more effort up front, but it saves you from rebuilding old problems in a new tool and getting stuck with the fallout.

If you’d like a lightweight worksheet to walk through this on the system you own today, hit reply and tell me which tool you’re responsible for and what change you’re dealing with.