A first project should give your company a useful result and a clear way to judge the work. A broad ambition such as “use AI in operations” gives you neither.
This exercise is for a sponsor and the employees choosing among possible tasks. Compare up to three candidates. The result is a proposed first test, with enough detail to explain why it deserves the team's attention. Choosing a task does not authorize a deployment.
1. Describe the work before describing the AI
For each candidate, complete this sentence: “When this happens, this person uses these records to produce this result for the person who needs it.”
Include where the result belongs. A meeting brief belongs with the person attending the meeting; a service update belongs in an agreed system and may require approval. “Generate content” leaves unclear who needs the output, how they will check it and who is responsible.
Ask the employee what makes the current task difficult. A slow lookup, missing record and unclear decision are different problems. AI may help with one while leaving the others in place.
2. Define a result you can accept
Write three or four checks that apply to the current process and every alternative. Examples include correct references, required fields, no unsupported commitment and acceptance by the person using the result.
Then list a normal case and a difficult case. Include a source that is missing, stale or contradictory. Name who can decide when the task exceeds its boundaries. If nobody can judge the output, investigate that gap before starting a build.
3. Compare the whole job
Use these questions for each candidate:
- Does the result serve a real customer or employee need?
- Does the task happen often enough to test and learn from?
- Are approved sources available, current and owned?
- Can a person review the result without repeating the entire task?
- Are permissions, fallback and receiving responsibilities clear?
- Who can participate in testing and maintain the change?
- Can you observe quality, preparation, review, rework and upkeep?
Record evidence or “unknown” beside each answer. Avoid turning these into a single score that hides a critical gap. A popular task with unresolved permission is still unresolved.
Worked fictional example
A small service company considers three tasks: prepare a meeting brief, draft a response to an unusual complaint and automatically change appointment dates.
The meeting brief uses an approved account record and current service notes. The account lead uses the brief. A usable brief includes open commitments and their sources, separates confirmed facts from questions and makes no new promises. The lead can review it before the meeting.
The complaint task has inconsistent policy records and no agreed reviewer for exceptions. The scheduling task could affect customer commitments, and the team has not defined authorization or checked the result in the scheduling system.
The team selects a limited meeting-brief test. It first checks whether its existing tool can prepare the required information through a verified configuration. It will compare that option and an AI-assisted draft with the current manual brief. The other two tasks remain in discovery. This fictional choice does not establish that meeting briefs are universally the best first project.
4. Give the test boundaries
Specify the task, sources, participating users, review requirement and permitted actions. State what the test will not do. For example: draft only; no customer sending; no write to the account system; manual fallback remains available.
Choose a review point based on enough representative work to see normal and difficult cases. Set the criteria before looking at results. A quicker draft that creates more review or misses open commitments should not pass on speed alone.
If an action is later added, agree who approves it and check the result in the tool. That is an additional responsibility, not a small wording change.
5. Choose a next step, including investigation
A sensible outcome may be a bounded test, a native-tool configuration check, a source cleanup or a decision to leave the process alone. Name the owner and the evidence needed for the next decision.
Keep the first release small enough for your team to explain and maintain. Add related tasks after the original result has been checked with the people who use it.
When this comparison is insufficient
If the task has serious consequences or nobody can judge the output, involve the appropriate specialist before testing it with real work. This comparison helps choose a task; the task still needs its own tests.
Your next action: describe three candidates using the same trigger-to-recipient sentence. Ask the people doing each task to correct your description.
The blank Project comparison worksheet is available by email, without a Field Notes subscription. The exercise above remains open, and your completed comparison belongs in your own files.
Before a wider trial, rehearse the selected task with the people who do it.
For help choosing or scoping a first release, book the diagnostic call. You can also contact BR8N.