AI Project Checklist.
A workbook for the whole project.
Plan the work, test it and record the handover. Six editable sheets to use with your team or any builder.
Download the workbook.xlsxOr use the checklist belowWork through your project.
Choose a phase. Open a check.
Business case
Decide whether the work is worth doing.
Define one job clearly
When does the work start, and what observable event means it is finished?
Evidence to ask for
A workflow naming the trigger, inputs, finished output, users and steps a person will keep.
Why this matters & an example
A specific start and finish make a project easier to price, test and measure.
Illustrative: an order email becomes a reviewed draft order in the CRM. Sending a quote stays with the account manager.
Measure the starting point
Which records show the current workload, and what does this sample leave out?
Evidence to ask for
Dated records of volume, handling time, error or rework rate, and the period and sample used.
Why this matters & an example
An improvement needs a comparable starting point, including exceptions and rework.
Illustrative: review four weeks of order emails and time a sample of routine, incomplete and corrected orders separately.
Set an outcome and a review date
What must improve, by when, and what result would make us reconsider?
Evidence to ask for
One primary metric, its definition, an agreed target, a review date and a person responsible for checking it.
Why this matters & an example
A visible target gives the team a way to decide whether to continue, change or stop.
Illustrative: compare median handling time after a four-week pilot, while checking that correction rates have not increased.
Compare a simpler alternative
What could we fix without AI, and why is the proposed approach worth the extra complexity?
Evidence to ask for
A short comparison of the current process, a simpler change and the proposed AI approach, including costs and limits.
Why this matters & an example
A rule, better form or existing software feature may solve the same problem with less upkeep.
Illustrative: compare a required order form with an AI email reader before building a new intake system.
Separate capacity value from cash savings
Will the benefit be more capacity, a real expense reduction, or additional sales—and what supports that expectation?
Evidence to ask for
An editable estimate of net hours freed, how those hours will be used, running costs and one-time costs, with assumptions identified.
Why this matters & an example
Freed time has value, but it does not automatically reduce payroll or create sales.
Illustrative: value time available for account follow-up separately from an overtime expense the business actually plans to remove.
Include the people affected
Who uses the output, who could be affected by a mistake, and who can challenge or stop the process?
Evidence to ask for
Input from operators and an accountable owner, with affected customers, sensitive decisions and a route to raise concerns recorded.
Why this matters & an example
The people using the system know practical exceptions and the consequences of a wrong action.
Illustrative: involve the sales coordinator and account manager; record that price exceptions require a manager’s decision.
Scope
Agree on what will be built and controlled.
Put the deliverables in writing
What is included, what is excluded, and who agrees to a change in cost or timing?
Evidence to ask for
Deliverables, exclusions, dependencies, milestones, acceptance criteria, price and a written change process.
Why this matters & an example
Clear boundaries keep a promising idea from becoming an open-ended commitment.
Illustrative: one shared inbox and one CRM are included; multilingual documents and a second sales team are a later phase.
Map the data and account access
Which data is necessary, where does it travel, and who grants or removes access?
Evidence to ask for
A source and account inventory covering access approvers, data quality, sensitive fields, retention and deletion requirements.
Why this matters & an example
The build needs usable information and permissions that match its job.
Illustrative: give the integration access to the orders inbox and draft-order endpoint; keep payment details outside its scope.
Define what needs approval
What may the system do on its own, and what must wait for a named person?
Evidence to ask for
A list of permitted actions, actions requiring approval, prohibited actions and the identity under which changes are made.
Why this matters & an example
Reading information, preparing a draft and committing a change have different consequences.
Illustrative: draft a quote automatically, but require approval before changing price, offering credit or contacting the customer.
Specify every connection
Which system owns each field, and how do we prevent duplicate or stale updates?
Evidence to ask for
For each connection: supported API or integration, field mapping, source of truth, identifiers, limits and failure behavior.
Why this matters & an example
A working demo does not establish that your actual systems exchange the right records reliably.
Illustrative: keep CRM customer IDs on each draft order and use the email message ID to recognize an already-processed request.
List outside services and limits
What depends on a third party, who pays for it, and what happens if its price or service changes?
Evidence to ask for
Provider and licence inventory with billing owner, usage limits, data terms, version dependencies and replacement options.
Why this matters & an example
Model providers, hosting and other tools affect price, availability and what can be moved later.
Illustrative: list the model API, automation host and CRM subscription separately from the builder’s fee.
Plan a limited first release
Where will we start, what will stay manual, and what would stop the pilot?
Evidence to ask for
A pilot population, start and end dates, review checkpoints, release decision owner, and a fallback to the current process.
Why this matters & an example
A bounded pilot makes it easier to find mistakes before the system handles all of the work.
Illustrative: start with one product category and draft-only output while the existing order process remains available.
Test
Check the work under realistic conditions.
Test representative examples
Which difficult cases occur in real work, and are they represented in the tests?
Evidence to ask for
A test set of routine, incomplete, ambiguous and out-of-scope inputs, with expected outcomes and important cases grouped separately.
Why this matters & an example
A polished demonstration covers only part of the work your team will encounter.
Illustrative: include an order with a missing quantity, conflicting product names, a forwarded thread and an unreadable attachment.
Record expected and observed results
What counts as a pass, which errors are unacceptable, and can someone else reproduce the result?
Evidence to ask for
A test log with expected and observed outcomes, pass criteria, environment or version, reviewer, date and evidence links.
Why this matters & an example
A result is only assessable when the expected behavior and acceptable limits are clear.
Illustrative: a missing quantity must produce a request for review rather than an invented order quantity.
Check speed and running costs
At our expected peak volume, how long does work wait and what does it cost?
Evidence to ask for
Observed response times, usage and cost for ordinary and busy periods, with the test workload and agreed limits documented.
Why this matters & an example
The system has to remain useful when several requests arrive together, not just during a single demonstration.
Illustrative: replay a busy hour of representative requests and record elapsed time, model usage and any rate-limit failures.
Try the failure and recovery paths
If a connection fails halfway through, can we tell what happened and safely continue?
Evidence to ask for
Tests for timeouts, unavailable services, duplicate requests and restarts, showing retained context and recovery outcomes.
Why this matters & an example
Interruptions should not silently lose work or repeat an action that already succeeded.
Illustrative: disconnect the CRM after a draft is created, then retry the request and verify that a second draft is not created.
Rehearse the human handoff
Who receives the exception, what do they see, and what happens if nobody responds?
Evidence to ask for
A tested escalation trigger, recipient, context package, acknowledgement process and fallback when that person is unavailable.
Why this matters & an example
An uncertain or sensitive request needs a reachable person and enough context to act.
Illustrative: route a pricing exception with the original email, proposed draft and reason for review to the duty account manager.
Test boundaries and misuse
Can an input or user cause the system to reveal data or take an action outside its job?
Evidence to ask for
Tests of denied access, sensitive-data requests, misleading instructions in inputs and actions outside the agreed permissions.
Why this matters & an example
Unexpected instructions or unauthorized users must not expand what the system is allowed to do.
Illustrative: an email telling the system to ignore approval rules must not cause it to send a quote or export the customer list.
Handover
Leave with the access and knowledge to run it.
Confirm access and ownership
What will we receive, when do rights transfer, and what still belongs to someone else?
Evidence to ask for
Written terms covering custom deliverables, source access, account control, payment conditions and pre-existing or licensed components.
Why this matters & an example
Owning an account, receiving source files and holding a licence are different things.
Illustrative: distinguish ownership of a custom workflow from the subscription and licence needed to run its hosting platform.
Keep a record of outcomes
Can we trace a reported improvement to the records and assumptions behind it?
Evidence to ask for
Dated records, metric definitions, data source, measurement window and a label distinguishing measured results, reports and estimates.
Why this matters & an example
Activity, completed work and revenue measure different things.
Illustrative: report draft orders created separately from approved orders and paid invoices; do not count all three as sales.
Get the operating instructions
Can our operator follow the instructions without the original builder on the call?
Evidence to ask for
A runbook and walkthrough covering configuration, version history, monitoring, routine changes, credentials management and common exceptions.
Why this matters & an example
The team needs a repeatable way to inspect, update and operate the system after the builder leaves.
Illustrative: ask the coordinator to change an escalation recipient using the runbook and confirm the next test reaches the new recipient.
Rehearse recovery and exit
How do we stop a bad run, recover a known version or move the work to another operator?
Evidence to ask for
A tested backup or export, restore steps, pause or shutdown procedure, rollback decision owner and list of dependencies required elsewhere.
Why this matters & an example
An export is more useful when someone has checked that it can actually be restored or moved.
Illustrative: restore the last approved workflow in a test environment and confirm it can process the saved sample inputs.
Name the owner after launch
Who checks the system, who fixes it, and which requests require a new agreement?
Evidence to ask for
Named operating and support owners, coverage and response expectations, incident contact, escalation route, scope and ongoing costs.
Why this matters & an example
Tool changes and incidents need someone with time and authority to respond.
Illustrative: record who handles a failed daily run and who approves a change to the workflow, including cover during leave.
Schedule review and retesting
Which changes require another test, and when will we compare outcomes with the original baseline?
Evidence to ask for
A review schedule, retest triggers, unresolved issues with owners, accepted limitations and a recorded launch or continuation decision.
Why this matters & an example
A successful launch does not establish that the system will keep performing after its inputs or tools change.
Illustrative: rerun the test set after changing the model, CRM fields or approval rules, and review the pilot’s outcomes with the process owner.
Project details
Your notes download includes every phase, its guidance and your saved statuses.
Notes stay on this device.
Sources & use
A practical resource by Benian Technologies. Use the prompts to support a project conversation; they are not a NIST assessment or certification. All examples are illustrative.