The best first project is often a familiar task with an understandable problem. Before choosing software or an AI tool, find a piece of work that repeats, has an owner, and could be improved without changing the whole business.

Use this guide when: Several tasks feel inefficient, and you need to decide which one deserves attention first.

Leave with: One workflow, a simple baseline, and a short list of questions to investigate.

1. Notice the work that repeats.

Write down three tasks your team performs regularly. Look for repeated copying, chasing missing information, reconciling different versions, or assembling the same report. Describe each task with a verb and an object: prepare the weekly schedule, reconcile supplier records, or route a new request.

Ask the person doing the work to walk through a recent example. The exceptions and workarounds often tell you more than the ideal process.

Include the people who receive the output. A report may be easy to produce but difficult to interpret; a request may leave one person's queue only to wait in someone else's inbox. Follow the work far enough to understand who benefits from a change.

  • Frequency: does it happen often enough for a change to matter?
  • Friction: is the problem time, errors, missing information, or uncertainty?
  • Consequence: what happens to the next person when this work goes wrong?

2. Give each workflow a beginning and an end.

A useful boundary makes the work observable. Identify the event that starts it and the condition that means it is finished. If a workflow stretches across several departments and has no clear owner, choose a smaller part first.

  • Trigger: what causes this work to begin?
  • Inputs: which information and tools are needed?
  • Owner: who is responsible for getting it through?
  • Finish: what must be true before it is considered complete?
  • Exception: what needs a person's judgment, approval, or correction?

Illustrative workflow: preparing a weekly schedule

The trigger is a weekly cutoff. The inputs are availability and confirmed jobs. A coordinator drafts the schedule, reviews conflicts, and shares the approved version. The first improvement could assemble the draft and flag missing information. Assigning people to jobs and approving the final schedule remain with the coordinator.

3. Compare value with readiness.

For each candidate, note how often it happens, the effort involved, and what goes wrong. Then ask whether the inputs are accessible, the process is understood, and someone can review a change. A painful task with unclear rules may need an audit before an automation.

Prefer a useful problem that is ready to investigate over a dramatic idea with uncertain inputs. Do not let a simple score hide a serious constraint such as sensitive data, unavailable access, or a decision that needs human judgment.

Check whether a shared checklist, a clearer responsibility, or a setting in an existing tool would address the problem. Custom software or AI can be appropriate when the work calls for it, but the smallest maintainable change is a useful comparison point.

A fictional comparison

A team considers replacing its entire scheduling system or reducing the manual assembly of a weekly schedule. The weekly task has a known owner, consistent source files, and an agreed output. It offers a smaller place to test whether a change helps.

4. Record what happens today.

Observe a representative set of recent cases. Record handling time, waiting time, corrections, or another measure connected to the problem. Keep the definition consistent and include unusual cases instead of selecting only easy ones.

If the information is incomplete, label the estimate and decide how to improve it. The point is a fair comparison, not a precise-looking number without a dependable source.

For the scheduling example, separate time spent gathering information from time spent reviewing a draft. If gathering takes most of the effort, a faster drafting tool may leave the main problem untouched. Also record corrections so a faster first draft does not conceal extra work later.

5. Count the effort around the build.

Implementation is one part of the cost. Someone may need to clean source data, arrange access, review examples, train colleagues, and own the workflow afterward. Third-party subscriptions, hosting, usage charges, and maintenance can continue after the first version is complete.

Estimate value cautiously. Time released from a recurring task can create capacity, but it does not automatically become cash savings. Compare the likely benefit with setup effort, recurring costs, and the work required to handle exceptions. Note what is known and what a small pilot would need to establish.

  • Keep: tools and steps that already work well.
  • Change: the smallest part that addresses the observed friction.
  • Budget for: setup, team review, software charges, and ongoing ownership.
  • Reconsider: candidates that depend on unavailable data or an owner who cannot participate.

6. Ask the team to challenge the choice.

Share the short workflow description with the person doing the work, the person receiving it, and someone who can make a scope decision. A scheduled walkthrough and written comments can reveal different problems. Use a redacted or fictional example before sharing sensitive operational records.

Ask each person what must remain under human control, which exception occurs most often, and what would make a first version useful enough to try. Capture disagreements as open questions. The next step may be a workflow audit if the rules are unclear, or a bounded pilot if the path is well understood.

7. Write the opportunity in one sentence.

Use this structure: when [trigger] happens, [person] needs to [task], but [friction] gets in the way. A useful improvement would [observable change].

Add the tools involved, a recent example, and the person who can explain the process. That is a stronger starting brief than a list of features or a request to add AI everywhere.

An illustrative starting brief

When the weekly availability cutoff arrives, our coordinator needs to prepare a reviewable schedule, but incomplete inputs and repeated copying slow the draft. We want to test whether a structured intake and draft assembly step reduces preparation effort while the coordinator keeps approval. First, we need to confirm which source records are reliable.

Take this into your next conversation.

Choose one recurring task with an owner, an observable problem, accessible inputs, and a clear finish. That gives a first project something useful to prove.

Describe the task that repeats, who handles it, which tools are involved, and what you want to make easier. Include any uncertainty about access or ownership so the first conversation can address it.

Download the blank PDF worksheet

Complete it with a real workflow in mind, then scan and email it to the address on the worksheet. Keep sensitive information out of the brief.

Back to all resources