Find the best NetSuite partner for ERP implementation services. Get expert assistance in planning and partnering for a successful project.
Two decisions determine more about how an ERP project goes than everything else combined. Who you do it with, and how carefully you plan it before you start. Both are made early, both are difficult to reverse, and both are routinely made faster than they deserve.
Everything after those two decisions is execution, and good execution cannot rescue a bad partner choice or an absent plan. This article covers how to make each one properly.
Software selection gets most of the attention in an ERP programme, and it is usually the least consequential of the major decisions.
The major platforms are all capable. A business that would succeed with one would generally succeed with another, because the differences between them are smaller than the differences between a well run project and a badly run one.
The partner determines whether the system fits your business, whether the decisions have reasons attached to them, and who you are dealing with when something goes wrong in year three.
The plan determines whether the project has a realistic shape, whether the internal effort is protected, and whether anybody has thought about what happens after go live.
Partners present capability, references and methodology. What you are actually buying is a group of specific people and a way of making decisions.
The methodology matters less than it appears, since every partner has one and they are broadly similar. The individuals matter enormously, because a project is a series of judgement calls made by whoever is in the room.
Which is why the most useful question during selection is who specifically will be on our project, how much of their time, and what have they done before.
Proposals that name senior people who then appear only at steering meetings are common enough to be worth asking about directly.
The question about projects that went badly is the most informative. Partners with real experience answer it readily and specifically. Partners who claim everything has gone well have either not done many projects or are not being straight with you.
NetSuite partners come in different commercial forms and the differences affect the advice you get.
A solution provider resells the software, so part of their revenue depends on licence volume. Many give excellent advice and the structural interest exists.
An alliance partner delivers services while the licence relationship sits between you and Oracle NetSuite, so their revenue depends on delivery rather than on what you buy.
Neither structure guarantees anything about quality. What matters is understanding the incentive when you are weighing a recommendation about scope or modules.
Our piece on solution providers and alliance partners sets out the distinction in detail.
For an Australian business, some domain knowledge is not optional and is not learnable during your project.
Payroll is the clearest case. Modern award interpretation, Single Touch Payroll Phase 2 reporting, superannuation on ordinary time earnings, long service leave varying by state, payroll tax with different thresholds and grouping provisions in each jurisdiction.
Statutory reporting and Australian accounting standards are similar, though less frequently a project risk.
Timezone matters more than people expect during design, since design is conversational and conversation across a twelve hour gap is materially slower.
A partner without local depth can deliver a competent implementation and will need you to supply the domain knowledge, which is worth knowing before you sign rather than after.
Reference calls are usually a formality and they can be genuinely informative if the questions are right.
Ask what went wrong, since every project has something, and how the partner handled it. That answer tells you more than a description of what went well.
Ask whether the people who sold the project were the people who delivered it.
Ask how much internal time it actually took compared to what was estimated.
Ask what they would do differently, and whether they would use the same partner again.
And where possible, speak to somebody two or three years past go live rather than someone freshly live, because the questions that matter are about how the system aged.
The document a partner produces tells you a good deal about how they work, if you read it for the right things.
A proposal that describes your business back to you in specific terms indicates that somebody listened. One that is largely generic with your name inserted indicates that nobody did.
Look at how the assumptions are stated. A proposal with no assumptions is either hiding them or has not thought about them, and both become variations later.
Look at what is explicitly out of scope, since a proposal that only describes inclusions is leaving the boundary undefined, and undefined boundaries are where the arguments live.
And look at whether the estimate for your effort is present at all. Partners who have run real projects know how much client time an implementation consumes and say so. Partners who omit it are either inexperienced or are avoiding an uncomfortable conversation that will happen anyway.
A project plan that is a list of phases with dates is not a plan. A useful one answers a specific set of questions.
What is in scope and, more importantly, what is explicitly out, since undefined scope is where the arguments come from.
Who from your business is involved, in what role, for how many hours per week, and what they are being relieved of in order to do it.
What decisions have to be made, by whom, by when, since projects stall on decisions far more often than on work.
What the data migration actually involves, including how much history and who does the cleansing.
And what happens after go live, for how long, at what level of support.
The most common planning failure is assuming that internal capacity will be found rather than allocated.
ERP implementations require substantial time from the people who understand the processes, and those are always the busiest people in the business.
Where their project time is added to a full workload, one of two things happens. Either the project slips because they cannot attend, or their normal work suffers and somebody notices at the worst moment.
The fix is unglamorous. Work out how many hours per week each person needs, decide what they will stop doing, and put both in writing.
Projects that do this run considerably more smoothly than projects that do not, and the difference is visible within the first month.
A plan needs an explicit position on whether the business intends to redesign its processes or replicate them.
Redesign produces more value and a harder project. Replication produces a faster project and frequently carries forward every inefficiency the old system had.
Neither is wrong and not deciding is, because a project without a stated position defaults to replication. Replication is what people ask for when asked what they need, since they describe what they do now.
This decision also drives the approach, the timeline and the amount of change management required, which is why it belongs at the front rather than emerging during design.
Data migration is the most consistently underestimated element of any implementation and the one most likely to move the go live date.
Decide early how much history you actually need, and challenge the answer, since more history means more effort and the requirement is frequently met by keeping the old system available in read only form.
Recognise that master data cleansing is business work rather than partner work, because deciding whether two customer records are the same customer requires knowing the business.
Allow time for reconciliation after loading, since data that loaded successfully is not the same as data that is correct.
Our data migration checklist covers the detail.
Training that sits as a line inside the project absorbs the slippage from everything upstream, which is why it so reliably gets compressed into the final fortnight.
Give it its own budget and its own dates, protected from the rest of the plan.
Involve whoever will deliver it during design, so they understand why decisions were made and can explain rather than describe.
And schedule it against first use rather than against go live, so that month end training happens before the first month end rather than weeks earlier when it will be forgotten.
Most plans end at go live, which is where the value actually starts and where the real problems appear.
The plan should name what support looks like for the first month, the first quarter and beyond, at what level and from whom.
It should identify what was deliberately deferred, so that the deferred list is a plan rather than a document nobody opens.
It should include the first month end explicitly, treated as an event with its own preparation rather than as business as usual.
And it should name who inside the business owns the system afterwards, because a system nobody owns drifts within a year.
Risk registers are frequently generic. The ones that matter on ERP projects are specific and recurring.
Key person dependency, where one person understands a process and their availability determines the timeline.
Data quality worse than expected, which is the most common cause of date movement.
Scope creep through accumulated small requests, each reasonable and collectively significant.
Decision delay, where the project waits on somebody who has not been told they are on the critical path.
And competing business priorities, particularly a peak trading period or a transaction that was not disclosed at planning time.
Project governance on mid sized implementations is frequently either absent or theatrical, and neither helps.
What is actually needed is a short weekly operational meeting that deals with issues and decisions, and a monthly steering conversation that deals with scope, budget and risk.
The steering group needs somebody who can make decisions in the room, since a governance forum that refers everything onward adds delay rather than control.
And reporting should be honest rather than green. A project that reports green until two weeks before go live has a reporting problem in addition to whatever else is wrong.
Choosing a partner is the beginning of a working relationship rather than the end of a procurement exercise, and how it is conducted affects the outcome.
Be a good client, which mostly means making decisions when asked, providing the people you committed, and raising concerns early rather than accumulating them.
Expect the partner to push back, and value it when they do. A partner who agrees to everything is agreeable and expensive, since every accepted request becomes something you own for the life of the system.
Escalate through the relationship rather than around it. A concern raised directly and early is usually resolvable. The same concern raised three months later through a formal channel has become a dispute.
And keep the commercial conversation separate from the delivery one, because mixing them tends to make both worse and it puts the delivery team in an impossible position.
Get the partner and the plan right and most of what follows is manageable. Get either wrong and good execution cannot compensate.
The practical starting point is to write down, before speaking to any partner, what you want the system to make possible that is impossible now, how much your processes should change, and how much of your people's time you can genuinely protect.
Those three answers shape the partner conversation and prevent the most common failure, which is a plan built on capacity nobody could provide.
Our pieces on comparing implementation approaches and the implementation journey cover what comes next, and the guide for client side project managers covers your side of it.
If you would like to talk through your own project, get in touch.
