Plan an 8–16 week process automation project with a Gantt chart covering process discovery, RPA/BPA tool selection, build sprints, UAT, and ROI measurement.
Business process automation projects have a pattern that repeats across organizations: a process is identified for automation, a tool is selected quickly, a bot or workflow is built, and then the project sits in a gray zone — "mostly working" but not fully deployed, not measured, and quietly abandoned when the champion moves to other priorities. The problem is almost always a missing project structure, not a missing technology.
A Gantt chart for process automation creates the structure that prevents this pattern. It defines clear phases, assigns ownership, establishes a UAT gate before go-live, and — critically — includes a measurement phase that produces the ROI numbers needed to justify the next automation project.
This guide covers the full automation project lifecycle for both robotic process automation (RPA) and business process automation (BPA), from initial process discovery through post-go-live ROI reporting.
Before any automation tool is touched, the process to be automated must be completely understood and documented. This phase is consistently underinvested because it looks like project overhead rather than real work. It is, in fact, the most valuable phase — automating a poorly understood process produces a bot that automates the wrong steps.
Current state (AS-IS) process mapping — map the process exactly as it is performed today. Conduct process walkthroughs with the employees who actually do the work, not their managers' descriptions of how it should be done. Document:
Use a process mapping tool (Lucidchart, draw.io, Visio, or even a whiteboard session) to create a visual flowchart. Validate the flowchart with the process SMEs before moving forward.
Pain point quantification — measure the current state cost of the process:
This baseline measurement becomes the denominator of your ROI calculation post-automation.
Process fit assessment — not all processes are good automation candidates. Assess fit against three criteria:
If multiple processes are candidates for automation, prioritize them before committing to a build.
Scoring criteria — score each candidate process on:
Quick win identification — prioritize 1–2 high-volume, low-complexity processes for the first automation build. These "quick wins" generate ROI quickly, build internal confidence in automation, and create the political capital to pursue more complex automation projects.
Backlog development — document all automation candidates in a prioritized backlog. This becomes the roadmap for automation projects beyond the first.
The automation tool market has three distinct tiers, and selecting the wrong tier for your use case is a common and expensive mistake.
RPA (Robotic Process Automation) — RPA tools (UiPath, Automation Anywhere, Microsoft Power Automate Desktop, Blue Prism) simulate a human user interacting with software interfaces: clicking buttons, copying and pasting data, reading screen contents. RPA is the right choice when:
RPA is not the right choice when API integration is available. API-based automation is faster, more reliable, and easier to maintain than RPA.
BPA (Business Process Automation) — BPA platforms (Zapier, Make/Integromat, n8n, Microsoft Power Automate Cloud) connect systems via APIs and webhooks to automate workflows across them. BPA is the right choice when:
AI workflow tools — newer platforms (Relevance AI, Bardeen, Lindy, Zapier Central) incorporate LLMs into workflow automation, enabling processes that require natural language interpretation (email parsing, document understanding, unstructured data extraction). These are appropriate for processes where the input is unstructured text.
Make vs. build vs. buy decision — for standardized processes (invoice processing, employee onboarding, order management), evaluate off-the-shelf automation solutions (SaaS apps with built-in automation, ERP modules) before building custom automation. Pre-built solutions are faster and cheaper for common process patterns.
Sprint structure — structure the automation build as a series of 2-week sprints:
Exception handling design — every automation has exceptions: malformed input data, system unavailability, unexpected UI states, transactions that fall outside the defined rules. Design exception handling before the build begins, not after. For each exception type, define: does the bot retry (how many times, with what delay)? Does it route to a human queue? Does it send an alert? Does it log and skip?
Human-in-the-loop design — the goal is not to eliminate humans from the process — it is to have humans handle only the exceptions and decisions that genuinely require human judgment. Design the exception queue: where do exception transactions go, who reviews them, and how does the reviewed result flow back into the process?
Logging and monitoring — every automation build should include comprehensive logging from Day 1:
Logging is not optional overhead — it is the data source for ROI measurement and the primary debugging tool when the bot encounters unexpected behavior.
UAT environment — run UAT in a test environment using production-representative data, not synthetic test data. Synthetic test data rarely surfaces the data quality issues that will appear in production.
UAT test cases — develop test cases covering:
Parallel run — run the bot and the human process simultaneously on the same transactions for 1–2 weeks. Compare bot outputs to human outputs. Discrepancies reveal automation logic errors that UAT did not catch.
UAT sign-off — require formal UAT sign-off from the process owner before go-live. The sign-off confirms: the bot handles all agreed scope correctly, exception handling works as designed, and the process owner accepts responsibility for production monitoring.
Phased go-live — for high-volume or high-stakes processes, phase the go-live: start with 10–20% of transaction volume running through automation, increase to 50%, then 100% over 2–3 weeks. This approach surfaces production issues before they affect the full transaction volume.
Hypercare period — designate the first 2–4 weeks post-go-live as a hypercare period. The automation developer monitors daily transaction logs, responds to exception alerts within 4 hours, and is available to fix production issues within 24 hours.
Escalation protocol — define what triggers an automation pause (error rate exceeds 10%, bot encounters a system change that breaks its logic) and who has authority to pause and restart the automation.
FTE hours saved — compare actual post-automation FTE hours spent on the process versus the pre-automation baseline. Account for human review of exception queues (this is real time that must be subtracted from gross savings).
Error rate reduction — measure the error rate of automated transactions versus the pre-automation baseline. Calculate the cost of errors avoided (rework time, downstream correction cost).
Cycle time improvement — measure the end-to-end process cycle time in automation versus the pre-automation baseline. Cycle time reduction often has business value beyond FTE savings (faster customer onboarding = faster revenue recognition, faster invoice processing = improved cash flow).
ROI calculation — ROI = (annual benefits − annual total cost of ownership) / annual total cost of ownership. Benefits include: FTE cost savings, error cost reduction, cycle time business value. Total cost of ownership includes: tool licensing, development cost (amortized), ongoing maintenance (typically 15–25% of initial development cost per year).
ROI report — produce a formal ROI report at 90 days post-go-live. This report justifies the investment to leadership and provides the business case data for the next automation project in the backlog.
Structure the Gantt with these tracks:
Flag the UAT sign-off milestone as a hard gate — the go-live date must follow UAT sign-off, not precede it. Automation projects that go live before UAT is complete consistently generate production incidents that cost more to fix than the time saved by the early launch.