Discover key strategies for a successful ERP upgrade with our comprehensive ERP Implementation Plan. Maximise ROI and Go Live faster!
An ERP implementation plan is not a Gantt chart. The chart is an output, and businesses that treat it as the plan tend to discover in month four that the document describes a project nobody is actually running.
The plan is the set of decisions underneath. What is in scope and what is not, who decides what, how change gets handled, what has to be true before each phase begins, and what the business is committing to contribute. Get those right and the schedule mostly follows. Get them wrong and no amount of replanning helps.
This article sets out what a genuinely useful implementation plan contains, written for the person who has to produce or approve one.
Every plan should open with the objectives, stated specifically enough that somebody could later establish whether they were met.
"Modernise our systems" is not an objective anyone can plan against. "Reduce month end close from eleven working days to five, provide stock visibility across all three warehouses, and produce profitability by project" is.
Rank them, because you will face trade offs and a ranked list resolves them without a meeting. When somebody proposes an addition, the question of which objective it serves settles a surprising proportion of scope conversations.
And write down what is explicitly not an objective. Projects acquire ambition, and a documented boundary is what makes deferral a decision rather than an argument.
Scope statements that only list what is included are half a definition, and the missing half is where disputes come from.
List the modules and functional areas in scope, the entities and locations covered, the integrations being built, the data being migrated and the reporting being delivered.
Then list what is out. Modules deferred to a later phase, entities not included, integrations that will remain manual, historical data that will stay in the old system. Being explicit about these prevents them being assumed in.
The out of scope list is also where a phase two begins its life. Items that go on it should carry enough detail that somebody could later scope them without reconstructing the reasoning.
This is the section most plans handle weakly and the one that most determines pace.
Name the sponsor, the person accountable for the project delivering its objectives, with the authority to resolve conflicts between departments.
Name the project owner from the business, the person running it day to day, and state explicitly what they can decide alone.
Name the process owners per function, the people who speak for how their area works and who will be held to those answers.
And state the escalation path with a timeframe. Decisions that cannot be made at the project level go somewhere specific, and they go there within a defined period rather than waiting for the next scheduled meeting.
Decision latency is the largest hidden cost in most implementations, and it is entirely determined by this section.
The plan should state what the business is contributing, in hours, by named person, by phase.
This is uncomfortable because it usually reveals that the project owner is expected to do this alongside a full role, and that process owners have not actually been released by their managers.
Better to have that conversation while the plan is being written than in month three when workshops are being rescheduled. Where the resourcing is not available, the correct response is a longer timeline rather than the same timeline with less involvement, and saying so in the plan makes that a decision rather than a discovery.
It is also worth naming the partner's team, with the expectation that those are the people who will actually appear. Plans that describe a partner team in general terms leave room for substitution.
A phase list with dates is a schedule. A phase list with criteria is a plan.
For each phase, state what must be true before it starts and what must be true before it is considered complete. Design cannot start until the process documentation is signed off. Build cannot start until the design is approved. User acceptance testing cannot start until the test data is loaded and the scenarios are written.
The value is that phases stop overlapping by accident. The most common way a project loses control is that a phase is declared complete on its scheduled date rather than on its criteria, and the incomplete work migrates silently into the next phase.
Exit criteria also make status reporting honest. A phase is complete or it is not, rather than being ninety per cent done for three weeks.
Data deserves its own section rather than a line in the build phase, because it is the most reliable source of delay.
The plan should state what data is moving, how much history, from which systems, who owns cleansing, and how many trial loads are planned before the final one.
It should also state who reconciles each load. The partner can confirm records arrived and only the business can confirm they are correct, and plans that leave this ambiguous find it happening late or not at all.
And it should start early. A migration workstream that begins in parallel with design rather than after build is the single most effective structural choice available, because the first trial load always reveals something and you want that in week six.
Testing appears in every plan and is genuinely planned in comparatively few.
A useful testing section separates the partner's testing from user acceptance testing, because they answer different questions. The partner tests that what was built works. The business tests that it supports how the business actually operates.
It names who tests what, with scenarios written in advance rather than left to exploration.
It allocates real time, booked, rather than assuming people will fit it around their existing work.
And it defines how defects are triaged, because the list will be longer than can be fixed before go live and the criteria for must fix versus can wait need agreeing while everyone is calm.
The plan should say who is trained, on what, when, in what format, and who produces the material.
Role specific rather than generic, delivered close to go live rather than weeks ahead, hands on rather than demonstrated, and using the configured system with recognisable data.
It should also cover what happens after go live, because training that ends at cutover leaves new starters and the questions people only develop once they have used the system.
Our piece on NetSuite training strategies covers how to structure this so it changes behaviour rather than filling a slot in the plan.
Cutover needs its own detailed plan, produced well before the weekend it describes.
Every task, its owner, its expected duration, its dependencies and its start time. Final data loads, opening balances, reconciliation, system switching, verification.
Defined go or no go criteria, agreed in advance in writing, so the decision is made against a standard rather than against how tired everyone is at two in the morning.
A rollback position, documented even though it will probably not be used, because the value is in having thought it through.
And a contact list with people who are genuinely available rather than nominally contactable.
The most common structural omission in ERP plans is that they end at cutover.
The weeks after go live determine adoption, because the workarounds people invent in the first fortnight tend to become permanent. A plan that does not resource that period has left the hardest part unmanaged.
Include hypercare with named people and defined availability. Include the first month end, which will take longer and needs support. Include a schedule for the refinements that always follow. And include the point at which the project formally hands over to ongoing support, with whoever is providing it.
Where that ongoing capability will not sit internally, arranging it before go live rather than afterwards is considerably more efficient, which is what managed services arrangements exist to provide.
Risk registers are frequently filled in as a formality, and the useful version is short and specific.
The risks that actually materialise on ERP projects are consistent. Key people becoming unavailable. Data condition worse than assessed. Integration dependencies on third parties who are slow to engage. Scope growth through accumulation. Testing revealing a fundamental mismatch. Business capacity being lower than planned.
For each, state what would tell you it is happening, what you would do, and who decides. A risk with no trigger and no response is a note rather than a control.
And review the register properly rather than rolling it forward unchanged, because a register that never changes is not being used.
Scope grows through accumulation, and each addition is individually reasonable, which is exactly why an explicit process is needed.
The process needs to be light enough to use. A written request, an assessment of effort and impact on the timeline, and a decision by a named person.
The most useful element is a visible deferral list. Most requests are legitimate and simply do not need to be in the first release, and putting them somewhere visible makes deferral feel like scheduling rather than rejection.
And the discipline that matters most is that accepted changes adjust the plan. Accepting scope without adjusting time or budget is how a plan quietly stops being real.
Status reporting should describe completion against criteria rather than activity.
"Configuration in progress" is activity. "Twelve of eighteen design decisions approved, four outstanding beyond their due date" is status, and it tells the reader whether to be concerned.
Keep the audience distinction clear. The steering group needs exceptions, decisions required and anything off track. The wider business needs a short, regular note about what is happening and what will change for them.
And report problems early. Projects that only report good news lose credibility the moment something visible goes wrong, and something always does.
A plan whose budget covers only the implementation fee is incomplete in predictable ways.
Include internal time, which is real cost even without an invoice. Include data cleansing effort. Include training, both initial and ongoing. Include the post go live support arrangement. Include contingency, because something will vary.
And budget for the twelve months after go live rather than only the project, because reporting gets built out, deferred items get delivered and refinements get made. Businesses that treat go live as the end of spending are the ones that end up using half of what they bought.
A plan written once and filed is decoration. The useful version is revisited.
Review it at each phase boundary against the exit criteria. Update it when scope changes rather than letting the document and the project diverge. Revisit the risk register when circumstances change. And check the objectives periodically, because projects drift and the ranked objective list is what pulls them back.
The test of whether a plan is real is simple. Could somebody joining the project read it and understand what is happening, what has been decided and what is outstanding? If not, the plan is a document rather than a working artefact.
A good implementation plan is mostly a set of decisions made early and written down, and the effort of making them is what produces the schedule rather than the other way round.
Our guide to navigating the implementation journey covers each phase from the client's side, and our piece on comparing implementation approaches covers the structural choice the plan sits on top of.
Where preparation is the immediate question, preparing from day one covers what to do before any of this begins, and our approach to NetSuite implementation sets out how we structure projects.
If you are producing or reviewing a plan and would like a second opinion, get in touch.
