How to Build an ERP Project Plan (WBS, Gates, RAID & a 100-Day Start)

What is an ERP project plan?

An ERP project plan is the single control document that defines how your ERP implementation will actually be delivered: the scope baseline, the work broken into packages, the schedule with dates and dependencies, the people accountable for each piece, the budget envelope, the milestones that gate progress, and the risks and decisions being actively managed. It is the difference between a rollout that ships on time and one that drifts into the well-documented majority of projects that miss their objectives.

It is important to separate three things buyers often confuse. A business case justifies why you are doing ERP and what return you expect. An implementation methodology — such as the six-phase Discovery, Design, Development, Testing, Deployment, Support lifecycle or Microsoft's Success by Design — describes the proven sequence of work. The project plan is the specific, dated instance of that methodology applied to your organization: who, what, when, with what, against what gates, and how change is controlled.

For SMEs especially, the plan is the antidote to the two failure modes that sink most rollouts: scope creep and optimistic scheduling. Gartner predicts that by 2027 more than 70% of recently implemented ERP initiatives will fail to fully meet their original business case goals, and as many as 25% will fail catastrophically. A disciplined plan does not eliminate risk, but it makes risk, assumptions, issues, and decisions visible early enough to act on — which is the entire point.

A methodology is not a project plan

Vendors and partners sell methodologies, and methodologies are valuable: they encode lessons from hundreds of prior projects and give you a reliable sequence. Microsoft's Success by Design, for example, structures Dynamics 365 delivery around five implementation phases — Strategize, Initiate, Implement, Prepare, and Operate — with explicit guidance on solution architecture, project governance, change management, testing, and preparation for go-live. The widely used industry lifecycle adds a sixth framing: Discovery, Design, Development, Testing, Deployment, and Post-go-live Support.

But a methodology is generic by design. It cannot tell you that your warehouse barcode integration lands on the critical path, or that your finance close calendar forces a mid-month cutover freeze, or that your single IT hire is over-allocated across three work streams. Those facts live only in your project plan. Buying a methodology and calling it a plan is the most common planning error: it produces a Gantt chart that looks complete but contains no decisions, no owners, and no risk.

The right mental model is that methodology is the mold and the project plan is the casting. You select a methodology that fits your platform and scale, then you instantiate it: you map its phases onto your calendar, decompose its activities into a work breakdown structure, assign named owners, attach budget, and surface the dependencies and risks that are unique to your business. The plan is what gets reviewed at every steering meeting; the methodology is what keeps the plan honest.

The seven components of an ERP project plan

A workable ERP project plan is built from seven interlocking components. Each component is a deliverable in its own right, and each must be baselined — that is, frozen at a known version — so that deviations can be measured rather than argued about. Skip any one and the plan develops the blind spots that turn into go-live surprises.

The components are not optional layers of process for large enterprises only. Even a lean SME rollout benefits from a lightweight version of each: a one-page charter, a spreadsheet WBS, a shared schedule, a milestone checklist, a named team, a budget tracker, and a risk log. The cost of producing them is trivial compared with the cost of recovering from an uncontrolled change request two months before go-live.

Build the work breakdown structure first

The work breakdown structure (WBS) is the backbone of the plan. It decomposes the implementation into deliverable-oriented work packages — each small enough to estimate, assign, and track. The discipline of a WBS is that it is organized by deliverable, not by task: you do not list 'attend workshops'; you list 'future-state process design for order-to-cash', because deliverables are what get accepted and signed off. The WBS is the structure on which the schedule, the budget, and the RACI all hang; everything else is a view of it.

Start from your chosen methodology's phases and decompose each into two or three levels. The rule is the 100% rule: the children of any node must add up to 100% of the parent, with no overlap and no gaps. Each work package should be sized so a single owner can account for it — typically eight to 80 hours of effort — and should carry a clear acceptance criterion. A package like 'configure sales pricing' is too vague to estimate; 'configure tiered customer pricing with three discount bands and approval workflow' is estimable and testable.

The WBS is also where over-customization gets caught early. If you find yourself creating large 'custom build' work packages before process mapping is complete, the plan is telling you that future maintenance cost is being designed in. A common and expensive pattern is to let the WBS be driven by the gaps in standard functionality before anyone has tested whether configuration can close them.

Sequence the schedule around milestone gates

Once the WBS exists, the schedule is a matter of sequencing the work packages, attaching realistic durations, and linking the dependencies. The dependencies matter more than the durations: most late projects are not late because individual tasks ran long, but because the critical path was misidentified and a hidden dependency (a data extract, a third-party API, a regulatory sign-off) landed late. Map finish-to-start relationships honestly and the critical path will reveal itself — along with the tasks that have zero float and therefore dictate your go-live date.

Be skeptical of under-three-month timelines. For SMEs and small businesses a realistic implementation runs three to nine months — three to six for smaller, less complex scopes and six to nine for mid-sized rollouts — and vendors promising faster almost always do so by cutting change management, training, or data migration. Your schedule should reflect that reality; if the date is fixed externally (a lease renewal, a fiscal-year close), then scope and resources must flex instead, because the schedule cannot honestly compress without dropping work packages.

The schedule's most useful artifacts are the milestone gates. These are decision points, not just dates: each gate has entry criteria, exit criteria, and an explicit go / hold / no-go decision by the steering committee. Gates force the conversation that prevents runaway scope — you cannot pass 'design complete' while core decisions are still open.

UAT, cutover, and hypercare are not footnotes at the end of the Gantt. Each needs its own work packages with named owners and exit criteria: UAT scripts mapped to end-to-end processes, at least one full mock cutover timed against the real data volume, a written go/no-go checklist, and a hypercare ticket threshold for exit. Link those packages to the team-roles model (sponsor, PMO, process owners, partner) so accountability is obvious when the readiness review arrives.

Governance and RACI: who decides what

ERP projects fail at decision boundaries far more often than at task execution. Governance is the structure that makes decisions happen on time: who owns the project day to day, who arbitrates change requests, who can approve budget movement, and who has authority over scope. Microsoft's Success by Design treats project governance as a first-class workstream under its Initiate phase, because without it the steering committee becomes a status-update meeting rather than a decision body. A workable model is three tiers: an executive sponsor who owns the business case, a steering committee that meets on a fixed cadence to decide at gates, and a project manager (or PMO) who runs the plan day to day.

Underneath governance sits RACI — a responsibility matrix that names, for each major activity, who is Responsible (does the work), Accountable (owns the outcome and signs off), Consulted (provides input), and Informed (kept up to date). The value of RACI is not the acronym; it is the act of writing it down. The moment you assign 'accountable' owners, the hidden single points of failure become visible — the one finance lead who is accountable for data migration, master data, UAT, and training simultaneously is a planning bug, not a staffing convenience.

RACI also resolves the most common political friction in an ERP rollout: ambiguity between the partner and the client. Every work package should have a clear client accountable owner as well as a partner owner, because work that is 'the partner's job' but never gets a client to provide decisions or data is work that slips silently. Documenting this up front prevents the late-project argument about who was supposed to deliver the cleansed customer master.

RACI only works if the named people have capacity. Overlay a simple resource histogram (hours per person per week) on the schedule: if the same process owner is R or A on discovery workshops, data cleansing, UAT scripts, and end-user training in the same month, the plan is lying. See the resource-loading section below for practical SME allocation ranges and how to protect critical path capacity.

Resource loading: protect internal SME capacity

Most ERP schedules fail because they treat internal subject-matter experts as infinitely available. Controllers, warehouse leads, and sales ops managers still have month-end, shipping peaks, and quota pressure. If the plan books them for full-day workshops on top of their day job, the critical path slips without anyone updating the Gantt. Resource loading — a simple histogram of planned project hours per person per week — is how you catch that before kickoff, not at UAT.

Industry implementation advisors commonly recommend dedicating 30–50% of select internal SMEs' time for the duration of the project, with full-time dedication for highly involved roles such as the client project lead or master-data owner. That often means temporarily backfilling operational work. A plan that lists names without hours is not a resource plan; it is a hope. Build the histogram from the WBS effort estimates, not from job titles, and re-check it at every gate when scope or dates move.

Peak load usually hits three windows: discovery workshops, data cleansing and trial loads, and UAT plus training. Stagger those peaks across people when you can — the same finance lead should not own trial-load reconciliation and write all UAT scripts in the same fortnight. Where you cannot stagger, buy capacity: temporary staff, partner-led data profiling, or deferred non-critical process scope. The schedule's critical path is often a person, not a task.

RAID log and change control: the active controls

Two living artifacts do more than any other to keep an ERP plan on track: a RAID log and a formal change-control process. RAID stands for Risks, Assumptions (or Actions), Issues, and Dependencies (or Decisions) — practitioners use slight variants of the acronym, but the discipline is the same: one central log, reviewed at every steering meeting, with an owner and status on every entry. The risk register is the R of RAID; folding assumptions, open issues, and critical decisions into the same log stops them from living only in email threads.

ERP-specific RAID entries cluster in predictable places: dirty or fragmented source data, third-party integration dependencies, key-user availability, fiscal-calendar or lease-driven cutover windows, regulatory sign-offs, and adoption resistance. Practitioners repeatedly warn that data migration is the trust killer at go-live — rehearsal loads that use only a fraction of production volume systematically understate cutover duration, because index rebuilds, conversion, and reconciliation do not scale linearly with row count. Log that risk early, own it, and schedule full-scale mock cutovers in the plan.

Change control is the process by which any deviation from the scope baseline is formally requested, costed, and decided. Without it, every workshop generates new requirements that silently expand the build; with it, those requirements are absorbed into a phase, deferred to an enhancement backlog, or approved with budget and timeline impact visible to the sponsor. A practical SME rule: no change is built until it is logged, costed, and either approved at a gate or batched for the next steering meeting. Change control does not prevent change — it makes change a decision instead of an accident.

A lightweight change-control process that actually runs

Change control fails when it is either a binder nobody opens or a veto that freezes the project. For SMEs, a lightweight weekly cadence is enough: anyone can raise a change request (CR); the PMO logs it within one business day; the partner and process owner estimate effort and schedule impact; the steering committee (or sponsor, under a pre-agreed threshold) decides approve, defer, or reject. Approved CRs update the baselined scope, schedule, budget, and SOW amendment if commercial terms change.

Write the thresholds into the plan before kickoff. Example: under two partner days and no go-live impact — project lead may approve with sponsor informed; above that or any go-live movement — steering only. Every CR gets a one-line business reason tied to the original success metrics. 'Nice to have' without a metric is a backlog item, not a CR. That single rule kills most mid-project scope creep without drama.

Close the loop in the RAID log. Approved changes that introduce new risks or dependencies get RAID entries; rejected changes stay visible so the same request is not re-raised three times in workshops. At hypercare exit, freeze the change log and open a formal enhancement backlog so post-go-live improvement does not masquerade as unfinished implementation scope.

Align the plan to the commercial SOW

The statement of work (SOW) is the commercial contract that defines scope, deliverables, responsibilities, timeline bands, and acceptance criteria between you and the implementation partner. The project plan is the operational execution of that contract. When the two diverge — vague SOW deliverables, or a plan that invents work the SOW never funded — you get the classic overrun pattern: the technology is fine, but the proposal hid scope gaps and unowned assumptions. ERP practitioners and partners repeatedly flag bad proposals and misaligned SOWs as a primary driver of budget blowouts, not the software itself.

Make the mapping explicit. Every SOW deliverable should appear as one or more WBS packages with acceptance criteria that match the contract language (or a deliverable expectation document if your SOW uses that pattern). Every plan milestone gate should map to a commercial milestone or payment trigger when your SOW uses staged billing. Out-of-scope items in the SOW must appear as explicit exclusions in the charter so workshop wish-lists do not silently re-enter the build. Assumptions in the SOW — client data quality, client SME availability, third-party API readiness — become RAID assumptions with owners and review dates.

Use the plan review at kickoff as a SOW audit. Walk the partner through the WBS and ask, for each package: is this in the fixed fee, time-and-materials, or change-order territory? Who accepts it, and what evidence closes it? If the partner cannot answer without improvising, the commercial document is incomplete and the plan will absorb the ambiguity as free scope. Update both documents together when change control approves a change — never let the Gantt become the only record of what was sold.

The fast-start ERP 100-day plan

When you hire an ERP implementation partner, the most useful first deliverable is a 100-day plan — a structured first roughly three months that mobilizes the project, establishes the scope baseline, and gets the core of the system configured in a sandbox before the heavy build begins. The 100-day plan is not a shortcut to go-live; a responsible ERP rollout for an SME takes three to nine months, and any plan that promises live production in 100 days is cutting the exact steps — data migration, training, change management — whose absence causes failure. What the 100-day plan does is de-risk everything that follows by front-loading the decisions and the discovery that most projects defer until they are expensive to fix.

The 100-day plan is valuable because the cost of a decision rises steeply over the life of a project. A process change caught in week four costs hours; the same change caught in week fourteen, after configuration and data mapping, costs weeks. By compressing mobilization, discovery, and the first configuration pass into the opening window, the plan moves the bulk of the expensive decisions into the cheapest place to make them. It also produces an early, tangible artifact — a configured sandbox running real scenarios — that gives the steering committee something concrete to react to instead of a status slide.

The structure below assumes a partner engaged at the start, working against a baselined charter. It is deliberately honest about scope: the goal at day 100 is a signed-off design and a configured sandbox with trial data loads, not a live system. Organizations that treat the 100-day plan as a full go-live are the ones whose projects fail at the predictably late, predictably expensive moments.

How rollout strategy reshapes the plan

The plan's shape changes with the rollout strategy you choose. The two extremes are big-bang — everything goes live in a single cutover — and phased rollout, where modules or sites go live in sequence. Captivea and other practitioners describe these as contrasting approaches with real trade-offs: big-bang is faster overall and avoids a dual-system period but concentrates risk at one moment, while phased rollout lowers risk and delivers early wins at the cost of a longer timeline and temporary operation of old and new systems side by side. Most modern SME implementations favor phased, agile-inspired delivery, but neither is universally correct.

The decision belongs in the plan because it changes the WBS and the schedule, not just the go-live day. A phased rollout adds a wave structure: each phase has its own build, test, and cutover packages, plus a temporary integration layer that keeps the legacy system alive for the not-yet-migrated functions. A big-bang plan collapses those waves into one but inflates the cutover work package and the hypercare package, because everything stabilizes at once. A hybrid is also legitimate — critical modules live in a single wave, secondary modules staggered — and is often the pragmatic answer for SMEs with a core must-have set and a longer tail of nice-to-haves.

Make the rollout choice early and document the reasoning in the charter. Leaving it ambiguous forces the WBS to hedge, which inflates every estimate, and tends to default to big-bang by accident as the deadline approaches — the highest-risk option, chosen under the most time pressure.

Common ERP planning mistakes to avoid

Most planning failures are predictable and avoidable. The first is the un-baselined plan: a schedule that exists only as a draft, constantly edited, so no one can tell whether the project is on track because there is no fixed point to measure against. Baseline the plan at kickoff and re-baseline only at gates, logging every change. The second is the under-resourced PMO: SMEs often assign project management as a side duty to someone with a full operational job, which guarantees that risks go unmanaged and the schedule drifts until it is unrecoverable. Project management is a workstream, not an afterthought.

The third mistake is optimistic scheduling that ignores dependencies and data effort. Data migration is routinely the single most underestimated workstream; a plan that treats it as a single 'load data' task near go-live is a plan that will slip. Profile the source data early, run trial loads during the build phase, and reconcile them — this work belongs in the WBS from day one. Rehearse cutover at production-scale volume at least once; extrapolating from a tiny test extract almost always understates conversion and validation time.

The fourth is a SOW and plan that do not match — commercial deliverables without WBS packages, or plan packages the partner never sold. The fifth is missing change control, which lets scope creep silently until UAT reveals a system built for a different spec than the one everyone remembers approving. The sixth, and the one that most often sinks otherwise well-planned projects, is treating change management and training as optional tail-end activities. Prosci research on ERP implementations finds human factors matter far more than technical factors for realizing benefits; back-loading training into the final two weeks produces users who are unprepared on go-live day. Build role-based training and super-user enablement into the schedule from the Prepare phase, and budget for it as a first-class line item.

Why a partner's plan compresses time without cutting corners

A good implementation partner brings more than configuration skill — they bring a tested planning template, a reusable work breakdown structure, and accelerators that compress the manual-heavy steps of the plan. The right partner will arrive with a 100-day plan already shaped by prior projects, so the first three months are spent refining and executing rather than inventing the structure from scratch. That is where genuinely faster delivery comes from: reusable artifacts and disciplined execution, not skipped phases.

The planning conversation is also the best moment to evaluate a partner. Ask to see their methodology mapped onto a sample WBS and schedule, ask how they run change control, and ask what their standard milestone gates and readiness review look like. A partner who cannot show you the plan they will run is a partner who will improvise on your budget. Relevant industry experience, platform certifications, a documented methodology, transparent pricing, post-go-live support, and references remain the core selection criteria.

This is also where platform neutrality pays off. A partner who sells only one stack will fit the plan to that stack regardless of fit; a neutral partner builds the plan around your business first and recommends the platform — whether Microsoft Dynamics 365 or Odoo — that the discovery actually supports. The ERP implementation methodology should be chosen before the platform decision is forced, not after.

Turn the plan into a project

If you are starting an ERP rollout — or recovering one whose plan never got baselined — the fastest way forward is a planning session that produces a real charter, a WBS, a dated schedule, and a 100-day plan you can act on the next week. In 30 minutes you can confirm your platform fit, get a qualified timeline and cost range, and leave with the first three milestones defined.

Start with Flectic ERP services to scope the engagement, then move to implementation and customization for the build plan. Use the ERP implementation guide as the methodology backdrop, the implementation team roles guide when you fill the RACI, and the ERP go-live checklist when you convert M6–M8 into an executable cutover runbook.

Frequently asked questions