Scoping custom software starts with the mess, not the wish list
Most custom software projects do not blow up because the code is hard. They blow up because the business process was never properly mapped before anyone started estimating.
I have seen this pattern repeatedly with Australian businesses that have outgrown spreadsheets, inbox-based approvals, and a patchwork of off-the-shelf tools. The team knows the work is painful. They also know what they want the new system to do. What they usually cannot articulate cleanly is how the work actually moves today, who makes which decisions, where the exceptions live, and which parts of the process are genuinely necessary.
That gap is where software scoping either becomes useful or becomes theatre.
If you are planning custom software, the discovery process is not a formality. It is the part where you separate the real workflow from the folklore, so your software project planning is based on reality rather than the loudest opinion in the room.
Start by mapping the actual workflow, not the ideal one
When a process is full of exceptions, workarounds, and tribal knowledge, the first job is business workflow mapping. Not a whiteboard sketch. A proper map of how work moves today.
That means tracing one item end to end. A lead, an order, a job, a contractor, a claim, a support request, whatever the unit of work is. Follow it through every handoff.
Look for:
- where the work starts
- who touches it
- what data gets captured
- which systems are involved
- where people stop and ask for approval
- where exceptions are handled manually
- what gets copied from one place to another
- what happens when the “normal” path fails
The useful detail is usually not in the happy path. It is in the exceptions that happen three times a week and the workaround everyone treats as normal.
A lot of teams in Australia think they have a process problem when they actually have a visibility problem. The spreadsheet is acting as a workflow engine, the inbox is acting as an approval queue, and one person in operations is holding the whole thing together from memory. If that person goes on leave, the process falls apart.
That is not a software problem yet. It is a discovery problem.
Treat tribal knowledge as evidence, not truth
When a process lives in people’s heads, you will hear statements like:
- “We always do it this way.”
- “Except for that client.”
- “Usually Sally handles that.”
- “We don’t really need a step there, unless it is a rush job.”
Do not write those statements straight into your custom software requirements. Test them.
A good discovery process asks three things about every rule or exception:
- How often does this actually happen?
- What breaks if we remove it?
- Is this a business rule, or just a workaround for a limitation in the current system?
That last question matters more than most teams realise. A workaround can look like a requirement if it has been around long enough. But if it only exists because the current tool cannot do something sensible, preserving it in the new build just hard-codes the pain.
This is where software scoping needs discipline. You are not documenting everything people do today. You are deciding what deserves to survive.
The first scoping mistake is usually hidden approvals
If I had to name the mistake that most often causes a custom software project to blow up later, it is hidden approvals. Not integrations, although those can hurt. Not data ownership, although that matters too. Hidden approvals are worse because they sit underneath the visible workflow and only appear once estimates are already locked in.
A hidden approval is any step where someone says yes, no, or “not yet” without that decision being explicit in the process map.
Examples:
- a manager checks every quote before it goes out
- finance approves new suppliers before they can be added
- compliance signs off on documents before a job can start
- a senior operator manually reviews edge cases before release
- a customer success lead overrides the normal process for key accounts
If you do not capture those approvals early, your custom software requirements will be incomplete. The team will think the build is straightforward. Then the prototype lands and everyone realises the system needs role-based approvals, status transitions, audit history, notifications, and exception routing.
That is not scope creep. That is missing scope.
The way to catch it before estimates are locked in is simple, but it takes patience:
- ask who can block each step
- ask who can override each step
- ask what needs to be true before the work can move forward
- ask what gets recorded for audit or accountability
- ask what happens when the approver is unavailable
If the answer is “we just message them on Teams” or “we usually sort it out in person”, you have found a hidden approval path.
Preserve the workflow only if it is still doing useful work
Clients often say they want the existing workflow preserved. Sometimes they mean the process is embedded in the business and changing it would create chaos. Sometimes they mean they do not trust the new system to force a better way of working.
Those are different problems.
If the current workflow is broken, preserving it exactly is usually the wrong goal. The better question is which parts of the workflow are there for genuine business reasons, and which parts exist because the current tools are poor.
A practical way to estimate effort is to split the workflow into three buckets:
| Bucket | What it means | How to treat it in scope | |---|---|---| | Core requirement | The business cannot operate without it | Keep it, design for it, estimate it properly | | Policy or compliance rule | Needed for governance, audit, or risk control | Keep it, but make it explicit and testable | | Legacy workaround | Exists because people are compensating for a bad process or bad tool | Challenge it, simplify it, or remove it |
If the client insists the workflow must stay the same, do not argue from taste. Argue from cost and risk. Show them what it takes to automate every exception, every manual check, and every special path. Then show the simpler version that preserves the business outcome without preserving the mess.
That is often where the real value in custom software appears. Not in digitising the old process, but in removing the parts nobody actually wants to keep.
Key takeaway: If a step only exists because the current system is awkward, it is usually a candidate for removal, not automation.
Over-scoping edge cases is easy, and expensive
When you are mapping a messy process, it is tempting to capture every odd scenario “just in case”. That feels safe. It is not. It is how software projects get bloated before a line of code is written.
The signals that you have over-scoped edge cases are fairly clear:
- you keep hearing “while we are at it”
- the same exception only applies to one client, one region, or one person
- the rule has not happened in the last 12 months, but someone remembers it from years ago
- a workaround is being treated like a permanent branch in the workflow
- the team cannot explain the business impact if the exception is handled manually
- the exception adds a lot of branching logic for very little operational volume
A good test is this: if the edge case affects less than 5 percent of transactions, and there is no compliance or revenue risk in handling it manually for a while, it probably does not belong in the first release.
That does not mean ignore it forever. It means park it. Put it in a backlog, label it clearly, and decide whether it is a phase two item or a manual process to retain for now.
This is where many software project planning exercises go wrong. They try to make version one perfect. Perfect is expensive. Clear is achievable.
Integrations and data ownership need to be nailed down early
Hidden approvals are the most common scoping trap, but missing integrations and unclear data ownership are the two that usually hurt most once the build starts.
If the new system needs to talk to Xero, MYOB, Microsoft 365, a CRM, a document store, or a third-party API, that is not a detail. It is part of the scope. Same with data ownership. If two systems both think they own the customer record, you will get duplicate records, stale data, and arguments about which source of truth is right.
You need to know:
- which system is the master for each data object
- what data must sync in real time versus overnight
- what happens when an integration fails
- who owns error handling
- whether historical data needs migration
- whether the integration is one-way or two-way
In one recent setup for Michael Jones, Pierce Solutions handled the domain registration, website, and Microsoft 365 tenant quickly and cleanly, all in under 24 hours. That kind of speed works because the scope is tight. The decisions are explicit. There is one point of contact, one bill, and a clear idea of what belongs where. Even in a small setup, clarity around ownership saves time immediately.
The same principle applies to larger custom software builds. If your data model is fuzzy, your estimate is fiction.
What changes after the first prototype is built
The first real prototype or technical spike is where the truth shows up. Not because the team was careless, but because some things are impossible to validate on paper.
The parts most likely to change are:
1. Workflow assumptions
People often describe the happy path during discovery. The prototype reveals the actual branching, the awkward approvals, and the places where users need to backtrack.
2. Data structure
Once you start building forms, reports, and filters, it becomes obvious when fields were grouped badly or when the business needs a different record structure.
3. Integration effort
A system that looked like a simple API connection can turn into a mapping exercise, especially if the external platform has poor documentation, rate limits, or inconsistent data.
4. Permissions and roles
Role-based access always looks simpler in a workshop than it does in a live system. The prototype usually exposes more nuance around who can view, edit, approve, and export.
5. Reporting needs
Users rarely ask for reporting in enough detail during discovery. The prototype makes it obvious which metrics matter, which filters are needed, and which reports need audit history.
The point of discovery is not to eliminate all change. It is to structure the change so it does not become political.
Use discovery to reduce argument, not just to collect requirements
A good discovery phase should do more than produce a document. It should create decisions.
That means you need a process that separates facts from preferences and records the trade-offs clearly. I usually want discovery to end with:
- a mapped current-state workflow
- a proposed future-state workflow
- a list of explicit assumptions
- a list of confirmed integrations
- data ownership rules
- a prioritised set of custom software requirements
- a list of out-of-scope items
- known risks and open questions
- a prototype or technical spike summary where needed
If the team cannot agree on a rule, write down the decision owner. If the team cannot agree on a process, write down the business outcome and the constraint. That stops scope debates from turning into personality debates later.
For Australian businesses, this matters even more when the software has to fit around local compliance, GST treatment, payroll workflows, or industry-specific record keeping. If you are building in healthcare, logistics, construction, or supply chain, the software scoping needs to reflect the actual operating environment, not a generic SaaS workflow.
The best scope is the one that can survive contact with reality
The goal is not to preserve every old habit. The goal is to build a system that supports the business without dragging its worst workarounds into the future.
That is the difference between a useful discovery process and a box-ticking exercise. Good software scoping is blunt. It asks what the business actually needs, what can be simplified, what can be deferred, and what will cause pain if ignored. It does not pretend every exception deserves custom logic.
If you are planning custom software, start with the workflow map, not the feature list. Challenge the hidden approvals. Separate real requirements from legacy habits. Lock down data ownership before estimates harden. Then use the prototype to test the assumptions that matter most.
If you want a practical next step, map one process this week from start to finish, including every approval, handoff, and exception. Then mark each step as core requirement, policy rule, or workaround. That one exercise will tell you more about your software project planning than a month of vague meetings.
