Skip to main content
An opportunity can have obvious business value and still be a poor implementation candidate. Feasibility is the bridge between “this problem matters” and “we should invest in this intervention.”

​
Assess six dimensions

​
1. Process readiness

Ask whether the workflow is sufficiently understood and stable. Warning signs:
  • different teams follow materially different processes;
  • ownership is unclear;
  • policy changes are already underway;
  • the proposed automation would simply encode a broken process.

​
2. Data readiness

Check whether the required information is available, trustworthy and legally usable. Consider:
  • source systems;
  • missing fields;
  • data quality;
  • access permissions;
  • personal or sensitive information;
  • whether examples exist for testing.

​
3. Technical feasibility

Identify:
  • systems and APIs involved;
  • authentication and access constraints;
  • latency or volume requirements;
  • model or automation capability required;
  • hosting and security requirements;
  • monitoring and support needs.
Do not estimate implementation effort confidently until important technical dependencies are known.

​
4. Human and change feasibility

Ask who will use, approve, monitor and own the new workflow. A technically successful solution can still fail if:
  • staff do not trust it;
  • managers do not change the operating process;
  • nobody owns exceptions;
  • incentives reward the old behaviour.

​
5. Risk and control

Consider:
  • accuracy requirements;
  • consequences of failure;
  • human approval points;
  • auditability;
  • security and privacy;
  • regulatory or contractual constraints.
Higher-impact use cases need stronger controls and a higher evidence threshold.

​
6. Commercial feasibility

Compare expected value with:
  • implementation cost;
  • ongoing cost;
  • internal client effort;
  • time to value;
  • dependency cost;
  • realistic adoption.

​
Use a feasibility scorecard

A simple 1–5 score can help structure discussion across process, data, technology, change, risk and economics. Do not treat the arithmetic as proof. The scorecard exists to expose assumptions and disagreements.

​
Red flags that should change the recommendation

  • the use case depends on data the client cannot access;
  • the process owner does not support the change;
  • a standard software feature already solves the problem;
  • the value disappears under conservative assumptions;
  • the task has a high consequence of error but no credible oversight model;
  • the implementation requires capabilities outside your delivery model.

​
Consultant talk track

The opportunity is attractive commercially, but it is not implementation-ready yet. We recommend resolving the data and ownership prerequisites first, then reassessing the build once those dependencies are closed.

​
What to do next

Once feasibility is understood, return to Prioritising Opportunities and select the first implementation candidate based on value, evidence, feasibility, risk and dependencies.