Discovery Process

Purpose

This page documents the structure and scope of discovery engagements. It clarifies what discovery work examines, how findings are organized, and what is delivered at the end of an engagement.

Discovery is not implementation. It is structured evaluation designed to surface constraints, assess viability, and establish whether proposed solutions align with actual operating conditions.

Why discovery comes first

Most AI initiatives begin with an assumption that AI can solve a specific problem, that implementation is straightforward, or that a particular tool or approach is appropriate.

Those assumptions are often incorrect.

Discovery work exists to test assumptions before they become commitments. The goal is to identify what is viable, what is risky, and what should be ruled out while change remains inexpensive.

This page applies to organizations considering AI or automation but uncertain whether the proposed approach fits their actual operating constraints.

What discovery examines

Each engagement addresses one clearly defined problem area and evaluates it through several lenses.

1. Context and problem statement

Discovery begins by documenting the operating environment and the problem being evaluated. This includes:

• Organization type, size, and operational context (anonymized in deliverables).
• What triggered the evaluation.
• How stakeholders initially described the problem.
• What outcomes are expected or required.

This step exists to establish a shared understanding of the problem before evaluating solutions.

2. Initial assumptions

Most problems arrive with embedded assumptions about cause, solution, or approach. Discovery makes those assumptions explicit:

• What stakeholders believe the problem is.
• What solutions they assume are needed.
• What success is assumed to look like.
• What tools or approaches seem obvious.

Making assumptions visible allows them to be tested. Many discovery engagements conclude that the initial problem statement was incomplete or that assumed solutions do not address actual constraints.

3. Constraints uncovered

Real operating environments impose constraints that are not visible in demonstrations or vendor promises. Discovery identifies and documents:

• Data quality, consistency, and completeness.
• Volume and structure of information.
• Process variability and documentation gaps.
• Ownership, accountability, and decision authority.
• Compliance, audit, retention, or regulatory concerns.
• Integration dependencies and existing system limitations.

These constraints often determine what is viable more than tool capabilities do.

4. Options considered

Discovery evaluates multiple approaches, including both AI and non AI options. Options considered typically include:

• Process or documentation changes that reduce or eliminate the need for automation.
• Manual workflow adjustments.
• Simple search, indexing, or retrieval improvements.
• General AI assistance tools (chat based, summarization, drafting).
• Document based AI systems for question answering over existing files with minimal restructuring.
• Retrieval augmented generation where traceability or governance are required.
• Structured knowledge systems with versioning and audit controls.

Not all options are relevant to every problem. Part of discovery is determining which categories apply and which can be excluded early.

In most engagements, discovery significantly narrows this list rather than expanding it.

5. Options ruled out

This is often the most valuable section of a discovery engagement. Discovery documents:

• Why certain AI approaches are premature, risky, or inappropriate.
• Why automation increases complexity without solving the actual constraint.
• Why specific tools or platforms fail to address the real problem.
• Why seemingly obvious solutions introduce accountability or governance gaps.

Ruling out options early prevents wasted implementation effort and reduces long term risk.

6. Outcome of discovery

Discovery does not advocate for a particular solution. It clarifies what can proceed, what should wait, and what should not be attempted.

The outcome section documents:

• What could reasonably proceed given observed constraints.
• What depends on resolving specific gaps or uncertainties.
• What should not be attempted without structural or organizational changes.
• What decisions remain open and require additional clarity.

Discovery focuses on decision clarity, not on selling a next phase.

7. Open risks and unknowns

Discovery does not eliminate uncertainty. It surfaces it. The final section documents:

• Remaining areas of uncertainty.
• Dependencies that could change conclusions.
• External factors outside the scope of evaluation.
• Areas requiring future validation or testing before implementation.

Discovery engagements end with explicit ambiguity where it exists, not false closure.

Deliverable

The primary deliverable is a written discovery report.

The report documents findings across these areas in sufficient detail for the client to:

• Understand why certain options were ruled out.
• Evaluate remaining options with realistic expectations.
• Make informed decisions about next steps.
• Hand off findings to internal teams or third party implementers.

Deliverables are written reports, not slide decks, and are intended to be read, referenced, and reused.

The report is intended to stand on its own and remain useful regardless of whether the client proceeds with implementation, delays, or cancels the initiative entirely.

What discovery does not include

Discovery work is deliberately bounded. It does not include:

• Implementation, development, or deployment.
• Vendor selection or procurement support.
• Ongoing monitoring, maintenance, or operational support.
• Training, change management, or adoption planning.
• Expansion to additional use cases or systems.

These activities are considered separately and are not part of the discovery engagement.

When discovery is appropriate

Discovery consulting is most useful when:

• The problem is understood, but the right approach is not.
• Multiple tools or methods appear viable, but tradeoffs are unclear.
• There is concern about cost, long term maintenance, or operational risk.
• The organization wants to avoid premature commitment to a specific platform or approach.
• Previous attempts at AI or automation produced inconsistent or unreliable results.

Discovery is not appropriate when a specific product, vendor, or architecture has already been selected and the goal is execution rather than evaluation.

Discovery is complete when decision clarity is achieved, regardless of whether any further work follows.

Engagement structure

Discovery engagements are scoped and priced based on:

• The complexity of the problem being evaluated.
• The number of systems, processes, or data sources involved.
• The availability of documentation and subject matter expertise.
• The clarity of stakeholder expectations.

Scope, fee, and timeline are defined up front. Meetings are limited and used to clarify inputs, validate assumptions, and review findings.

This page documents discovery only. Consulting scope, including when discovery may precede implementation, is documented on the consulting page.

For inquiries, use the contact page.