Our process

The right discovery is the best investment you'll make on a technology project.

It answers the hard questions before money is spent on build. It creates shared direction, reduces risk, and gives your leadership the information they need to make a confident ongoing decision.

It doesn't mean a big budget. Even a small, well-run discovery makes sure you've considered your needs, the options available, and the risks involved before anything gets built.

Scroll
Without it, here's what tends to happen
01
The budget overruns. Nobody saw it coming.
Except the gaps were there from the start — assumption gaps written into requirements six months earlier. By the time they surface in build, they're expensive to fix.
02
The system works. Nobody uses it.
The requirements came from the people who commissioned the project, not the people who'd have to live in it. Adoption was always going to be hard. Nobody said so in discovery because discovery didn't go deep enough to find it.
03
Phase two never happens. The business case never closes.
Phase two existed as a slide. When phase one closed, the momentum went with it. The automation and integration work that justified the whole investment was deferred, then cancelled. The project was a success. The investment wasn't.

The build team did exactly what they were told. The problem was they were told the wrong things.

Discovery is where high level requirements, options, decisions and risks are considered. The build team are assuming the right decisions are already made.

Good vs bad discovery

Bad discovery isn't always obvious

The workshops happened. The document exists. The sign-off was clean. But there are patterns that predict problems.

Good discovery
Bad discovery
Options tested before committing

Several architectural options were scoped and prototyped before a path was committed to. The chosen approach has a documented rationale, a risk register, and a mitigation plan for the remaining unknowns.

One path, full confidence, no evidence

"We've mapped the requirements and have a clear path forward. We have every confidence this will deliver." One approach considered. No alternative tested. No risk register. Found out what they'd missed eight weeks into build.

Validated before build

Where possible, clickable prototypes get in front of actual users early. Requirements gaps that didn't surface in workshops come up here, before build starts.

First real feedback arrives in UAT

Requirements came from workshop summaries. Nobody interacted with anything real until UAT, six months into build. Eight weeks of rework. The discovery process had a perfect sign-off score.

Tool selected after requirements

Platform options evaluated against documented requirements. The recommendation includes a scored rationale and explicit trade-offs — including what the chosen platform doesn't do well.

Tool selected before discovery starts

The platform was already decided. Discovery became an exercise in fitting requirements to the tool. The team bought things they didn't need and missed things the platform couldn't do.

Decision registers, not document dumps

Options analysis, documented rationale, the key decisions that prevent arguments in build. Not every requirement captured upfront — the information you need to make good decisions as the project moves. Short. Outcome-focused.

Documents produced as evidence

A 150-page specification nobody read past page twenty. Produced for sign-off coverage. The delivery team worked from the last section and a conversation. Contradictory by month three.

Programme planned, not just phase one

The roadmap sequences the whole programme. Phase two has a defined scope and a trigger. The business case is built on what the complete set of capabilities will deliver.

Phase two never happens

Phase one delivered. Nobody had planned phase two in real detail. The work the business case depended on was deferred, then cancelled. The project was a success. The investment wasn't.

The people running it

What you need

Good discovery needs two things: a deeply experienced expert in technology strategy and execution, and a good BA. The strategy expertise makes the hard calls on options, architecture, and risk. The BA does the detailed work of getting requirements right.

What a good BA does
Ineffective BA choice
Experienced at facilitating workshops and working sessions — knows how to get what you need out of people
Focused on frameworks over people and true business needs
Understands and captures the right level of detail to get what you need
Doesn't know their audience or needed outcome — too waffly or too specific
Creates documents that lead to results and are outcome focused
Creates big documents that are hard to maintain and are rarely read
Brings a system-agnostic view informed by broad CRM and systems knowledge from experience
Lack of knowledge of what is possible or what a developer needs
Is connected to the delivery team
Fixed term or day rate — so a delayed project costs a lot
How we work

How GravityLab runs discovery

Research Workshops Questions & 1:1 Q&A Analysis Prototyping Design & options documentation Validation
1
Research and background reading
We respect your time and come prepared. We like to look at strategy documents, previous project work, any prior discovery, and current system documentation.
2
Questions and 1:1 Q&A sessions
We interview key people individually alongside group sessions. Sometimes this is more productive and cost-effective, and sometimes people say different things one-on-one than they do in a room with their manager present.
3
Workshops structured around decisions
We don't bring a standard workshop format. Sessions are designed around the specific calls the project needs to make. The hard and complex areas get tackled first. Our facilitation experience is in getting real answers out of rooms that don't naturally agree, including cross-functional groups, federated organisations, and boards.
4
Rapid prototyping runs in parallel
We put working versions of the solution in front of real users early. This shows progress and ensures what people react to is more reliable than what they say they want. It saves a lot in decisions, direction and build time — we're building the right thing from the start.
5
Analysis and options design
We look across architecture, tool and feature selection, phasing, and integration approaches. The options are explained — understanding why a path was chosen or rejected matters for future context.
6
Validation before we close
We check that written requirements match what was prototyped and validated. We want every key decision to have a documented rationale, and that the delivery team has what they need.
Rapid prototyping

We make it
before we build it.

What people say in a workshop and what they do with something real in front of them are regularly different. Finding that out in week two is a conversation. Finding it out in week eight of build is a cost.

Version A
app.gravitylab.nz/contact/new ▾ Save contact Cancel Open form — field-per-line layout
Version B
app.gravitylab.nz/contact/42 Edit JR A ↑ Record view — chat panel on right
The output

What a discovery engagement produces

Everything a delivery team and a board need to start the next phase with confidence.

01
Context, landscape, and constraints
Where you are, what's forcing the change, and what the solution has to work within.
02
Scope and focus areas
What's in and what's out, with the reasoning documented.
03
Requirements: functional, non-functional, data, integrations
The complete requirements set at the right level. Data and integration requirements are where most projects find their hardest problems.
04
Dependencies
What the project needs from other people, systems, and decisions, and when. Unmapped dependencies are one of the most reliable sources of delivery delays.
05
Solution and architecture, including systems diagram
How the solution fits together: what connects to what, where data flows. Described in writing and drawn.
06
Technical considerations
Performance, security, legacy system behaviour, data migration complexity, integration limitations. The things that will matter in build and shouldn't be surprises when they arrive.
07
Options design and selection
Evaluated options with scored rationale and a clear recommendation. Trade-offs acknowledged. This is the output most discovery processes skip or do poorly.
08
Phased implementation roadmap
A delivery plan that sequences complex work to the front to resolve unknowns and risks. Future phases are scoped with a trigger, so the business case has a realistic path to full realisation.
09
Vendor requirements, commercial estimates, and project team
What you need from suppliers, internally and what it will cost.
10
Key decisions and trade-offs, documented
Every significant call made during discovery, recorded with the reasoning. Decisions get relitigated in build constantly. This is what you need to supplement build documents, and to feed into your AI models.
11
Risks and mitigation register
Known risks, owners, and mitigations in a format the delivery team will use.
The output that matters most

A business case your board can trust and act on.

Options with costs attached, a recommended path, a delivery timeline, an honest risk register, and a clear view of what future phases look like. It represents a process that they would endorse.

Discovery done properly is the best ROI on a technology project. Done badly, it's expensive paperwork that gives everyone false confidence and commits the programme to an approach before anyone has tested whether it's the right one.

Validating is your pathway to success

Ready to get started?

Get in touch now

"*" indicates required fields