What Should Happen Before an Automation Project Starts?

An automation project that starts with a kickoff meeting and a vendor already selected is starting in the wrong place. By the time a project reaches that stage, it should already have answers to a specific set of questions: what does the process do today, what is it supposed to achieve, how is it performing now, what assumptions is the plan built on, what should the process look like once the change is made, and who owns the decision if something in that plan turns out to be wrong. Skipping these questions does not make the project faster. It moves the cost of answering them into the build phase, where getting them wrong is far more expensive to fix.

Define the current process as it actually runs

The starting point is a description of the process as it is actually performed, not as it is written in a policy document. This includes every step, every handoff between people or teams, and every exception path that gets used regularly even if it was never formally approved. A process description that only reflects the documented version will miss the workaround an experienced team member uses to handle a recurring edge case, and an automation build based on the documented version alone will fail the moment it meets that edge case in production.

Getting this right does not require weeks of interviews. It requires talking to the people who actually do the work, walking through recent real cases rather than hypothetical ones, and being willing to record the messy version rather than smoothing it into something tidier than reality.

State the objective in terms that can be measured

Every automation project needs an objective specific enough to be checked later. Faster is not an objective. Reduce average cycle time for standard approvals from six days to two days is an objective. Fewer errors is not an objective. Reduce the rework rate on data entry from eighteen percent to under ten percent is an objective. A vague objective cannot be tested against a baseline and cannot tell a project team when it has succeeded, which means scope tends to expand indefinitely because there is no defined finish line.

The objective also needs to be the right objective for the business, not just the easiest one to automate. A project aimed at reducing labor hours in a step that was never actually the bottleneck will succeed on its own narrow terms while leaving the customer-facing delay completely unchanged.

Establish a measured baseline

Once the process and the objective are clear, the process needs to be measured as it currently performs against exactly the metrics named in the objective: cycle time, throughput, error or rework rate, and where volume actually concentrates. This baseline becomes the reference point that every later claim of improvement is measured against. Without it, a claim that automation reduced cycle time by forty percent is unverifiable, because there is no honest record of what the cycle time was before the change.

Write down the assumptions the plan depends on

Every automation plan rests on assumptions, and most projects never write them down, which means nobody notices when an assumption stops being true. Assumptions worth stating explicitly include expected volume and its likely range, the rework or exception rate the new design is expected to produce, the effort required to build and test the change, and any dependency on another team or system being ready by a certain date. Writing these down does not slow the project down. It gives the project a way to explain, later, exactly why an outcome differed from the estimate, rather than leaving everyone guessing.

Define the target flow, step by step

Before implementation begins, there should be a specific description of what the process looks like after the change: which steps remain, which are removed, which are automated, which involve an AI agent, and how a case moves between them. This target flow does not need to specify implementation detail like which system fields get mapped where, that is implementation work, but it does need to be unambiguous about the sequence of steps and who or what is responsible for each one. A target flow that is still vague about ownership at this stage will generate disputes during build, when changing course is far more expensive.

Assign ownership of the decision, not just the delivery

Implementation teams need a clear answer to a specific question: if something in the target flow needs to change once building starts, who has the authority to approve that change. Without a named owner, small decisions during implementation either stall waiting for consensus or get made unilaterally by whoever is available, and neither outcome produces a process that matches what was actually intended. Ownership should be assigned to a specific person accountable for the process outcome, not to a committee, and that person should have been involved in defining the objective and the target flow in the first place.

How Processfix supports this

Processfix is built to produce exactly this set of answers before implementation starts. A process can be described in plain language or extracted from an existing SOP or PDD document into an editable swimlane model, clarifying questions surface the gaps in the description, and a discrete-event simulation across a realistic mix of cases produces a locked baseline. Improve and Add AI scenarios are then tested against that baseline, with objective-led recommendations and clear before-and-after comparisons on cycle time, throughput, and estimated value. The result, including the target flow and its underlying assumptions, can be exported as a process design document to Word, PDF, or Markdown, giving an implementation team a complete and specific starting point rather than a set of assumptions they have to reconstruct themselves.