When work is delayed, a new platform can feel like a fresh start. It may help if the current tools lack a necessary capability. It may simply move the same unclear responsibilities into a more attractive interface. Follow one real request through the existing process before deciding which problem you are buying a tool to solve.
Choose a representative completed task and, if possible, a delayed one. Work with authorized records and the people involved. The aim is to understand the process, not to collect examples that make one team member look responsible for every delay.
Draw the route the request actually took
Record where it arrived, who assessed it, what information was required, where it waited, and how the outcome reached the requester. Include informal messages and spreadsheets only when they are genuinely part of the work. A tidy official diagram can miss the steps people rely on every day.
At each handoff, ask what the receiving person needed to begin. Was the request complete? Was its priority clear? Did they know they were the owner? Did they have permission to act? These questions distinguish a missing feature from a missing agreement.
Give the delay a concrete description
Replace statements such as the system is bad with observations. For example: requests lack a delivery date; two people reply because assignment is invisible; approval waits because nobody knows the authorized approver; or the export omits a required field. Each observation suggests a different remedy.
The GOV.UK discovery guidance emphasizes understanding the problem and constraints before assuming a new service must be built. For a small workflow, the same discipline helps prevent a software purchase from becoming the definition of the problem.
Try the smallest process correction that can answer the question
If requests repeatedly lack information, a clearer intake form may be worth testing. If ownership is unclear, an explicit assignment rule may help. If the approved process requires a capability the current tool cannot provide, document that requirement for the product comparison.
Keep the correction within the team's authority and information-handling rules. Do not create an unofficial database of sensitive records to avoid an inconvenient approved system. A trial should reduce uncertainty without introducing an unmanaged operational dependency.
Measure the whole task
Record a small set of useful observations: time waiting for missing information, number of handoffs, repeated questions, or requests reopened because completion was unclear. Choose measures that describe the identified problem. Counting clicks or messages can be misleading if fewer of them simply means work is being skipped.
For an illustrative team, adding a required delivery-date field might reduce the number of follow-up messages while leaving approval delays unchanged. That result is useful. It shows that one problem improved and another remains. It does not prove that the entire workflow is fixed or that the form has failed.
Turn remaining gaps into product requirements
After the process trial, list capabilities still missing: assignment visibility, auditable approval, a required integration, accessible input, or a particular export. Separate must-have requirements from preferences. Ask candidate vendors to demonstrate the complete workflow with appropriate sample data.
Include migration, permissions, ongoing administration, and exit options in the comparison. A tool that solves the visible screen problem while making data transfer or ownership unclear may shift the difficulty rather than remove it. Estimate the effort of transition without pretending every future cost is known.
Keep the human agreements explicit after purchase
If you choose a new tool, carry the resolved responsibilities into its setup. Name who triages, who owns a request, who approves exceptions, and what closes the work. Configure the product around those agreements where it supports them instead of hoping its default labels will settle the questions.
Check the real workflow after launch. A completed setup checklist is not evidence that requests reach the correct person and finish successfully. Follow another task from beginning to end and compare the actual failure points with the original record.
You may conclude that the current tools are sufficient, that a focused change is enough, or that a new platform is justified. Each is a useful result when it follows the evidence. The goal is a request that arrives with enough information, reaches an authorized owner, and ends with a clear outcome. Software should support that route, not stand in for defining it.
Sources
- GOV.UK: How the discovery phase works
Understand the user problem and constraints before assuming that a new service must be built.