Digital change that works: stakeholder engagement and product adoption

1. Map people, decisions and dependencies

Purpose: Understand whose work can affect the transition.

A stakeholder is someone who affects the work or is affected by it. Include users, managers, developers, support, security, accessibility specialists and suppliers where relevant. A dependency is something your work needs from elsewhere, such as an access decision or a supplier release.

For each group, record the change to its work, the decision it owns, the support it needs and the dependency it creates. Ask who is missing, particularly people on different shifts or with access needs.

Review the environment during delivery. A related team changing its data source or a supplier moving its release date can alter your plan even when your own development remains on track.

2. Design engagement around a useful decision

Purpose: Make each conversation relevant to the people involved.

Users need to try realistic tasks and explain where the process becomes difficult. Support colleagues need to rehearse common problems. A sponsor may need to decide whether to reduce scope or move a date. These are different conversations.

State the purpose, evidence and decision needed before a meeting. Afterwards, record the outcome and follow through on commitments. Keep a route for people who cannot attend to contribute.

When stakeholders disagree, make the competing needs visible. If operations wants a gradual rollout and a sponsor wants rapid coverage, compare the options using agreed readiness criteria, available support and the consequence of delay. Confirm who has authority to decide.

3. Walk the journey from discovery to completion

Purpose: Remove avoidable effort while retaining necessary controls.

Follow a new user through finding the product, requesting access, completing a task and obtaining support. Include the steps outside the interface, such as manager approval or a supplier account request.

• Is there one reliable starting point and a clear description of who the product is for?
• Can people understand the access steps and see who owns an outstanding request?
• Are instructions accessible and organised around real tasks?
• Can users recover from errors without repeating work unnecessarily?
• Is the support route visible at the moment it is needed?

Keep required security and approval controls. Look for duplicated forms, ambiguous instructions and unnecessary hand-offs that make those controls harder to navigate. Reducing friction means removing avoidable obstacles from a legitimate task.

4. Pilot the complete working process

Purpose: Check readiness before expanding the change.

Choose a pilot group that reflects important differences in users and tasks. Include people who are less familiar with the product and those with relevant accessibility needs. Explain what the pilot is testing and how feedback will be used.

In the fictional booking service, ask users to reserve equipment, amend a booking and deal with an unavailable item. Ask support to handle an access problem and a failed update. Include the supplier if its response is needed for recovery.

Agree criteria for expanding, pausing or adjusting the rollout. Prepare a fallback that explains who can authorise it and how records will be reconciled. Running two processes indefinitely can create its own confusion, so make the transition arrangements explicit.

5. Learn from workarounds after launch

Purpose: Use adoption evidence to decide what to improve.

Logins show entry to the application. Look further: can eligible users complete the task, how often do they need help, and what work continues elsewhere? Compare experiences across user groups without turning support needs into a judgement about individual performance.

If people keep the spreadsheet, ask what it gives them. Training may help when someone lacks confidence with a task. Missing functionality, inaccurate information or unclear accountability requires a different response.

Assign an owner for reviewing feedback, incidents and adoption measures after the initial project work ends. Tell users what changed because of their input, what still needs investigation and when they will hear more.

Bring evidence to the rollout decision

Purpose: Identify what is ready, what needs work and who will act.

• People: affected groups have been identified and involved in realistic tasks.
• Access: intended users can find the product and obtain the correct permissions.
• Workflow: the new process, responsibilities and transition arrangements are understood.
• Dependencies: connected teams and suppliers have confirmed the actions needed.
• Support: common problems and escalation routes have been rehearsed.
• Evidence: completion, errors, support demand and workarounds can be reviewed.
• Decision: an accountable person can expand, pause or adjust the rollout.

For each point, record the evidence, the gap and a named action owner. A list of green labels without supporting evidence will not help you decide whether users are ready.

Start with one task this week. Observe where someone waits, repeats information or asks for clarification. Use that observation to agree one concrete improvement with the people who own it.