How to plan an enterprise software pilot without disrupting operations

A pilot is a decision instrument

An enterprise software pilot is not a small rollout with an optimistic name. It is a bounded experiment designed to answer a decision that cannot be resolved through documentation and demonstrations alone. The scope, users, data, controls, duration and exit must be explicit before the first account is created.

Write the decision in one sentence: proceed, revise, repeat or stop based on defined evidence. Select the few assumptions most capable of overturning the preferred option. A useful pilot might test identity and access, a complex user journey, data quality, administration effort, integration behaviour, accessibility or recovery.

The pilot succeeds when it reduces uncertainty, including when the answer is no. Adoption numbers without a baseline, a friendly volunteer group or a demonstration in a supplier environment may create activity but cannot support an operating commitment.

Choose the riskiest assumptions, not the easiest features

List the assumptions behind value, feasibility, usability and control. Rank them by impact and current uncertainty. Test the high-impact unknowns that can still change the decision. Avoid spending the pilot proving basic features already supported by reliable documentation while integration, data or operating risks remain untouched.

The GOV.UK guidance for the alpha phase recommends focusing on the riskiest assumptions and building only enough to test ideas. An enterprise product pilot is not a government alpha, but the principle prevents a broad trial from becoming an expensive rehearsal for a decision already made.

Write an evidence statement for each assumption. “The integration works” becomes “a user can create, change and cancel the priority transaction through the existing identity and calendar environment without duplicate records”. The statement names what must happen and where evidence will come from.

Bound scope without creating a toy environment

Use a small but representative slice: one location or process, several user roles, a normal journey, important exceptions and the real administration path. Include people who are not enthusiastic early adopters. A pilot made only of project champions can reveal product capability while hiding ordinary confusion and resistance.

Keep the environment safe but realistic. Use approved non-production or minimised data, the intended identity controls and representative integrations. If a critical integration cannot be tested, record that limit and avoid presenting the pilot as proof of end-to-end feasibility.

Define what is outside scope and how excluded dependencies affect interpretation. A single office may not represent every network condition. A small catalogue may not expose performance or migration complexity. Boundaries make evidence usable when they are visible; hidden boundaries turn positive results into overclaims.

• Representative user roles, including support and administration.
• Priority journey plus meaningful exception and recovery cases.
• Realistic identity, policy and integration conditions.
• Approved data with minimisation, retention and deletion rules.
• Named exclusions and limits on what the pilot can prove.

Set measures and stop rules before launch

Choose measures tied to the decision: successful task completion, time to resolve an exception, support requests by cause, data reconciliation, policy compliance, administrative effort and user understanding. Collect a baseline where comparison matters. Define the sample and period so a percentage cannot float free of its context.

Set thresholds for proceed, revise, repeat and stop. Include qualitative blockers such as an inaccessible journey, unexplained data loss or a control the service owner cannot operate. Do not allow a high average score to cancel a failure that affects a critical role or obligation.

Give the steering group permission to stop. Name who can pause access for security, privacy, safety or operational reasons and how evidence will be preserved. A stop rule is not pessimism; it is what keeps a pilot reversible while the organisation is still learning.

Prepare users, support and change control

Explain the purpose, duration, included tasks, data rules and support route to every participant. Provide task-based guidance rather than a generic product tour. Tell people how to report a problem and make clear that feedback is evidence, not a test of their willingness to cooperate.

The GOV.UK beta guidance emphasises limited users, feedback, iteration, success metrics and enough support capacity for unexpected difficulty. The context differs, but a private beta offers a useful model for learning with real users before a service is expected to operate at scale.

Create a short change log for configuration, workflow and guidance. If the pilot changes halfway through, record the reason and the evidence affected. Otherwise results from different configurations may be combined as though participants experienced the same service.

Run scenarios and observe the work

Observe people complete priority tasks in the environment they will actually use. Capture where they hesitate, leave the workflow, seek help, duplicate data or create a workaround. Ask what they expected after the task rather than treating completion as the only signal.

Test operational events deliberately: a permission change, failed integration, unavailable resource, duplicate record, temporary closure, support escalation, export and user removal. The normal path shows product capability; exceptions show whether the organisation can govern and support the service.

Keep supplier assistance visible. Record which tasks required specialist intervention and whether an internal owner could repeat them. A successful outcome completed by the vendor may still expose an operating gap if the proposed contract does not include that level of support.

Review evidence without moving the goalposts

At the review, present the original question, boundaries, measures, configuration changes, results, incidents and participant coverage. Show missing evidence beside positive findings. Do not add new success criteria only because the preferred option performed well on them.

Use the vendor evaluation scorecard to update previously unproven criteria and risks. Use the workplace technology ROI framework where the pilot is intended to support a value decision. Keep evidence from the real environment distinct from vendor documentation and estimates.

Decide proceed, revise, repeat or stop. Proceed may still include conditions. Revise means the solution or operating design changes before more testing. Repeat needs a specific evidence gap, not general discomfort. Stop should record what was learned so the same assumption is not rediscovered in the next procurement.

Close the pilot before scaling

Remove temporary accounts, access, integrations and data according to the plan. Confirm exports and deletion, collect owned documentation and close temporary support routes. If access remains for continued use, make that a new approved state rather than allowing the pilot to drift into production.

Create a scale brief that names the approved scope, unresolved dependencies, service owner, support model, migration approach, controls, measures and next gate. Link it to the site’s ERP implementation pathway or operating process so the product decision becomes part of a controlled change.

A strong pilot leaves less ambiguity and no accidental service. It makes the next commitment smaller, clearer and owned. That is more valuable than a celebratory usage number that cannot explain whether the software fits the work, controls and support model it is expected to enter. Keep the evidence pack with the decision record so implementation teams can see what was tested, what was excluded and which conditions must be verified again at scale.