Why do ERP vendors consistently underestimate implementation timelines?

Vendors build their estimates around best-case conditions: clean data, engaged project teams, fast decision-making, and no scope changes. Their own published case studies reflect that: ERP Research's analysis of 299 of them found a 6-month median and describes them as best cases. A broader survey, Panorama Consulting's 2026 ERP Report of 170 organizations, found a 9-month median with almost a quarter of projects over schedule, most often because of organizational issues.

What are the five real phases of an ERP implementation and how long does each take?

A realistic implementation has five phases: Discovery and Requirements (4–8 weeks), System Design and Configuration (6–12 weeks), Development and Unit Testing (8–16 weeks), UAT and Parallel Running (4–8 weeks), and Go-Live and Hypercare (4–6 weeks). Phases overlap and problems found in UAT frequently send the team back into development, extending the overall timeline.

Why is skipping parallel running such a common cause of failed go-lives?

Parallel running — operating the old system and the new ERP simultaneously — is the only real safety net before full commitment to the new system. It is often cut to 'save time', but skipping it means there is no fallback when real-world usage exposes problems that workshops and UAT sessions missed. In the author's implementations, it has been the most common cause of catastrophic go-lives.

What does a realistic timeline look like for an Indonesian SME implementing three modules?

For a 30–100 employee company building a custom ERP for HR leave management, multi-level AP approval, and AR with automated reminders, a realistic timeline is 9–12 months. Discovery and data audit fill months 1–2, design and prototyping months 3–4, core development months 5–7, internal QA month 8, UAT months 9–10, parallel running month 11, and go-live with hypercare in month 12. A packaged cloud ERP configured with little customization can be faster: ERP Research gives 3–6 months as a planning range for small businesses.

What three factors most reliably compress an ERP project timeline without sacrificing quality?

The post identifies a full-time internal project manager (not a part-time department head), clean pre-migrated data completed before development starts, and pre-approved decision-making authority for the project lead as the three consistent accelerators. Delivering all three allows meaningful timeline compression because the biggest hidden delays — slow sign-offs, mid-development data cleanup, and requirement churn — are removed.

ERP Implementation Timeline: The Reality vs. The Sales Pitch

Why ERP projects almost always take longer than vendors promise, what phases actually consume the most time, and how to build a realistic timeline for an Indonesian SME implementation.

Key Takeaway

A six-month ERP timeline matches the best-case median of vendor-published case studies, not a typical custom build; for a custom ERP at an Indonesian SME, plan 9–12 months with explicit time for data cleaning, decisions and parallel running. Panorama's 2026 survey found organizational issues, not technology, were the most common reason projects ran over schedule.

Every ERP vendor will show you a timeline slide. It looks clean: 3 months for design, 2 months for build, 1 month for testing, go-live. Total: 6 months. That number has a basis: ERP Research's analysis (updated August 2026) of 299 vendor- and partner-published case studies puts the median at 6 months, and it calls those stories best cases. Panorama Consulting's 2026 ERP Report, a survey of 170 organizations with a median revenue of about $200 million, found a 9-month median, with almost a quarter of projects over schedule. The custom ERP builds I've run as a freelance ERP consultant for Indonesian SMEs have taken 9–14 months. This post breaks down why timelines slip, what the real phases are, and how to build a schedule that holds.

Why Vendor Timeline Estimates Are Always Optimistic

Vendors estimate timelines based on their best-case scenarios: clients who have clean data, engaged project teams, fast decision-making, and no scope changes. Those conditions rarely all hold at once. Indonesian SMEs in particular face three timeline killers that vendors rarely account for: data quality problems in legacy systems (Excel files with years of inconsistent data), slow internal decision-making cycles (every requirement change needs four sign-offs), and part-time project team members who have day jobs on top of ERP duties. The pattern is not only local: in Panorama's 2026 ERP Report, the most common reason for schedule overruns was organizational issues such as governance, resistance to change and process redesign, with approvals and sign-offs trailing the technical work.

The Five Real Phases of ERP Implementation

A realistic ERP implementation has five phases, not three. Phase 1: Discovery and Requirements (4–8 weeks) — this is where you map every business process, audit your existing data, and define what Phase 1 scope includes. Phase 2: System Design and Configuration (6–12 weeks) — detailed design, database schema, UI wireframes, integration specifications. Phase 3: Development and Unit Testing (8–16 weeks) — actual build, including all custom logic and integrations. Phase 4: UAT and Parallel Running (4–8 weeks) — users test the real system with real data while still running the old system. Phase 5: Go-Live and Hypercare (4–6 weeks) — live deployment with intensive support. Each phase bleeds into the next, and problems discovered in Phase 4 send you back to Phase 3.

Where Time Actually Goes: The Hidden Delays

From my implementations: requirements gathering always takes twice as long as planned because stakeholders don't know what they want until they see a prototype. Data migration always hits unexpected quality problems — I've never seen a clean Excel import on the first attempt. User acceptance testing (UAT) always surfaces requirements that were not captured — real users doing real work find edge cases that workshops miss. Each round of UAT feedback adds 1–2 weeks of development and retesting. Parallel running — running old system and new ERP simultaneously — is often skipped to 'save time', and in my experience skipping it is the most common cause of the catastrophic go-lives I have seen.

Realistic ERP Timeline: Indonesian SME (30–100 staff, 3 modules)

Month  1–2  │ Discovery + Requirements
             │ ● Process mapping workshops
             │ ● Data audit (legacy systems)
             │ ● Scope definition + sign-off
             │
Month  3–4  │ System Design
             │ ● Database schema
             │ ● UI wireframes
             │ ● Integration specs
             │ ● Stakeholder design review
             │
Month  5–7  │ Development
             │ ● Core module build
             │ ● Integration development
             │ ● Unit testing
             │
Month  8    │ Internal QA
             │ ● Bug fixing sprint
             │ ● Performance testing
             │
Month  9–10 │ UAT (User Acceptance Testing)
             │ ● Dept lead testing with real scenarios
             │ ● Feedback → fix → retest cycles
             │
Month  11   │ Parallel Running
             │ ● Old system + ERP running simultaneously
             │ ● Compare outputs daily
             │ ← DO NOT SKIP THIS PHASE
             │
Month  12   │ Go-Live + Hypercare
             │ ● Hard cutover
             │ ● Daily standups with dept champions
             │ ● Issue log + resolution tracking
             │
"Vendor estimate":   6 months   ← (best case, ideal client)
"My custom builds": 12 months   ← (Indonesian SME, 3 modules)

From my experience in my freelance ERP consulting work: build your timeline backwards from a hard deadline if you have one (like a fiscal year start), then identify which phases have flex and which are fixed. Discovery and UAT are fixed — they cannot be compressed without destroying quality. Development can sometimes be parallelized across modules. Never compress parallel running; it's the only real safety net you have before full commitment.

Building a Realistic Timeline: The Numbers

For an Indonesian SME (30–100 employees) implementing HR leave management, AP with multi-level approval, and AR with automated reminders — three moderately complex modules — a realistic timeline is 9–12 months. Month 1–2: discovery, process mapping, data audit. Month 3–4: system design, UI prototypes, stakeholder sign-off. Month 5–7: core development. Month 8: internal QA and bug fixing. Month 9–10: UAT with department leads. Month 11: parallel running. Month 12: go-live and hypercare begins. Projects that compress this to 6 months typically do so by skipping the data audit, rushing UAT, and skipping parallel running — and then spend months 7–12 in crisis mode fixing what breaks.

# ERP Timeline Delay Analysis — My Own Projects (indicative, not survey data)

Timeline killers and their typical delay impact:

┌──────────────────────────────────────────┬─────────────────┐
│ Cause                                    │ Delay Impact    │
├──────────────────────────────────────────┼─────────────────┤
│ Data quality worse than expected         │ +4–8 weeks      │
│ Stakeholder unavailable for sign-off     │ +2–4 weeks      │
│ Scope changes in month 5+               │ +4–12 weeks     │
│ UAT reveals missed requirements          │ +2–6 weeks      │
│ Parallel running skipped → go-live fail  │ +8–16 weeks     │
│ Part-time project team (day job conflict)│ +6–10 weeks     │
│ Integration partner delays               │ +2–4 weeks      │
└──────────────────────────────────────────┴─────────────────┘

Mitigation:
- Appoint full-time internal PM (not a dept head)
- Clean data BEFORE development starts
- Lock scope at Month 2 with signed change control process
- 100% attendance required for UAT sessions
- Never skip parallel running

The Phased Rollout Approach: Why It Works

Instead of a big-bang go-live where every module launches simultaneously, a phased rollout launches one module or department at a time. In one client engagement, I went live with HR leave management first — it was the lowest-risk module, touched every employee, and built company-wide confidence in the system before finance went live. Accounts payable went live two months later. AR followed. Each phase had its own UAT and parallel running cycle. Total timeline was 14 months from kick-off to full AR go-live, but the business never experienced a catastrophic failure because each phase was small enough to contain.

I've seen three ERP go-lives timed to coincide with month-end financial closing. All three were disasters. The system is under maximum stress from batch jobs and report generation at exactly the moment your team has minimum tolerance for delays. Schedule go-live for the second week of the month, mid-year if possible. Give yourself a full business cycle (one complete month of operations) before any financial reporting period deadline.

What Accelerates ERP Projects

Three things consistently accelerate ERP timelines: a full-time internal project manager (not a part-time department head), clean pre-migrated data (data cleaning done before development starts, not after), and pre-approved decision-making authority (the project lead can approve scope changes up to a defined limit without a 3-week approval chain). If you can deliver these three, you can meaningfully compress the timeline without sacrificing quality.

Setting Expectations With Your Board or Leadership

The most useful thing you can do before starting an ERP project is to present a realistic timeline to your board and get explicit approval — not just for the timeline, but for the resources it requires. A 12-month implementation means 12 months of disruption to your team's normal operations. It means a full-time internal project lead for 12 months. It means UAT sessions that pull department heads out of their day jobs for 2–4 weeks. Getting sign-off on these resource commitments upfront is what separates implementations that succeed from those that get quietly abandoned at month 8.

Sources & Further Reading