> ## Documentation Index
> Fetch the complete documentation index at: https://irisdocs.prescientlabs.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Assessing Opportunity Feasibility

> Test whether an AI, automation, integration or process-change opportunity is practical before recommending implementation.

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.