Exception discovery is the moment a project finds out that the process on paper isn’t the process people actually follow, and on most projects it happens far too late. The workflow diagram looked clean. The requirements were signed off. Then go-live arrives and the first real customer, invoice or claim doesn’t fit the happy path, and suddenly the new system can’t handle Tuesday.
If that sounds familiar, you’ve met the exception discovery problem. In this guide we’ll explain why exceptions stay hidden, what it costs when they surface late, and how business analysts in Sydney, Melbourne, Brisbane, Perth, Adelaide and Canberra can bring this work forward to where it’s cheap and useful.
What Is the Exception Discovery Problem?
Every real process has a standard path and a long tail of exceptions: the urgent order, the missing document, the customer with special terms, the manager who approves by phone. People handle these daily without thinking of them as exceptions. They’re just “how we get things done”.
The exception discovery problem is the gap between that lived reality and what the project team captures. Requirements describe the standard path, solutions are designed for it, and the exceptions are found later by users, usually as defects, workarounds or complaints. It’s one of the quietest reasons good projects deliver disappointing results.
Why Projects Fail When Real Work Doesn’t Follow the Process
None of this comes from carelessness. It comes from how requirements work is usually done. These are the six patterns we see most.
1. Requirements capture the happy path
Workshops naturally focus on the normal flow because it’s easy to describe and everyone agrees on it. Exceptions are awkward, inconsistent and often embarrassing, so they stay out of the room.
2. People describe the rule, not the workaround
Ask someone how a process works and you’ll often hear the official version. The workaround they use every day feels too informal to mention. Without a deliberate effort to find exceptions, the official version becomes the requirement.
3. The knowledge lives with experienced staff
The people who know every exception are frequently the most experienced and the busiest. If they aren’t interviewed or observed, their knowledge never reaches the project.
4. The wrong people are in the workshop
Managers describe how the process should run. Frontline staff know how it actually runs. When only the first group is consulted, the picture is limited to whatever managers happen to remember.
5. Testing uses clean data
Test scripts are written from the requirements, so they confirm the happy path. Real customers, real data and real timing then expose gaps that no one tested, because no one knew they existed.
6. Exceptions surface after go-live, when fixes cost the most
A missed exception found during analysis costs a conversation. Found in testing, it costs rework. Found in production, it costs rework, workarounds, lost trust and often a hurried patch. The later an exception is found, the more it costs.
The Real Cost of Finding Exceptions Late
The financial argument for looking early is simple. An exception raised in a workshop is a five-minute conversation. The same exception raised during user acceptance testing means changing requirements, design and test cases. Raised after go-live, it means production fixes, retraining, workarounds and a stakeholder who now trusts the project a little less.
- Rework: features rebuilt because they couldn’t handle real cases.
- Workarounds: users quietly rebuilding the spreadsheets the project was meant to retire.
- Delays: go-live dates slipping while exceptions are triaged under pressure.
- Lost confidence: sponsors and users losing faith in the new process before it has a chance to work.
Experienced analysts treat this as a risk to manage from day one, not an unfortunate surprise. It’s also why organisations increasingly ask BAs how they validate requirements against real work, not just against what stakeholders say in meetings.
Exception Discovery Warning Signs
| What you notice | What it usually means | Where to look |
| Staff say “that’s not how we do it” | Documented process differs from actual practice | Observe real work, not workshops |
| Side spreadsheets and email chains | Systems don’t handle real cases | Collect and review the workarounds |
| Frequent manual overrides or approvals | Rules don’t reflect real authority | Interview approvers and frontline staff |
| Many “special” customers or cases | Exceptions are normal, not rare | Sample recent real cases and outliers |
| High rework or escalation rates | Standard path fails regularly | Analyse volumes, reasons and cycle times |
How Business Analysts Make Exception Discovery Happen Early
Good exception discovery is a deliberate part of elicitation, not a lucky by-product. These techniques, drawn from standard practice in the BABOK Guide and everyday BA work, help surface what people don’t think to say:
- Observation and job shadowing: watch real work for a few hours and note every time someone leaves the standard path.
- “What happens when…?” questions: ask about late, missing, duplicate, urgent and disputed cases for every step.
- Sampling real cases: review the last 20 transactions, including the awkward ones, rather than an idealised example.
- Exception-aware process models: use BPMN to show alternative flows, error paths and escalation, not just the main line.
- Frontline interviews: speak to the people doing the work, separately from their managers.
- Data analysis: look at rework, escalation and cancellation counts to find where the standard path breaks.
- Prototype walk-throughs: show users a draft and ask them to try messy real scenarios.
Types of Exceptions to Look For
| Exception type | Example | How to capture it |
| Data | Missing, duplicate or conflicting records | Review real data samples and error logs |
| Timing | Urgent requests, late approvals, cut-offs | Ask about deadlines and “what if it’s late” |
| Authority | Verbal approvals, delegated sign-off | Interview approvers and map real decisions |
| System | Spreadsheet workarounds, manual re-keying | Observe users and collect their tools |
| Customer | Special pricing, contract-specific terms | Sample non-standard customers and contracts |
| Regulatory | Compliance cases and audit-driven steps | Involve compliance and review policy documents |
A Practical Exception Discovery Process
- Map the happy path first. Agree the standard flow so exceptions have something to be compared against.
- Interview the frontline separately. Ask for the last difficult case, not the typical one.
- Shadow real work. Note every deviation, workaround and informal handoff.
- Sample real cases. Pick a spread, including outliers, and trace each against the documented process.
- Log every exception. Record what triggers it, how often it happens, who handles it and what the impact is.
- Decide what to do with each one. Handle it in the solution, eliminate it by changing the process, or escalate it for a business decision.
- Turn exceptions into requirements and tests. Add alternative flows, acceptance criteria and test cases so they’re built and verified, not rediscovered.
Writing Exceptions Into Requirements and Tests
Finding exceptions is only half the job. They need to live somewhere durable. Add alternative and exception flows to use cases, write acceptance criteria that cover non-standard paths, and use Given-When-Then scenarios for the awkward cases. An exception log with an owner and a decision for each item keeps them visible and stops them dying in meeting notes.
Not every exception deserves automation. Rare, high-risk cases may be better handled by a person with clear guidance, while frequent exceptions suggest the standard process itself needs to change. That judgement is exactly where an analyst earns their keep.
Building Exception Discovery Skills
Exception discovery blends elicitation, process analysis and stakeholder skills, and it improves with structured practice. If you want to build these capabilities, explore our Business Analysis Techniques course, which covers practical analysis methods, and the IREB Requirements Engineering Foundation (CPRE-FL) for a rigorous approach to requirements. Teams working iteratively can look at AgileBA Foundation and AgileBA Practitioner, or the ISQI Agile Business Analysis certification. For change-focused roles, see BCS Business Change Foundation and the BCS Business Finance Certificate. Browse every option on our courses page or the business analysis courses overview, and see IIBA, IREB and BCS for the certification bodies themselves.
Business Analysis Training for Exception Discovery Across Australian Cities
Wherever your team is based, you can build these skills through live online or classroom training:
- Sydney: business analysis courses in Sydney for finance, government and technology projects.
- Melbourne: business analysis course in Melbourne at our West Melbourne centre or online.
- Brisbane: business analysis courses in Brisbane for infrastructure, health and services programs.
- Perth: business analysis training in Perth for resources, engineering and operations-heavy organisations.
- Adelaide: business analysis courses in Adelaide for education, defence and health projects.
- Canberra: business analysis courses in Canberra for public sector and contractor teams.
You can also explore related resources on our sister site, businessanalystcourse.au, and Logitrain’s training catalogue. Learn about us or contact our team for group and in-house options.
Frequently Asked Questions
What is exception discovery in business analysis?
Exception discovery is the practice of deliberately finding the cases where real work departs from the standard process, such as workarounds, special cases and manual overrides, so they can be handled in requirements, design and testing.
Why do projects miss exceptions until go-live?
Requirements workshops focus on the standard path, people describe the official process instead of their workarounds, and test cases come from the requirements. Without observation and real-case sampling, exceptions stay hidden.
How do business analysts find hidden process exceptions?
Through observation, frontline interviews, sampling real cases, analysing rework and escalation data, exception-aware process models and prototype walk-throughs using messy scenarios.
Should every exception be built into the system?
No. Frequent exceptions may signal the process needs fixing, rare and low-risk ones may stay manual, and high-risk ones need clear controls. Each exception should get an explicit decision.
Which course helps with exception discovery?
Business analysis techniques and requirements engineering courses build the underlying skills. See our courses or contact us for advice on the right option.
Final Thoughts: Find Exceptions While They’re Cheap
Real work is messy, and every process has a long tail of exceptions. The projects that cope are the ones that go looking for those exceptions early, write them down and make decisions about them. Strong exception discovery turns surprises at go-live into ordinary requirements during analysis.
Ready to build those skills? Explore our business analysis courses, browse the latest articles on our blog, or call 1300 649 299 to find the right option.