Software Discovery Workshop: Deliverables, Cost Drivers and Red Flags

A software discovery workshop is a structured decision-making phase before substantial development. It should turn an initial idea or operational problem into a shared model of users, workflows, risks, scope and delivery options. Its value is not the number of meetings held. Its value is the uncertainty removed and the evidence created.

Discovery can be a short focused workshop for a contained integration or a multi-week phase for a new platform. The right size depends on uncertainty, stakeholder count, data, integrations, compliance context and the cost of getting a decision wrong.

When discovery is worth doing

Discovery is particularly useful when:

• stakeholders describe the problem differently;
• the requested solution crosses several teams or systems;
• users have different roles and permission boundaries;
• legacy data must be migrated;
• third-party APIs are material to the workflow;
• the first-release boundary is contested;
• security, privacy or accessibility requirements affect design; or
• suppliers cannot estimate without making large assumptions.

It is not a ritual that every tiny change needs. If the outcome, acceptance criteria and technical route are already clear, a team may move directly into delivery planning. The key question is whether unresolved assumptions could cause expensive rework.

What happens before the workshop

Good discovery starts with preparation. The facilitator should request existing process notes, sample forms, anonymised reports, system lists, data examples, policies and previous research. Participants should know which decisions are in scope and which constraints are fixed.

The client should identify a decision owner, subject-matter experts, operational users and technical owners of affected systems. Inviting every interested person to every session creates noise; excluding the people who perform the work creates confident fiction.

A short pre-work interview often reveals disagreement that a group workshop would otherwise hide. The custom software requirements checklist can be used to gather this baseline without pretending it is the finished specification.

Core discovery activities

Problem and outcome framing

The group separates symptoms, causes and desired outcomes. It records what happens today and why the change matters. A useful problem statement names the affected user, situation, friction and consequence without dictating a feature.

Stakeholder and user mapping

Discovery identifies who performs, supervises, approves, receives or is affected by the workflow. It distinguishes user roles, incentives, access and frequency of use. This prevents a system being designed only for the sponsor.

Current-state process mapping

The team maps the real process, including email, spreadsheets, rekeying and exceptions. The aim is not to make a beautiful diagram. It is to reveal handoffs, hidden decisions, duplicated data and work that exists only because of current tool limitations.

Microsoft describes process mining as a way to use event data to understand how processes are actually executed and identify improvement or automation opportunities. Formal mining is not required for every project, but the principle matters: design from evidence, not the official process alone.

Future-state and service blueprinting

The group designs a simpler future workflow and identifies where software, people and external services interact. It keeps human judgement where it is valuable and makes system responsibilities explicit.

Data and integration discovery

This activity names important records, ownership, quality issues, relationships, migration needs and external interfaces. Technical checks should confirm whether advertised APIs, authentication methods, limits and sandbox environments actually exist.

Prototyping and technical spikes

A prototype tests comprehension and interaction without building the full system. A technical spike tests a risky assumption such as document extraction quality, identity integration or an old API. Both should answer a specific question; neither should become unreviewed production code by accident.

Prioritisation and release planning

The team defines a coherent first outcome rather than labelling a long list “MVP”. Requirements are prioritised against business value, user need, risk and dependency. The result should state what is not in the first release.

Deliverables you should expect

Not every project needs every artefact, but a credible discovery usually produces a tailored set of the following.

1. Agreed problem and outcome statement

This concise document explains the current situation, affected users, desired change, constraints and evidence of success. It should be readable by a non-technical sponsor.

2. User roles and permission matrix

The matrix records who can view, create, change, approve and administer important records. It highlights segregation of duties and cross-organisation boundaries that will influence architecture and testing.

3. Current- and future-state workflow maps

These show triggers, steps, owners, decisions, systems, exceptions and outputs. The future-state map should not simply digitise every current step; it should explain what can be removed, combined or automated.

4. Prioritised requirements and release boundary

Requirements should be expressed as outcomes, workflow capabilities and testable rules—not only user-interface components. The initial release should form an end-to-end journey.

5. Data model and migration outline

This is not necessarily a complete database design. It should identify core entities, relationships, sources of truth, sensitive fields, data-quality issues and a migration/reconciliation approach.

6. Integration inventory

For each external system, record the business purpose, owner, data direction, event or schedule, API status, authentication, limits, failure behaviour and unanswered questions. High-risk integrations may need evidence from a spike.

7. Experience prototype

The prototype should focus on the riskiest or most important journeys. It gives users something concrete to test and allows developers to estimate interactions with less guesswork. It is not a promise that every visual detail is final.

8. Architecture direction and decision log

The technical output explains system boundaries, identity, data, hosting, integration patterns, environments and material trade-offs. Short architecture decision records are often more useful than a large diagram with no rationale.

9. Risk, assumption, issue and dependency log

This log names uncertainty and assigns an owner or next action. Examples include unavailable API access, unprofiled legacy data, pending policy advice, stakeholder availability and decisions required from third parties.

10. Delivery roadmap and estimate basis

The roadmap should describe stages, dependencies, validation points and release strategy. Any estimate should state its assumptions, range or confidence and what could change it. Discovery improves the estimate; it does not make complex delivery perfectly predictable.

What drives discovery cost and duration

Discovery effort rises with complexity, not simply project price. Common drivers are:

• number of materially different user groups;
• process variation across teams or regions;
• quantity and quality of existing data;
• legacy or undocumented integrations;
• privacy, security and regulatory considerations;
• need for user research or accessibility testing;
• hardware, mobile or offline requirements;
• number of decision-makers; and
• prototypes or technical experiments required.

Ask suppliers to price the activities and outputs, not a vague block called “analysis”. A focused discovery may deliberately defer detailed work on later releases.

Who should attend

The ideal group changes by session. It normally includes a business sponsor, operational user, process owner, product/delivery lead, designer and technical architect. Bring security, data, finance or legal specialists into decisions that require their authority rather than asking the core team to guess.

The sponsor does not need to attend every working session, but must be available to resolve priorities and constraints. Discovery without decision access becomes documentation of disagreement.

Red flags in a paid discovery

Be cautious when:

• the agenda is identical for every project;
• the supplier promises a fixed build price before examining data or integrations;
• workshops contain only senior stakeholders and no operational users;
• no assumptions or risks are written down;
• outputs are screenshots of a whiteboard with no synthesis;
• a high-fidelity interface is produced before workflows and permissions are understood;
• technology is selected because it is the supplier’s default;
• the client cannot reuse the outputs with another delivery team;
• the estimate has no scope boundary or dependencies; or
• discovery ends without decisions, owners and next steps.

A discovery phase should reduce dependence on the supplier by making the project clearer—even if that clarity makes the client a better buyer elsewhere.

Questions to ask before commissioning discovery

Ask:

1. Which uncertainties do you intend to resolve?
2. Who needs to participate and for how long?
3. Which artefacts will we own at the end?
4. How will users and existing evidence inform the work?
5. Which technical assumptions will be tested?
6. How will unresolved questions appear in the estimate?
7. Can another competent team continue from the outputs?
8. What decision ends discovery and begins delivery?

Use the answers when you compare software development companies.

Discovery is successful when choices become clearer

The result is not a thicker specification. It is a shared understanding of what should be built first, why it matters, how it connects to existing operations and where risk remains. That is also the foundation for deciding whether fixed-price or time-and-materials delivery is appropriate.

AUZtec Innovations includes discovery within its turnkey solutions work and can run it as a focused pre-build engagement. We connect process, experience, data, integration, engineering and deployment decisions so the first release is both useful and supportable.