How to prioritize improvements in an existing system

Your core business system still runs the company — but the backlog of improvement requests keeps growing, every department thinks their issue is the most urgent, and somehow nothing ever meaningfully changes. Prioritizing improvements in a legacy FileMaker ERP or custom application isn't a technical problem. It's a decision-making problem. This article gives you a practical framework to cut through the noise and invest your limited development budget where it actually moves the needle.

Why urgency is the wrong compass

The most common mistake is treating urgency as a proxy for importance. Someone in sales escalates a request because a client complained. The CFO wants a new dashboard because they saw a competitor demo one. IT flags a technical debt issue that sounds scary. Each of these might be legitimate — but none of them tells you whether fixing it will make a measurable difference to the business.

The result: development cycles get consumed by loud, visible problems while the silent, high-impact bottlenecks go untouched for years. A warehouse team re-keying order data from FileMaker into a spreadsheet every morning because the integration was never built — that's costing hours per day, but nobody escalates it because it's just "how things work here."

Prioritizing by urgency feels productive. It rarely is.

What should actually drive prioritization?

Three lenses work together to form a defensible, business-aligned priority ranking:

1. Business impact — Does fixing this directly affect revenue, cost, risk, or customer satisfaction? An improvement that eliminates a manual reconciliation step between FileMaker and your accounting system saves measurable hours and reduces error rates. A cosmetic UI refresh does not.
2. User need and frequency — How many people are affected, how often, and how severely? A workaround that five power users hit thirty times a day outranks a frustration that one person encounters once a month.
3. Return on investment (ROI) — What does it cost to build versus what does it save or generate? A two-day development task that saves two hours per week pays back in less than a month. A three-month feature project that satisfies one client's wish list rarely does.

When you apply all three lenses consistently, a priority list emerges that you can actually defend to stakeholders — because it's grounded in evidence, not politics.

How to build your improvement backlog the right way

Before you can prioritize, you need a clean, structured backlog. Most organizations have improvement requests scattered across email threads, sticky notes, support tickets, and someone's memory. Consolidate them first.

Step 1: Capture everything in one place. Run a structured intake session with each department. Ask: What slows you down? What do you do outside the system that should be inside it? What breaks under pressure? In FileMaker environments, common answers include: manual data exports to Excel for reporting, duplicate entry between systems, slow layouts with no clear cause, and missing approval workflows.

Step 2: Classify each item. Sort every request into one of four categories:

• Bug / break-fix — something that is broken and actively causing errors
• Performance issue — something that works but is slow or unreliable under load
• Missing functionality — a capability the system never had but the business now needs
• Enhancement / nice-to-have — an improvement to something that already works adequately

This classification alone will surprise most teams. Many items that felt urgent turn out to be enhancements. Many items that were quietly tolerated turn out to be bugs.

Step 3: Score each item. Use a simple scoring matrix — not a complex formula, just consistent judgment across three axes:

Criterion	1 (Low)	2 (Medium)	3 (High)
Business impact	Cosmetic / minor convenience	Saves time or reduces errors	Directly affects revenue, risk, or compliance
Number of users affected	1–2 people	A team or department	Cross-department or customer-facing
Effort to implement	High (weeks+)	Medium (days)	Low (hours)

Sum the scores. Sort descending. Your first pass at a priority list is done.

What about technical debt and system architecture?

Here's the tension most business owners and IT managers feel: the development team says the system needs to be refactored before new features can be added cleanly, but the business wants new features now. Both are right, and ignoring either creates problems.

The practical answer is interleaving — not a separate "technical debt sprint" that never arrives, but a standing rule that a portion of every development cycle (typically 20–30%) goes toward structural improvements: splitting oversized FileMaker tables, consolidating duplicate scripts, migrating to Data API calls instead of legacy ODBC connections, or introducing proper separation between UI and data logic.

This isn't slowing down the business. It's the difference between building on solid ground and piling furniture on a floor that's slowly rotting. As covered in How to modernize business software without starting over, the goal of modernization is continuity — keeping the business running while the foundation gradually improves underneath it.

How do you handle stakeholder pressure?

Prioritization frameworks only work if leadership uses them consistently. The moment a senior executive overrides the list because their pet project "has to go first," the framework loses credibility and the team reverts to politics.

Two things help:

• Make the scoring visible. Share the priority matrix with stakeholders before decisions are made. When someone sees that their request scored a 4 out of 9 because it affects one person and takes three weeks to build, the conversation changes.
• Create a release rhythm. Monthly or quarterly planning cycles, with a clear backlog review, reduce the pressure to react to every new request immediately. Stakeholders know when the next window is and can plan accordingly.

This doesn't mean being inflexible. A true emergency — a compliance deadline, a system outage, a critical client issue — absolutely jumps the queue. But "emergency" should mean something, not be the default label for anything someone wants quickly.

Step-by-step: Your 5-step prioritization process

1. Consolidate — Gather all improvement requests into one shared backlog (a simple spreadsheet or project management tool works fine to start).
2. Classify — Label each item: bug, performance issue, missing functionality, or enhancement.
3. Score — Rate each item on business impact, number of users affected, and implementation effort.
4. Sequence — Sort by score, then manually review the top 10 for dependencies (some items only make sense after another is done first).
5. Reserve capacity for technical debt — Allocate 20–30% of each cycle to structural improvements, non-negotiably.

Repeat this process at least quarterly. Backlogs go stale fast — business priorities shift, some items become irrelevant, new critical needs emerge.

Checklist: Signs your current prioritization process is broken

• The same requests have been on the backlog for over a year with no clear reason why
• Development cycles are dominated by urgent fixes rather than planned improvements
• Different departments feel the system serves other teams better than them
• You can't explain to a new stakeholder why item X is ahead of item Y
• Technical debt discussions keep getting deferred to "next quarter"
• Users have built parallel workflows in Excel or email because the system doesn't support their actual process
• No one owns the backlog — requests come in but nothing is ever formally closed or declined

If you checked three or more of these, the issue isn't your system — it's the process around it.

FAQ

How often should we review and re-prioritize the backlog? At minimum, quarterly. For fast-growing businesses or systems under active development, monthly reviews prevent the backlog from becoming a graveyard of forgotten requests.

Who should own the prioritization process? Ideally a single person — often the IT manager, an operations lead, or an internal product owner — who can translate business needs into development priorities. Without a clear owner, every stakeholder prioritizes their own requests and nothing gets resolved.

What if two improvements have the same score? Look at dependencies first — does one need to be done before the other? If not, default to the one with lower implementation effort. Quick wins build momentum and demonstrate that the process works.

Should we ever say no to an improvement request? Yes. Not everything belongs in a business system. A request that scores low on all three axes — low impact, few users, high effort — should be formally declined, not left on the backlog indefinitely. A clean backlog is an honest backlog.

How do we factor in compliance or security requirements? These are non-negotiable and sit outside the scoring matrix. Any item with a regulatory deadline or a security risk gets elevated automatically — but it should still be scoped and planned, not just thrown at the development team as an emergency.

---

If your backlog has grown unwieldy, your development cycles feel reactive, or you're unsure which improvements will actually move the business forward — that's exactly the kind of challenge Loggix works through with clients. Whether it means auditing an existing FileMaker system, mapping out an API integration that eliminates duplicate data entry, or building a structured roadmap for gradual modernization, we can help you turn a pile of requests into a plan that makes business sense.