Process

A process designed to reduce risk and scope drift

Six phases, each with a defined deliverable and a risk it answers for. Few engagements run all six — most start at phase one or two and stop where the value is delivered.

The six phases

Each phase has a deliverable and a risk it answers for

Assess readiness

Clarify goals, identify the first use case, review data handling requirements, and determine whether the organization is actually ready to move forward.

Deliverables

Use-case shortlist with prioritization rationale
Data sensitivity and access inventory
Stakeholder map with named owners and decision-makers
Go / no-go recommendation with reasoning

Risk this phase answers for

Funding a pilot before the use case is real, before data access is achievable, or before an internal owner is in place.

Define the deployment model

Select the right infrastructure pattern and access model based on sensitivity, scale, operational maturity, and support expectations.

Deliverables

Deployment model decision: on-premises, private cloud, or controlled hosted
Model and runtime selection rationale (open-weight, private endpoint, or hybrid)
Data-flow diagram covering ingress, retrieval, model, logging, and egress
Vendor and tooling shortlist with explicit trade-offs

Risk this phase answers for

Picking infrastructure that violates data-residency or contractual constraints, or picking a model the team cannot operate.

Design the control set

Document permissions, logging boundaries, content sources, review flows, and operational responsibilities before any rollout work begins.

Deliverables

Identity and access design with role-to-use-case mapping
Logging, retention, and redaction policy
Retrieval policy: trusted sources, ACL enforcement, freshness rules
Change-control and approval workflow
Threat model with named risks and mitigations

Risk this phase answers for

Building the environment first and bolting on controls later — which never produces a reviewable design.

Build the pilot

Implement a controlled first environment with narrow scope, measurable validation criteria, and clear admin and user paths.

Deliverables

Working pilot environment integrated into an existing tool surface where possible
Evaluation harness with use-case-specific acceptance criteria
Admin console or operating dashboard
Documented test runs against the acceptance criteria

Risk this phase answers for

Shipping a demo instead of a system. Demos win meetings; controlled pilots withstand scrutiny.

Train and operationalize

Deliver runbooks, enable admins and users, and define how the environment will be governed and supported after launch.

Deliverables

Operational runbook covering routine tasks, escalation, and rollback
Admin and reviewer training material
End-user onboarding with realistic prompts and known failure modes
Governance cadence and ownership document

Risk this phase answers for

A working pilot with no documentation, no owner, and no operating model — the most common failure pattern.

Review and expand

Tune the environment, address issues, and expand only after the first use case is stable, useful, and supportable.

Deliverables

Post-launch review with documented findings
Tuning plan for retrieval, prompts, and evaluation
Use-case expansion roadmap with prerequisites for each
Policy and logging refresh on a defined cadence

Risk this phase answers for

Expanding scope before the first use case is reliable. The fastest way to lose credibility is to broaden adoption while the foundation is unstable.

Typical timeline

What a full path looks like end-to-end

Typical ranges, not guarantees. Actual duration depends on data-access complexity, integration count, and how mature internal review processes are.

Phase	Typical length	Engagement shape
Assessment	2–4 weeks	Fixed-fee, defined deliverables
Deployment model + control design	2–4 weeks	Often bundled with pilot
Pilot build and validation	6–12 weeks	Scoped project, narrow use case
Operational handoff	1–2 weeks	Documentation, training, ownership
Expansion and review	Quarterly cadence	Retainer, optional

Anti-patterns

What goes wrong without this discipline

The phases are not bureaucracy. Each was added because skipping it produced the same failure mode in practice.

Skipping readiness

Jumping straight to a build without a candidate use case, named owner, or data access plan. Almost always leads to a stalled pilot that nobody owns.

Treating governance as a follow-on

Deferring access design, logging, and change control until after launch. The retrofit costs more than the original build.

Confusing demos with validation

A working demo proves the model can answer a question. A validated pilot proves the system meets acceptance criteria the business cares about.

Broad rollout before stability

Expanding adoption while the first use case is still being tuned. The result is a wider user base of frustrated people and an environment that is harder to fix.

Not sure which phase to start at?

Discovery includes a starting-phase recommendation. Often that is an assessment; sometimes it is a scoped pilot if the use case is already clear; sometimes it is a fit-and-defer.

Book discovery Service models