Estimable Automation Project Briefs

Start with the decision the project must improve

An automation project becomes difficult to estimate when its purpose is described only as “save time,” “use AI,” or “improve operations.” Those may be valid ambitions, but they do not define what the proposed system must do, who relies on it, or how its value will be judged. Begin with one explicit business objective: a decision to accelerate, a handoff to reduce, a queue to manage, or a recurring task to standardise.

State the objective in operational terms. For example, “prepare a complete first draft of supplier onboarding records for human review” is more estimable than “automate onboarding.” The first statement indicates an output, an actor, and a review point. It also gives the team a basis for identifying systems, data, exceptions, and measurement.

Victor Laybats provides AI and automation engineering services from Paris and publishes practical guidance for scoping, securing and measuring AI and automation projects. In that context, an objective is not a slogan for the project; it is the boundary that allows work to be separated from adjacent requests that may otherwise expand scope.

• Name the business process and the process owner.
• Describe the specific output, recommendation, action, or handoff expected.
• Define which users or teams will use the result.
• Name the decision or operational measure the project should support.

Describe the current workflow, including exceptions

An estimator needs to understand the work that exists today before proposing automation. A brief should therefore show the current sequence from trigger to completion: what starts the work, which people or systems touch it, what information moves between steps, and what marks the process as finished. A simple numbered workflow is often more useful than a broad process diagram with unexplained labels.

The important detail is variation. Many processes appear straightforward until the team considers missing information, duplicate records, unusual requests, approvals, escalations, or work performed outside the primary system. These cases affect design choices and effort because they determine whether the solution can follow a stable path or must route work back to a person.

Do not try to predict every rare scenario at the brief stage. Instead, distinguish normal cases from known exceptions and state what should happen when the automation cannot proceed safely. That makes uncertainty visible without turning the brief into a technical specification.

• What event triggers the process?
• Which systems, files, inboxes, or forms are involved?
• What is the normal path from start to completion?
• Which exceptions occur often enough to matter?
• What should happen when required information is absent or inconsistent?

Make data access and control concrete

A useful AI or automation project depends on controlled data. For estimation, that means more than listing data sources. Explain where the information resides, who can authorise access, how it is currently structured, how often it changes, and whether it can be used for the proposed purpose. A vague reference to “company data” leaves major questions unresolved.

Describe the inputs and outputs at a practical level. Inputs might include a request form, a customer record, a document collection, or a transaction status. Outputs might be a drafted response, a categorised record, a workflow update, or a report for review. For each, identify the source system or owner and the expected format where known.

Data quality should be addressed honestly. Outcomes depend on context, existing systems and input quality. If files are inconsistently named, records contain gaps, or fields are not maintained in a consistent way, record that in the brief. This does not make the project impossible; it enables a realistic estimate that includes validation, preparation, or a narrower first scope.

• List each input and output with its owner and location.
• State whether access is available, pending, or unknown.
• Note expected data volumes and update frequency if known.
• Identify sensitive, confidential, or restricted information.
• Flag known quality gaps, duplicates, and incomplete records.

Specify safeguards and human review

Appropriate safeguards are part of scope, not an afterthought. A project brief should identify which actions the proposed automation may take independently, which outputs must be reviewed by a person, and which actions are out of bounds. This is especially important where an automation changes records, sends communications, triggers downstream work, or handles sensitive information.

Human review needs to be operationally described. Say who reviews the output, what they check, when they intervene, and what happens if they reject or correct it. A statement such as “human in the loop” is too broad to estimate because it does not show the review workload, permissions, or feedback path.

Also identify access and audit expectations that are already known. The brief does not need to resolve every security design detail, but it should make clear that safeguarding requirements exist and whether there are internal stakeholders who must approve access, deployment, or operating procedures.

• Define permitted actions, review-required actions, and prohibited actions.
• Name the reviewer role and expected review point.
• Describe escalation for uncertain, incomplete, or unusual cases.
• Identify approval, access-control, logging, or retention requirements already known.

Example: a brief that can be estimated

Example — A business team wants to reduce manual preparation of internal purchase requests. Their brief says: “Create a draft purchase-request record from a standard intake form and supporting documents, then route it to the procurement coordinator for review. The objective is to make requests ready for review more consistently; the automation must not submit or approve purchases.” This is substantially more estimable than a request to “automate procurement.”

The current workflow is recorded as follows: a requester completes a form, attaches one or more documents, and emails the package to procurement. A coordinator reads the materials, copies selected fields into the purchasing system, asks for missing information, and routes the request for approval. Known exceptions include missing cost centres, unreadable attachments, and requests involving non-standard categories.

The data section identifies the intake form, document storage location, purchasing system, responsible owners, and uncertainty around attachment formats. The safeguards section requires the coordinator to approve every draft before it enters the approval route. Production measurement is defined as the share of submitted packages that can produce a review-ready draft, the review correction categories, and the time between intake and coordinator review.

This example does not determine a single estimate by itself. It does, however, let an estimator identify the interfaces to assess, the data preparation questions to resolve, the review workflow to design, and the boundaries that prevent unplanned purchasing authority from entering the scope.

• Business objective: prepare review-ready draft records, not approve purchases.
• Inputs: standard form and attachments; output: draft record for coordinator review.
• Exceptions: missing fields, unreadable files, non-standard categories.
• Safeguard: no autonomous submission or approval.
• Measurement: draft readiness, correction types, and review timing.

Turn the brief into a measurable delivery boundary

An estimate is strongest when the brief separates what is known, what must be discovered, and what is deliberately excluded. Include the intended first release, the systems expected to be involved, the expected users, and the decisions still awaiting confirmation. This makes it possible to estimate a scoping phase where necessary instead of pretending that unanswered questions have no effect.

Production measurement should be included before deployment is discussed. Define what will be observed once the automation is operating: completion outcomes, review corrections, exception volume, processing timing, or another measure tied to the business objective. Measurement is not a promise of a particular result. It is a way to determine whether the implementation remains useful in its actual operating context.

Finally, assign ownership. A project can be technically well described yet remain ambiguous if nobody owns the process, data access, human review, or acceptance of the deployed workflow. Naming these roles makes the brief actionable and helps distinguish project work from organisational decisions that need to be made separately.

• State the first-release boundary and explicit exclusions.
• List open questions and the person responsible for resolving each one.
• Define production measures linked to the objective.
• Name owners for process decisions, data access, review, and acceptance.
• Record dependencies on existing systems, approvals, and availability of inputs.