On this page
Start with the queue, not the demonstration
Hypothetical situation: an operations manager has three suggestions for a first AI project. One team wants help drafting supplier replies. Another wants a searchable policy assistant. A third wants a system to approve purchase requests. Each has a credible sponsor, but the proposals describe very different responsibilities. Comparing their demonstrations will not tell the manager which one the organisation can safely operate.
Start by describing one item entering each workflow and the evidence needed to finish it. For a supplier reply, that might mean an incoming enquiry, an approved price list and a reviewed draft. For purchase approval, it includes delegated authority, budget checks and a recorded decision. Those are different commitments even if both demonstrations end with a convincing paragraph.
The decision is which bounded task deserves a controlled test. It is too early to choose an enterprise programme, promise a delivery duration or calculate a return from assumptions that nobody has checked. Establish the work before estimating the benefit.
When a candidate is deferred, record the next piece of evidence needed rather than marking the idea as permanently unsuitable. A named source owner, a workable review step or a clearer exception route can change the decision. Revisit it when that evidence exists. This keeps the discussion tied to operational readiness without promising that every proposal should eventually become a pilot.
Compare value without inventing a benchmark
Ask each team to bring a small, representative sample of recent work. Remove sensitive information through the organisation’s approved process. Record the time spent finding information, preparing the output, reviewing it and correcting it. Keep waiting time separate from hands-on effort: a faster draft will not remove a delay caused by an unavailable approver.
Use the worksheet to compare candidates in plain language. Do not turn unknowns into a numerical readiness score. A proposal with uncertain source ownership needs an owner and evidence, rather than an optimistic rating. Ask what would make the proposed assistance useful enough for the receiving team to keep using it.
Include a comparison with improving the existing process. A clearer form, a maintained knowledge page or a deterministic validation rule may address the problem without generated content. Record that possibility alongside the AI option so the sponsor can make an informed choice.
| Question | Evidence to bring | Decision owner |
|---|---|---|
| Where does work slow down? | Representative items and observed handling steps | Process owner |
| What needs judgement? | Examples of corrections and exceptions | Reviewer |
| Can the source be trusted? | Approved source, owner and update process | Information owner |
| What happens after a wrong output? | Recovery route and affected decisions | Operational owner |
Make feasibility a practical check
For each remaining candidate, trace the input to its source. Confirm that a pilot team is permitted to use it, can obtain a representative sample and knows who can correct it. An exported spreadsheet that one employee assembled privately is not an agreed information supply. A policy document with no effective date is not a dependable answer source.
Then identify what the proposed system would be allowed to do. Reading approved material and preparing a draft is a different scope from sending a message, changing a record or approving a payment. Write the boundary as an action that an operator can recognise. For example: prepare a response for review; do not send it.
These are proposed review practices. The NIST AI Risk Management Framework is a voluntary risk-management resource available before this coverage date; it does not certify this worksheet or supply a product-specific approval mechanism. Your organisation still needs its own access controls, operational checks and acceptance decision.
Name the receiving owner
A sponsor can authorise exploration without being the person who will operate the result. Name the receiving owner before starting. That person needs to decide what counts as acceptable work, which exceptions require escalation and how the team returns to its previous process if the test fails.
Ask the reviewer to reject an intentionally incomplete sample. If the team cannot explain why it should be rejected, the acceptance criteria need work. Also ask who maintains the approved sources when the original project team moves on. A workflow that depends on an engineer quietly correcting material every evening has an unrecorded operating cost.
Choose a first test only when the owner, input boundary and review method are clear enough to describe to the people doing the work. Keep the rejected candidates and the reason for deferral. That record makes the next discussion more useful than another round of competing demonstrations.
Sources & further reading (1)
Historical evidence checked . Review practices and hypothetical exercises are editorial recommendations, not product guarantees.
