Give a pilot a clear finish line.

1. Name the question the pilot should answer.

Begin with the problem and the change you want to evaluate. Replace a broad ambition such as modernize our operations with a question about one workflow: can an agreed set of intake information reach the right reviewer without being copied between tools?

Write down the current baseline, the intended improvement, and who will judge the result. Treat the desired improvement as a target to test, not a promise.

Choose the decision the evidence will support: adopt the workflow, revise it, extend it, or stop. A pilot becomes difficult to finish when every demonstration raises a new question and none has priority.

2. Define one complete path through the work.

A small project still needs to be useful from beginning to end. Pick the users, starting event, inputs, and output needed for that path. Include the important failure cases that could make the first version unsafe or unusable.

• In scope: the workflow, users, source systems, and agreed outputs.
• Out of scope: adjacent workflows, additional integrations, and later ideas.
• Dependencies: access, subscriptions, sample data, and decisions required from others.
• Constraints: data handling, operating hours, hosting, and who maintains the result.

3. Make done something you can observe.

Acceptance criteria describe behavior that a reviewer can check. Include normal cases, incomplete inputs, and exceptions. Agree on representative test data and who has the authority to accept the work.

Separate a functional acceptance check from a business measure that needs time to observe. A workflow can pass its tests before there is enough evidence to judge its long-term effect.

• A complete input reaches the correct destination with the agreed information.
• Missing or conflicting information creates a visible review task.
• A failed connection is visible to an owner and has an agreed recovery step.
• A repeated action does not create an unintended duplicate outcome.
• The reviewer can explain what happened using the available status or records.

4. Make the cost assumptions explicit.

A useful proposal separates implementation work from third-party subscriptions, hosting, usage charges, and optional ongoing support. Ask which costs are one-time, which recur, who pays them, and what level of usage the estimate assumes. A fixed scope still needs clear assumptions about access, source data, and review effort.

Integration count alone is a poor guide to complexity. One system with incomplete records, restricted access, or unreliable exports may take more investigation than several well-supported tools. Data cleanup, permission design, exception handling, and historical migration should each be discussed rather than absorbed into a vague promise to connect everything.

Compare proposals against the same acceptance criteria and handover expectations. If the budget needs to be smaller, reduce the number of workflows, user groups, or source systems before removing the checks that make the selected workflow dependable.

5. Agree on review and change decisions.

Set a review rhythm and name one person who can resolve scope questions. At each demonstration, compare the work with the agreed criteria. Keep a separate list for useful ideas that are outside the pilot.

When a new request affects effort, timing, or dependencies, make that tradeoff explicit before adding it. Agree on the change, exchange it for another item, or defer it.

Choose where scope notes, feedback, and acceptance decisions will live. A shared written record plus scheduled demonstrations gives both the builder and the workflow owner something concrete to review. Confirm access and availability at the start; a waiting approval can delay work just as much as a technical dependency.

6. Plan what happens after the demonstration.

Include operating notes, appropriate access, known limitations, and a recovery or rollback approach where needed. Name who owns the workflow after handover and how future issues or changes will be handled.

Have the future operator run a normal case and an exception using the notes. Gaps discovered here are easier to resolve while the project team is still together. Confirm what support is included in the agreement and what would require separate work; ongoing care should have a defined purpose and boundary.

• Operating notes: how to start, review, pause, and recover the workflow.
• Ownership: who controls accounts, billing, access, and future decisions.
• Limitations: unsupported cases, expected review, and known dependencies.
• Maintenance: update responsibilities and how an issue is reported.
• Acceptance record: the checks performed, unresolved items, and the agreed next step.

7. Close the pilot with a decision.

Compare the demonstrated behavior with the agreed checks. Then review any available business evidence separately: preparation time, correction volume, or another measure chosen at the start. State where the observation period is too short or the sample is too small to draw a useful conclusion.

Choose whether to adopt the result, revise a specific part, investigate further, or stop. Record the owner and the evidence needed for any follow-up. A pilot that reveals an unsuitable approach can still be useful when it prevents a larger commitment based on an untested assumption.