A pilot’s overall success rate can conceal a fault that matters across the wider device estate. Two failures on the same configuration may deserve more attention than dozens of successful installations elsewhere. Add devices awaiting a restart or missing reports, and the case for expansion becomes less clear.
Deployment plans should distinguish those outcomes. The plan sets out the rollout sequence and controls; each stage produces evidence for deciding whether the next should proceed.
Check that the pilot represents the next group
A phased rollout applies ITIL deployment management by introducing changed software to one group before expanding to others. Choose the early devices to cover configurations that matter in the next group.
For an application update, relevant differences might include operating-system versions, older hardware, remote connections and installed add-ins. A pilot consisting entirely of IT staff’s recently configured laptops could leave important combinations untested.
Record which pilot devices cover each combination. Where coverage is missing, add suitable devices or keep that configuration out of the next stage until it has been checked. Prioritise filling relevant gaps over simply increasing the device count.
Separate verified outcomes from missing evidence
Define success before deployment begins. For a desktop application, this could mean confirming the intended version, completing any required restart and checking that the affected function still works. A completed distribution task may establish only that the package was delivered.
At each review, separate verified successes, confirmed failures, pending checks and devices with no current report. Assign each device to one category at that review point so the totals reconcile with the target population. Record the evidence source and collection time alongside the counts.
Treat an unreported laptop as an unknown outcome and investigate whether it was offline, outside the target group or affected by a reporting problem.
Then examine results by configuration. A cluster of failures among devices using the same add-in deserves investigation if that add-in is widespread in the next group, even when the overall figures look favourable.
Define expansion and stop conditions before deployment
Specify both the observation period and what must happen during it. Waiting until tomorrow offers little reassurance if nobody has restarted the devices or used the changed function. Allow time for relevant activity, then identify who will review the results before expansion.
Keep scheduling separate from approval. A timed activation can advance a rollout regardless of whether anyone has assessed the evidence. Confirm that the rollout mechanism supports the intended hold point, or schedule a review early enough to prevent the next activation if necessary.
Set progression conditions for the particular change rather than adopting a universal success percentage or waiting period. Conditions could include coverage of relevant configurations, investigation of repeated failures and resolution of unexplained faults that block essential tasks.
Distinguish pausing from recovery, too. Pausing expansion leaves completed installations in place, while already assigned work may continue depending on the system. Check that behaviour beforehand. Where reversal is feasible, identify the tested backout procedure and approved previous version before starting. Otherwise, specify the corrective route and its owner.
Record the decision and the next action
Consider a hypothetical desktop application update involving 100 pilot devices. Its agreed stop condition is an unexplained task-blocking fault in any configuration included in the next group.
A compact decision record could read:
- Evidence at 14:00: 96 devices have the intended version and have passed the required checks; two failed the post-installation check; one awaits a restart; one has not reported.
- Failure pattern: Document processing is blocked on both affected devices, which share an add-in also used in the next group. The cause remains unconfirmed.
- Decision and owner: The deployment owner pauses expansion because the agreed stop condition has been met. The two affected devices are assessed separately for recovery under the prepared procedure.
- Next review: The application team investigates the failures. Reassessment requires a successful retest on the affected configuration, completion of the outstanding restart check and an explanation of the missing report.
Link the record to its underlying evidence and identify the package version assessed. If remediation changes the package, record the new version and review which earlier results remain relevant.
Here, the repeated fault matters more than the headline count of 96 verified successes. The decision record preserves that reasoning and gives the next operator a starting point: what stopped expansion, who owns the follow-up and what evidence would justify proceeding.