Support & operations · Practice guide

Agree what a software update must achieve before building it

Illustrative situation

A software update is described as improving the dashboard, but nobody has specified what a user should be able to do differently or how errors will be handled. Improving a screen is too vague to judge after delivery. Describe what the user should be able to do and what should happen when information is missing or access is restricted. Clear acceptance protects both the practice and supplier from avoidable disagreement.

Healthcare website support desk with a system checklist, telephone and orange notebook.
Know who to call and what help your support arrangement includes.

What this means for your practice

Describe what the user should be able to do after the update and what evidence will show it works. Include missing information, errors and restricted-access cases before building begins.

An example to discuss with your team

Give the criteria to a reviewer who did not build the feature and ask them to design a pass-or-fail check from the wording.

Healthcare website maintenance with infrastructure, a status panel, tools and an operational checklist.
Monitor the useful journey, not just whether a server responds.
Healthcare backup and recovery illustrated by storage copies, an archive folder and a restoration route.
Test whether a backup can restore a usable service.

How to review the arrangement

Give the brief to someone who did not build the change. Can they recognise success and failure? Use a real task, such as finding an unanswered enquiry, rather than an adjective such as easier. Agree the evidence before implementation so the review focuses on behaviour that matters.

Describe success in a task someone can observe

Choose the person who will use the change and describe what they should be able to finish. For a dashboard update, that might mean finding unanswered enquiries for their clinic and identifying the next action. Explain the expected result when there are no matching records or the person does not have access to a wider view.

Ask the supplier to demonstrate the proposed behaviour before building where a simple sketch or prototype will help. Agree which examples will be used during review, including the important awkward cases. Keep the criteria understandable to the practice colleague who will accept the work. If an assumption changes, update the brief rather than leaving two competing versions of success. At delivery, follow the agreed examples and record any remaining issue. A clear acceptance conversation makes it easier to distinguish a genuine defect from a new request that was not part of the original change.

How to check the result

Track releases delayed by ambiguous acceptance criteria.

Turn reading into a next step

Your action checklist

Work through these checks with your team or supplier. Tick the ones you have resolved and leave unknowns open.

Checks to discuss

Record what you know, what is still missing and the answer you need from your team or supplier.

Use project decisions only, without personal, patient or confidential details. Entries stay in this page and are not submitted to Kay & Co. Copy or download before leaving; this page does not save your notes.

Further reading

These sources provide background for the topic. The practice examples and checklist are illustrative planning suggestions from Kay & Co.

Related guides

Need help with this?

Tell us what is getting in the way. Kay & Co. can help you understand the options and turn the next step into something that works for your practice.

Explore support & operations services or discuss your project.

Try the free Healthcare Digital Planner to find your starting priority.