← All guides

Gantt Chart for Process Automation

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.

Gantt Chart for Process Automation

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.

Phase 1: Process Discovery and Documentation (Weeks 1–3)

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:

  • Every step in the process, in sequence
  • Decision points and branching logic (if X, then Y; if Z, then escalate to human)
  • Systems accessed and data entered at each step
  • Exceptions and edge cases (what happens when the data is missing? When the system is down? When the format is unexpected?)
  • Handoffs between people, teams, or systems

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:

  • Volume: how many times per day/week/month is the process executed?
  • Time: how long does each execution take, in minutes?
  • FTE cost: multiply volume × time × FTE hourly loaded cost (salary + benefits + overhead)
  • Error rate: what percentage of executions contain errors? What is the cost of each error (rework time, downstream corrections, customer impact)?
  • Cycle time: total elapsed time from process trigger to completion (includes waiting time, not just active work time)

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:

  • Rule-based: does the process follow consistent, documentable rules, or does it require human judgment, creativity, or relationship management? Pure rule-based processes are the best automation candidates.
  • Digital: does the process work with digital data (database entries, spreadsheets, email, web forms), or does it require handling physical documents? Fully digital processes are ideal; paper-intensive processes require additional OCR/document capture infrastructure.
  • Stable: is the process stable, or does it change frequently? Automating a process that changes every 6 months means constant bot maintenance.

Phase 2: Automation Opportunity Scoring (Weeks 3–4)

If multiple processes are candidates for automation, prioritize them before committing to a build.

Scoring criteria — score each candidate process on:

  • Volume × time = annual hours saved (higher is better)
  • Error rate reduction potential (higher is better)
  • Implementation complexity (lower is better): number of systems accessed, number of exception types, data format variability
  • Strategic value: does automating this process unlock a strategic outcome (faster customer onboarding, reduced compliance risk, improved employee experience)?

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.

Phase 3: Tool Selection (Weeks 4–6)

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:

  • The process spans multiple legacy systems with no APIs
  • The systems cannot be modified (mainframe applications, third-party platforms with no integration capability)
  • Screen scraping and UI interaction are the only available access methods

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:

  • All systems in the process have APIs or webhooks
  • The workflow is trigger-based (a new form submission triggers a sequence of actions)
  • No UI interaction is required

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.

Phase 4: Build Sprint (Weeks 6–12)

Sprint structure — structure the automation build as a series of 2-week sprints:

  • Sprint 1: build the core happy path (the process flow for the most common, no-exception case). Target: 70–80% of transaction volume handled.
  • Sprint 2: build exception handling for the top 3–5 exception types. Target: 90–95% of transaction volume handled.
  • Sprint 3 (if needed): handle remaining edge cases, logging, alerting, and error recovery.

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:

  • Transaction ID and timestamp
  • Input data (sanitized if it contains PII)
  • Steps completed
  • Outcome (success, exception type, routed to human queue)
  • Processing time per transaction

Logging is not optional overhead — it is the data source for ROI measurement and the primary debugging tool when the bot encounters unexpected behavior.

Phase 5: User Acceptance Testing (Weeks 11–13)

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:

  • Happy path (standard transactions)
  • Each defined exception type
  • Edge cases identified during process discovery
  • High-volume stress testing (can the bot handle the peak daily transaction volume?)
  • System unavailability simulation (what happens if a downstream system is down?)

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.

Phase 6: Go-Live and Hypercare (Weeks 13–15)

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.

Phase 7: ROI Measurement (Weeks 16–20 and Ongoing)

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.

Building the Automation Project Gantt

Structure the Gantt with these tracks:

  1. Discovery and documentation: process mapping, pain point quantification, fit assessment
  2. Tool evaluation: requirements, demos, proof of concept, selection
  3. Build sprints: Sprint 1, Sprint 2, Sprint 3 (if needed), code review
  4. Testing: UAT environment setup, test case execution, parallel run, sign-off
  5. Deployment: phased go-live, hypercare monitoring
  6. Measurement: logging validation, 30-day metrics, 90-day ROI report

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.