Software rollout: prepare the work, support and adoption together

A software rollout changes how people perform tasks, exchange information and recover from problems. Installing the application and creating accounts are necessary steps, but adoption depends on whether the new workflow can be used in the conditions where the work actually happens.

Prepare the operational change alongside the technical release: name the tasks, permissions, handoffs, practice opportunities and support arrangements. Use a limited pilot to investigate unresolved conditions before expanding. Record who can approve that expansion and what would require a pause.

This guide is a practical rollout process for an ordinary workplace system. It connects to an existing change-readiness assessment, rather than supplying a universal go-live score. Technical assurance, security and the safeguards specific to the service still need their appropriate owners.

Define the change in terms of completed work

“Deploy the ticket system to all staff” describes distribution. “A coordinator can register a repair, a mechanic can identify the agreed work and the next shift can find the current status” describes usable work. Begin with the second kind of statement.

List who begins a task, what they need, which decision they make and who receives the output. Identify normal cases and consequential exceptions. Include absence, interrupted connectivity, an incorrect record and a request that needs an authorised decision. Do not define success solely as a login or a completed course.

Prosci distinguishes individual change through Awareness, Desire, Knowledge, Ability and Reinforcement in its ADKAR model. That provides a vocabulary for support conversations, not evidence that sending a launch message and training invitation establishes adoption. Our ADKAR guide explains its scope and limitations.

The rollout should also identify the old routine being replaced. Otherwise colleagues may have to maintain the new system alongside the existing spreadsheet indefinitely. If overlap is needed during transition, specify the authoritative record, reconciliation responsibility and the condition for ending duplication.

Map the work before configuring the software

Consider a hypothetical bicycle repair business with two workshops. It plans to replace paper repair tags and emailed updates with a shared ticket system. Coordinators book work, mechanics record progress and a duty lead approves changes to the agreed repair. Customers still arrive or telephone, so the service spans several channels.

Map one repair from the first contact to collection. A journey map can show the customer’s experience, while a service blueprint exposes the internal handoffs and support needed to deliver it. The rollout team should discuss both with the people doing the work.

In the invented business, a mechanic often discovers an additional problem after inspection. The ticket must show that approval is pending, and the coordinator needs to know who will contact the customer. A status field called “in progress” cannot by itself explain that boundary.

Agree these meanings before finalising configuration. Define the minimum information needed to hand a repair over, who may update it and which decisions the system records without authorising. Technical convenience should not quietly move decision rights from the duty lead to whoever can click a button.

Use stakeholder mapping to include reception cover, part-time mechanics and the colleague managing parts. A pilot composed entirely of confident desk users may miss the main constraints of using a tablet beside a repair stand.

Treat permissions and workplace conditions as prerequisites

Check accounts, devices, access, connectivity and the physical setting. Can a mechanic reach the tablet without abandoning an unsafe operation? Is the interface usable with the assistive technology a colleague needs? Can another workshop see the information required for an agreed transfer? Who handles a locked account on an early shift?

The original COM-B paper considers capability, opportunity and motivation together when examining behaviour. Applied here, knowing the new procedure is a capability condition; a working device and permission to use the record are opportunity conditions. This is a workplace adaptation, not a validated rollout diagnostic.

In the fictional workshops, the team might discover that a shared tablet locks whenever the coordinator leaves the desk. That calls for an approved access arrangement, not another lesson for the mechanic. If the parts database updates overnight, a training slide cannot make current stock visible during the afternoon.

Give each prerequisite an owner and a demonstration. “Access ready” should mean the actual role can complete the required task in the intended environment. A named technical owner confirms the access arrangement; an operational owner confirms that the task and authority remain correct.

Build practice around the tasks people must perform

Use realistic scenarios with invented or appropriately protected data. Ask a coordinator to register an ordinary repair, correct a mistaken entry and route a consequential exception. Ask a mechanic to locate the agreed work, record what changed and explain when to stop for approval.

Demonstrate a task, let the learner attempt it and give feedback on the task rather than on their confidence. A fluent presenter can create the impression that the workflow is obvious. An independent attempt exposes missing terminology, confusing defaults and assumptions about local knowledge.

Build a task-based competency map when roles require different preparation. A receptionist covering a busy lunch period does not need the same configuration skills as the administrator. Both need the handoffs and escalation routes their work requires.

Keep a short, maintained reference within reach of the task. It should explain the action, the meaningful exception and where help comes from. Make the difference between a product defect, a permission issue and an unresolved process decision visible in the support arrangement.

Protect an opportunity to use the learning soon afterwards. Our learning-transfer guide explains how supported practice and working conditions connect training to later use. An attendance record should remain an attendance record, not be relabelled proof of competence.

A hypothetical bicycle-workshop rollout

The invented business chooses one workshop and the routine daytime repairs for the first pilot. It deliberately includes a coordinator, two mechanics with different working patterns and reception cover. The duty lead remains available for approvals; an administrator covers access problems.

The team rehearses a case where a customer telephones with an urgent request while the coordinator is updating another repair. The coordinator must find the right record, preserve the original agreement and ask the duty lead to make the priority decision. The software is only part of the task.

Suppose rehearsal reveals that closing the edit screen discards an unfinished note without a clear warning. It also reveals that the duty lead cannot see an approval request from the workshop tablet. The first problem belongs to product configuration or design; the second may involve access and workflow. Neither should be recorded simply as “staff need more training.”

The pilot proceeds only after the relevant owners confirm an acceptable arrangement. Its purpose is to investigate ordinary use under bounded conditions, not to achieve a launch date at any cost. A premortem before the trial can expose additional recovery questions while there is still time to change the plan.

Give the pilot an observation and recovery plan

GOV.UK’s beta-phase guidance describes inviting limited numbers of users, gathering feedback and preparing support before moving to larger use. Its government-service process is not a prescribed sequence for this workshop; the relevant principle is learning while exposure is bounded.

Write the questions the pilot must answer. Can both shifts retrieve the current repair status? Can a colleague handle the agreed exception with available support? Does the new routine create duplicate recording elsewhere? How much additional help is required, and who provides it?

Use a compact decision record:

Area	Evidence to collect	Owner and response
Task completion	Observe an eligible repair from registration to handoff	Service owner resolves process gaps
Exceptions	Review attempted corrections and approval requests	Duty lead confirms decision boundaries
Access and reliability	Record failures by role, device and shift	Administrator routes and resolves technical issues
Workload	Examine duplicate entry and time spent seeking help	Workshop manager adjusts capacity or scope
Recovery	Rehearse the agreed fallback and later reconciliation	Operational and technical owners confirm the route

Define stopping conditions before starting. For example, an untraceable repair, repeated loss of an agreed record or an unavailable essential approval route should trigger the agreed recovery process. Exact thresholds depend on the consequences and the safeguards for the service; this table does not validate them.

Recovering the work involves more than restoring a screen. Decide how transactions completed during an outage will be reconciled, who checks for omissions and how colleagues learn that normal use has resumed. Keep one authoritative route for each state so that a fallback does not create an uncontrolled second system.

Connect support to the rollout decision

Support needs opening times, available people, escalation responsibilities and a way to report recurring issues. A messaging channel can receive questions, but someone must decide whether a question indicates a defect, confusing instruction or unresolved policy.

Government Digital Service’s user-support guidance treats support feedback as input to service improvement and warns against isolating support from the rest of the organisation. For our example, the administrator and workshop manager should review the same issue record.

Suppose the hypothetical pilot shows that afternoon mechanics repeatedly ask who can change a promised collection time. Updating the reference may help, but the service owner must first agree the authority. Closing each help request without that decision would hide the recurring problem.

Report what changed and where the current answer lives through the change communication plan. Include colleagues who were away and the people about to enter the next rollout group. Check that a revised instruction has reached the people who received the earlier one.

Decide whether to expand, revise or hold

Hold a review with the technical owner, service owner and representatives of the people doing the work. Compare the evidence with the original task outcomes. Ask which conditions were absent from the pilot, including a busy shift, a transfer between workshops or a different accessibility requirement.

Separate adoption from benefit. A high proportion of eligible repairs recorded in the system shows use. It does not establish faster repairs or better customer understanding. Government Digital Service’s benefits guidance recommends connecting intended benefits to evidence. Choose the benefit measure and a meaningful baseline before claiming improvement.

Expansion should specify the next group, prerequisites, support capacity and review point. A successful demonstration by the first group is evidence about those people and conditions. It is not a reason to remove support from the next group or delete the fallback before the transition is dependable.

Evidence and limits

This playbook combines institutional service guidance, an individual-change model and a behaviour framework. Those sources support the distinctions used here; they do not establish this exact sequence as an independently validated rollout method. The bicycle business, rehearsal findings and decisions are hypothetical.

Some systems require specialist assurance beyond an ordinary workplace pilot. A technical or legal requirement cannot be replaced by an informal adoption check, and a small pilot must retain the applicable controls. Use the right accountable people to set those boundaries.

A rollout is ready for its next step when the required work, support and recovery arrangements are credible within the stated scope. Keep the evidence and unresolved conditions visible so that approval is a reasoned operational decision, rather than a date inferred from completed installation tasks.