Start with work your team already owns. This checklist develops the four questions on our homepage into a short brief you can share with a sponsor, technical lead, and reviewer.
01 · The work
Describe the input, task, output, and handoffs. How often does it happen? What slows it down?
Check before proceeding: A recurring task is not automatically a good custom-build candidate. Check whether an existing tool or a simpler process could address the problem.
02 · The people
Name the process owner, users, reviewers, and decision-maker. Ask what they need to change.
Check before proceeding: Without people available to test and adopt the workflow, a successful demo may not become useful work.
03 · The baseline
Record a representative sample of time, volume, rework, exceptions, and review effort.
Check before proceeding: Count checking and correction time. Capacity released is not automatically cash saved. Include implementation, data, infrastructure, and support costs.
04 · The information
List sources, owners, access rights, sensitivity, missing fields, and permitted uses.
Check before proceeding: Resolve required permissions before transferring sensitive material. A prototype needs appropriate inputs, not unrestricted access.
05 · The check
Define a useful result, unacceptable errors, reviewer action, and the fallback when the system cannot help.
Check before proceeding: Choose acceptance criteria for the consequences of this particular task, not a universal accuracy percentage.
A one-page brief to take into a conversation
- Workflow and accountable owner
- Current steps and recurring volume
- Baseline and intended improvement
- Permitted data and unresolved access questions
- Reviewers, acceptance criteria, and exceptions
- Existing tools and alternatives considered
- Decision needed and reasons to stop
Use Qualify → Prove → Decide → Embed → Handover to separate the decision to test from the decision to deploy. See our implementation method.
