Why Discovery Matters
When you’re modernising a legacy system, especially in government or enterprise, it’s not just about building something new. You’ve got to understand what’s already there. This means looking at how the system is actually used, figuring out what the business really needs, and spotting any risks before they trip you up.
Discovery is where all of that happens. It’s the phase that makes sure we’re building the right thing and not just what we think the brief says. Whether we’re dealing with a decade old system or a critical platform that can’t afford downtime, Discovery helps us line everything up so the modernisation work can move ahead with clarity and direction.
We sat down with David Burkett, CGO and Director, to talk about how the WorkingMouse discovery process works and why it’s so important for modernisation projects.
A Three-Phase Approach Anchored in Jidoka
Every project at WorkingMouse goes through our Jidoka framework:
- Discovery & Design
- Modernisation
- Continuous Optimisation
Each stage builds on the last. Discovery is where we understand the system, document the “as-is,” and prepare for a modern future without overstepping into premature assumptions.
Goals Board: Where Scope Meets Clarity
A key artefact in Discovery is the Goals Board. This is a visual, structured application model built on Codebots.
We break work into milestones, each with distinct streams:
- Application
- Infrastructure
- Platform
- Documentation
Each stream has goals, which map to requirements with linked acceptance criteria. These criteria become the signposts for delivery and client approval. As David says, "The acceptance criteria is what the customer signs off on. That’s how we ensure we’re delivering the right thing—milestone by milestone."
Modelled Requirements
Unlike traditional requirements that live in Jira or spreadsheets, our approach is different: we model requirements.
- They’re tied directly to the product.
- They connect with testing, documentation, and UI components.
-
They evolve with the project, staying current and relevant—not wasting away in siloed documents.
This modelling means we get test traceability, auto-generated user guides, and linked artefacts. This keeps everything synchronised as the system evolves.
Business vs Built Requirements
During Discovery, we differentiate between:
-
Built Requirements – captured through models like entity
diagrams or UI mockups.
-
Business Requirements – the custom logic, flows, and
user needs that don’t emerge from code alone.
Only the business requirements go into the requirements model. It keeps our focus lean and intentional.
Like-for-Like Modernisation
Our approach often involves like for like modernisation. This is when you rebuild the legacy system with modern architecture but not changing the business process at the same time.
Why? Because changing both the tech and the process introduces unnecessary risk. We modernise first, then optimise incrementally. This approach helps get modernisation done faster, with fewer surprises and much more control along the way.
SMEs
Documentation? Often outdated. The real insights live with the people who use the system daily.
That’s why we sit with Subject Matter Experts (SMEs). We record, observe, and understand the “why” behind each button press. Frequently, the answer to “Why do you do it this way?” is “I don’t know—we’ve always done it this way.”
David talked about one time where they traced a whole process, only to realise the button someone was clicking didn’t actually do anything. It had just become part of the workflow out of habit. Stories like that are surprisingly common!
SMEs help us uncover that kind of knowledge. They show us the real process, not just what’s written down. And that’s what helps us rebuild systems that make sense, not just replicate what was there.
Functional & Non-Functional Requirements
Discovery isn’t just about features. It’s about everything that makes the system usable, scalable, and compliant. That includes:
- Security (OWASP, ASD Essential 8)
- Accessibility (WCAG 2.0 AA)
- Infrastructure & Hosting
- Architecture Compliance (especially for QLD Gov projects)
We incorporate these into Codebots templates and our CI/CD pipelines, generating audit trails, testing for compliance, and validating assumptions early.
Activities, Techtivities & Workshops
We run a mix of collaborative and technical activities in Discovery:
-
Activities like journey mapping, user interviews, and
context canvases
-
Techtivities (aka tech spikes) to explore unknowns like
legacy algorithms or data flow
-
Workshops for live modelling ERDs, reviewing business
processes, and co-designing interfaces
Each role (BA, designer, architect) leads sessions aligned to their expertise. It’s agile, cross-functional, and outcome-driven.
Lessons Learned
Discovery done poorly doesn’t always reveal itself immediately. But weeks into delivery, the cracks show:
- Missed requirements
- Overlooked infrastructure or compliance needs
- Lost knowledge due to team churn
- Rushed Codebot setup
- Misalignment between stakeholders
To avoid this, we now book the same team for Discovery and Development. No handoffs. No loss of context. Just continuous momentum.
Final Word
Discovery is not preamble. It’s product. Done right, it sets the tempo, reduces scope creep, and makes modernisation projects feel inevitable—not impossible.
If you’ve got a legacy system and wondering where to begin, start with Discovery. And start it properly. Take your first step toward modernisation with our quick quiz!
