Key takeaways
- A ten-day schedule is a proposed planning aid, with timing dependent on scope and access.
- Inspect actual records and compare process changes, existing software and new tools.
- Separate released staff capacity from cash savings and test assumptions before expanding spending.
A business considering an AI project needs to know what staff do today, which part a new tool could change and how much a trial would cost. The schedule below is a proposed way to gather those facts over ten working days. It assumes employees can make time for interviews and the team can access the relevant records.
Use it for one defined process, such as preparing a standard quote or classifying incoming requests. A project spanning several departments, regulated decisions or unresolved data permissions may need a longer assessment. Record those dependencies rather than treating the tenth day as a deadline to approve a build.
Days 1 and 2: examine current work
Ask the process owner and employees to walk through recent completed cases, including ones that required correction. Record the input, steps, software, decisions and output. Distinguish hands-on time from waiting for another person, because faster drafting will not eliminate a delay caused by an approval queue.
Find out how often the task occurs and what errors cost. Use records where available and mark estimates where staff must reconstruct time spent. A complaint about a slow process can identify a candidate, but the assessment still needs to establish which delay a proposed tool would address.
Days 3 to 5: inspect records and permissions
Collect an authorized sample that covers normal work, exceptions and different periods. Check for missing inputs, inconsistent fields, changed procedures and corrected outputs. Ask employees to explain disagreements about what a successful result should contain.
Confirm who owns the records and who can authorize the proposed use. Find out whether a vendor may process them and whether the trial can use a smaller or less sensitive sample. A permission problem requires a specific resolution; good scores on cost or convenience cannot compensate for it.
Write down how fresh each input needs to be and how updates would reach the tool. Also identify material that exists only in email attachments, local files or an employee’s memory. An engineer can then estimate the effort needed to make those inputs available.
Days 6 and 7: compare plausible options
Consider a change to the existing process, a feature in software already owned, a new vendor product and a custom build. Have suppliers or engineers explain what each option would require, including setup, integration, review and ongoing support. Request a demonstration on representative material where sharing is permitted.
NIST’s AI Risk Management Framework Playbook offers actions that organizations can adapt to their circumstances. It explicitly avoids treating its guidance as a checklist that every organization must complete. This assessment likewise needs findings about your proposed use, rather than a maturity score.
Day 8: calculate costs and possible benefits
Separate setup costs from recurring expenses. Include employee time for preparation, integration, training and review; fees for software and model usage; and support after launch. Estimate benefits from the portion of the process a trial could actually change.
Here is an illustrative calculation. Assume staff spend 40 hours a week on a task for 50 weeks, at a combined wage-and-benefit cost of $45 an hour. That represents $90,000 of annual labor. If a trial reduces the task to 25 hours including review, the released capacity is 750 hours, valued at $33,750.
Suppose setup costs $18,000 and annual operation costs $12,000. Valuing the released hours at that labor rate produces an estimated annual benefit of $21,750 after running costs, and a simple payback of about ten months after full operation begins. A cash-payback calculation would need to use spending the company can actually avoid or additional profit from paid work completed in those hours. Implementation delays would lengthen either calculation.
Days 9 and 10: define a trial and make a decision
Choose trial cases, expected outputs and a person qualified to review them. Agree how errors will be classified, how time will be measured and what result would justify a larger deployment. Reserve some cases for evaluation instead of using every example to improve the tool.
Prepare a short decision record with the chosen option, cost assumptions, permissions, unresolved questions and proposed trial. A decision to wait should identify what must change and who will address it. A decision to stop should record why further spending is not justified.
Before funding the trial, ask the process owner and finance lead to sign off on the same version of those assumptions. Put a review date beside the budget so the next decision can use measured time, errors and expense from the trial.
