A pilot is a purchasing decision tool. It should show whether the source data, interpretation rules, delivery workflow and review effort are suitable for the larger project. Agree its price, scope and decision criteria before sending the sample.
Choose a sample that can reveal problems
Include ordinary production plus known difficult areas. For LiDAR, that may include steep ground, vegetation, bridges and variable density. For imagery or CAD, include occlusion, complex geometry and ambiguous features. No single tile represents every land cover or acquisition condition.
- List the conditions represented by the sample and the conditions it does not cover.
- Include adjoining tiles or features when continuity matters.
- Supply accepted examples and known defects, rather than hiding relevant context.
Write the decision criteria before production
List each output with its format, required attributes, reference system and acceptance method. Distinguish whole-package checks from sampled review. Choose thresholds appropriate to the intended use and source quality; there is no universal pass percentage for every GIS production task.
- Set the pilot delivery date, review window and included correction cycle.
- Assign a client technical reviewer and a production contact.
- Identify issues that prevent acceptance and exceptions a client may explicitly accept.
Capture interpretation decisions
Record the questions raised during production and the agreed answer, with a feature or tile reference. Save the accepted files and decision log as a versioned baseline. Later changes should name the affected outputs and trigger a review of time, cost and rework.
- Use stable issue IDs and evidence such as coordinates or annotated screenshots.
- Distinguish corrected defects from unresolved source limitations.
- Record who approved each exception and when the baseline changed.
Measure the buyer’s effort as well as throughput
Track how much time your team spends reviewing, explaining corrections and loading the result. Record quantities and their context: a number of corrected tiles is not meaningful without the number reviewed and the review method. A pilot estimates a workflow; it does not prove sustained production capacity.
- Reviewer hours, questions raised and resubmission cycles.
- Files or features reviewed, defects by type, and unresolved limitations.
- Successful import into the target application and any manual cleanup.
- Elapsed turnaround alongside active production and client-wait time.
Make an explicit scale-up decision
At the close of the pilot, choose to proceed, revise and retest, or stop. If you proceed, agree batch sizes, handover dates, review coverage, escalation and capacity. Recalibrate when source conditions, staff assignments or specifications materially change.
- Proceed only against the accepted output and decision baseline.
- Carry known limitations into the production scope.
- Agree how unresolved issues affect each batch’s release.
- Confirm access and retention arrangements for the larger dataset.
Put the checklist to work
Use the editable templates to record your project requirements and delivery review. Adapt them to the applicable contract and specification.