Skip to content
VIGORLet’s talk
VIGOR

Independent thinking.
Connected engineering.

Delivery planning

How to scope a technology pilot that helps you decide

A practical framework for defining a software, AI or IoT pilot: choose one question, establish a baseline and agree what happens after the review.

The short answer

A useful technology pilot has one decision to inform, a bounded workflow, a named owner and agreed acceptance criteria. Define the evidence you need before deciding which features to build.

1. Name the decision, not just the demonstration

Start by completing this sentence: after the pilot, we need to decide whether to ____. The answer might be expanding a device connection, adopting an internal workflow or investing in a larger application.

“Show that AI works” is too broad to guide a useful evaluation. “Determine whether document extraction can reduce review time without missing required fields” defines a workflow, a user and something to measure.

2. Draw a boundary around the first slice

Specify the location, users, records and systems involved. One complete workflow with clear boundaries is often more informative than several incomplete features.

Write the exclusions as carefully as the inclusions. A pilot might test one equipment type, one department or one class of documents. It should not silently become a commitment to every future integration.

3. Establish the baseline and acceptance criteria

Record what happens today using representative examples. Agree who will judge the output and what constitutes an acceptable result, including the exceptions.

Use criteria that reflect the operational goal: time after review, missing records, recovery from a connection failure or successful completion of a task. A polished dashboard is an output; the ability to make a better decision is the outcome.

4. Make dependencies visible

List vendor access, data permissions, equipment availability, network constraints and stakeholder review time. Assign an owner to each dependency before the delivery window begins.

If a critical interface is unknown, discovering its feasibility may be the pilot’s primary purpose. A four-week plan only becomes credible when the assumptions behind it are understood.

5. Agree what happens at the review

Review the working scope and the evidence against the original question. Record limitations and any conditions that would change the result at a larger scale.

There are several useful outcomes: proceed, narrow the scope, run another specific investigation or stop. A pilot that prevents an unsuitable investment has still informed a decision.

Your planning checklist

  • Decision the pilot must inform
  • Workflow, users and system boundary
  • Baseline and acceptance criteria
  • Access, data permissions and named owners
  • Deliverables, exclusions and review date
Explore the VIGOR pilot approach

Apply this to your next project.

Tell us what you want to improve. We’ll help turn the problem into a practical engineering scope.

Discuss your project

Ask VIGOR

AI project conversation · Project discussion

AI assistant · Keep sensitive details private

Messages are processed by OpenRouter and its model provider. AI can make mistakes. Privacy details

What would you like to build?

Let’s find a useful first step.