Automation projects can disappoint even when the software performs the requested action. The action may solve the wrong problem, create additional review work or fail when the surrounding process changes.
The ten checks below help a team examine a proposal before committing to a wider rollout. They are practical review questions, not a ranking based on an asserted failure-rate study.
1. Automating a task that should change first
A workflow may contain duplicate approvals, unnecessary data entry or an outdated rule. Automating those steps can make an inefficient process run faster without making it useful.
Ask what outcome each step serves. Remove or redesign unnecessary work before estimating the value of automating it. Keep an accountable process owner involved in that decision.
2. Describing only the ideal process
Teams often explain the normal path and omit the cases that consume most attention. Missing data, conflicting records and an unavailable approver can determine the real workload.
Review recent examples with the people doing the work. List exceptions and who resolves them. Treat them as part of the scope rather than assuming they will disappear after launch.
3. Taking on too much at once
A broad programme can make it difficult to identify which change produced a result. It also increases dependencies on data, systems and teams.
Choose a bounded pilot with a clear completion state and explicit exclusions. Expansion should depend on evidence and operating capacity, not on a predetermined promise to automate every department.
4. Involving users only at the end
A technically correct workflow can be awkward or incomplete for the people using it. They may create unofficial workarounds that make the data unreliable.
Include users in design and test realistic cases with them. Record feedback, provide training and explain how exceptions reach a person. Adoption is work to plan, not an automatic consequence of installation.
5. Measuring activity instead of outcomes
The number of bot runs or generated answers does not establish that useful work was completed. A faster response can still be wrong.
Agree on baseline measures before implementation. Track accepted results, errors, review effort and costs over comparable periods. Distinguish time released from spending reduced, and revenue from contribution margin.
6. Ignoring portability and supplier dependence
A useful platform can still make migration difficult if workflows, records or credentials cannot be exported in a usable form.
Review export options, ownership, licence conditions and integration dependencies before signing. Document the workflow and assess what would be needed to rebuild or move it. Code ownership alone does not remove dependence on a third-party service.
7. Leaving rules and data ownership undocumented
If nobody knows which record is authoritative, automation can distribute inconsistent information more quickly.
Name the owner of each important field or source. Document transformations, approval rules and known exceptions. Keep the documentation alongside an agreed process for making changes.
8. Treating integrations as always available
Requests time out, credentials expire and external interfaces change. Retrying a failed operation without checking its outcome may create a duplicate transaction.
Design idempotency, reconciliation, retry limits and a visible exception queue. Test a failure after the destination has accepted a request but before confirmation returns. Define how a person can recover safely.
9. Ending the project at launch
A workflow can degrade as volumes, policies or source systems change. A model can also behave differently after an update.
Assign an operational owner and a maintenance responsibility. Define alerts, response procedures, fallback and periodic review. Budget for updates and support rather than presenting initial implementation as the lifetime cost.
10. Bringing security and permissions in too late
Broad access can make a demonstration convenient while creating unnecessary exposure in production. A model’s instruction to behave carefully is not an access-control system.
Review identity, permissions, secrets and data handling during design. Restrict actions to the task and require approval for consequential changes. Test requests that should be refused, not only authorised ones.
Use a decision gate, not a guaranteed ROI claim
A pilot should leave the team able to stop, revise or proceed. Compare evidence with the criteria agreed at the start. An unfavourable result can be useful if it prevents a larger unsuitable investment.
Document assumptions in the business case and include a scenario with lower use, delayed benefits or more exceptions. Do not use a generic success percentage as evidence that your particular workflow will pay for itself.
Questions before accepting a project
What should an acceptance test contain?
Representative normal cases, known exceptions, permission boundaries, interrupted operations and recovery steps. It should measure business correctness and review effort as well as technical completion.
Who should own the automation after launch?
A process owner should be accountable for the outcome, with clear technical responsibility for monitoring, incidents and updates. Those responsibilities should be agreed before deployment.
Decide where the work starts
For organisational analysis and changes following an audit, explore Q-Journey. A defined software project can start in Q-Dev. In either case, bring examples of normal work, difficult exceptions and the result you want to improve.