Discover key roles, skills, and strategies for successful ERP implementation in our guide, ideal for Client-Side PMs.
Somebody in your business has been handed the NetSuite project. Often they were not asked, they were told, and often they have never run an ERP implementation before. If that is you, this is written for you.
The role is unusual because you sit between two groups with different knowledge and different incentives. The partner knows the software and has done this many times. Your colleagues know the business and have done this never. Your job is to make those two sets of knowledge meet, and almost everything that goes wrong in an implementation goes wrong at that join.
The title says project manager, which suggests plans and status reports. Those matter, and they are not the substance of the job.
The substance is decision brokering. An ERP implementation generates a continuous stream of questions that only the business can answer, and most of them cut across departments. Which approval limits apply to whom. Whether the sales team's discount practice is a rule or a habit. What counts as a project for reporting purposes. Your value is in getting these answered correctly and quickly.
Alongside that sits translation. The partner will describe things in NetSuite terms, and your colleagues will describe things in your business's terms, and neither will consistently notice when they have failed to understand each other. Someone has to catch that, and it will be you.
And there is advocacy. When the partner proposes something that will not work for how your business actually operates, someone has to say so with enough confidence to be taken seriously. That is difficult when they are the experts and you are learning, and it is the part of the role that matters most.
Three things are worth settling before the project begins, because settling them later is much harder.
The first is your authority. Can you make decisions, or must every one go to a steering group? A project where the manager can decide moves at a completely different pace from one where they can only escalate. If you do not have decision rights, get clear on exactly which decisions do need escalating and how quickly that can happen.
The second is your time. If you are doing this alongside a full role, know what has been taken off you. Nothing being taken off you is a signal about how the project is actually regarded, and it is better to have that conversation now than in month three.
The third is what success means. Write down what the business expects to be true when this is finished, in specific terms. It becomes the reference point every time someone proposes adding something.
You do not need to become an expert and you cannot function on nothing. What you need is enough vocabulary to follow a conversation and enough understanding to know when something sounds wrong.
Learn the record model, meaning how customers, vendors, items and transactions relate. Learn what a saved search is and roughly what it can do, because a large share of requirements turn out to be saved searches. Learn the difference between configuration, workflow and script, because that distinction drives cost more than anything else you will encounter.
Ask the partner for access to a sandbox and spend time in it. An hour clicking through the system teaches more than a day of documentation, and it makes you far harder to mislead.
The signal you are looking for is being able to ask a follow up question. If every answer ends the conversation, you do not yet know enough to challenge anything.
You need process owners from each affected function, and choosing them well matters more than most people expect.
Pick people who actually do the work rather than only manage it. A finance manager knows how the process is supposed to run. The person who processes the invoices knows how it actually runs, including the exceptions, and the exceptions are where implementations come unstuck.
Pick people whose managers have genuinely agreed to release them. A nominal process owner who cannot attend workshops is worse than no nominee, because their absence goes unnoticed until decisions have been made without them.
And pick at least some people who are sceptical. Enthusiasts will tell you it is going well. Sceptics will tell you what is wrong, which is considerably more useful.
Discovery is where the partner learns your business, and your job is to make that learning accurate rather than polite.
The instinct in a workshop is to describe the process as it should work. Resist it. Describe what actually happens, including the spreadsheet, the informal approval, the step that exists because of something that went wrong in 2019. A system configured against an idealised process will not fit the real one.
Push for the partner to observe rather than only ask. Watching an order go from enquiry through to cash reveals things nobody would have thought to mention.
And read whatever discovery produces properly, line by line, with your process owners. It is the cheapest correction point in the entire project. A misunderstanding caught here costs a conversation. The same misunderstanding caught in testing costs a rebuild.
This is the mechanical core of the role and the thing that most determines whether the project runs to time.
Keep a decision log. Every decision, who made it, when, and the reasoning. This sounds bureaucratic and it repays itself repeatedly, because three months later somebody will ask why something works the way it does, and without a log the answer is speculation.
Set a service level for yourself. Decisions raised get answered within a defined period, and where they cannot be, they get escalated rather than sitting. Decision latency is the single largest hidden cost in most implementations, and it is entirely within your control.
Distinguish reversible decisions from structural ones. Most are reversible and deserve a quick answer rather than a perfect one. A handful, particularly the chart of accounts and the dimensional structure, are genuinely expensive to change later and deserve real deliberation. Spending equal care on both is how projects stall.
Scope grows through accumulation rather than through any single dramatic request. Each addition is individually reasonable and none seems large enough to warrant reopening the plan.
The workable posture is not refusal, it is deferral. Maintain a phase two list, visible to everyone, and put things on it rather than arguing about them. Most requests are legitimate, they simply do not need to be in the first release, and a visible list makes deferral feel like scheduling rather than rejection.
Ask one question of every addition. Does this need to be true on day one for the business to operate? A surprising proportion of things do not, and the question is easier to ask than a judgement about value.
And when you do accept something, make the cost visible. Accepting scope without adjusting time or budget is how a plan quietly stops being real.
The relationship works best when it is direct rather than deferential.
Ask why. When a recommendation arrives, understanding the reasoning tells you whether it applies to your circumstances or is simply the usual answer. Good consultants welcome this, and the reaction to being asked is itself informative.
Escalate early and calmly. Problems raised at week four are solvable. The same problems raised at week sixteen are a crisis. Partners generally respond well to early escalation and badly to being surprised.
Insist on written decisions. Conversations get remembered differently. This is not distrust, it is how projects with hundreds of decisions avoid drifting apart.
And remember that a good partner disagreeing with you is doing their job. If they never push back on anything you ask for, that is a warning rather than good service.
The partner can move data. Only your business can decide what should move, and this is where client side project managers most often lose control of the timeline.
Start early, because the first trial load always reveals something and you want that in week six rather than week twenty.
Push for less rather than more. The instinct is to bring everything across in case it is needed. Open balances and a limited period of history covers the overwhelming majority of real needs, and the old system remains available for the rest.
Assign reconciliation to people who will actually check. Confirming that records arrived is not the same as confirming they are correct, and only your people can do the second.
User acceptance testing fails in a predictable way. People are asked to test, they are given no time, they click through a few screens, they report that it seems fine, and the real problems surface after go live.
Prevent it by being specific. Write scenarios rather than asking people to explore. Take a genuinely complicated real order, an awkward purchase, a full month end, and have someone run each end to end.
Book the time formally. Testing that has to fit around a full workload does not happen properly, and you are the only person positioned to argue for that time.
Log everything, including things that work but feel wrong, because those are often the early signal of an adoption problem. Then triage honestly into must fix and can wait, and hold the line on the second category.
The wider business will form its view of the project from whatever it hears, and if it hears nothing it will assume the worst.
Keep it short and regular. What happened, what is next, what we need from you. A brief update that arrives reliably is worth far more than a detailed one that arrives occasionally.
Be honest about problems. Projects that only report good news lose credibility the moment something visible goes wrong, and something always does.
And tell people what will change for them specifically, well before it does. Most resistance to a new system is not about the system, it is about being surprised by it.
Cutover needs a written plan with every task, its owner, its timing and its dependencies. Assume nothing will be improvised well at two in the morning.
Agree the go or no go criteria in advance, in writing, while everyone is calm. Deciding in the moment whether an unresolved issue is a blocker is a bad time to be forming that judgement.
Have a rollback position even though you will probably not use it. The value is in having thought it through.
And make sure the right people are genuinely available rather than nominally contactable. Cutover weekends run long.
Your job does not end at go live, and the weeks immediately after are when the outcome is actually determined.
Make support visible and fast. The gap between someone raising a problem and it being resolved determines whether they stay on the system or build a workaround, and workarounds invented now become permanent.
Go and look rather than waiting for reports. People do not report that they have stopped using something, because from their point of view they found a solution.
Expect the first close to be slow and something not to reconcile immediately. Get the differences explained rather than adjusted around.
At some point you return to your actual job, and what you leave behind determines whether the system keeps improving.
Make sure someone owns it. Not as a title, as a role with time attached. Our overview for system administrators covers what that actually requires.
Make sure the decision log, the configuration documentation and the phase two list all survive you and are somewhere findable.
And make sure the ongoing support arrangement is settled rather than assumed. Where the business will not carry that internally, managed services is the usual answer, and arranging it before you step back is considerably easier than after.
The project managers who do this well are rarely the most technical. They are the ones who kept decisions moving, refused to let discovery be superficial, protected testing time, and told the truth about problems early.
None of that requires deep NetSuite knowledge. It requires being willing to ask obvious questions in front of experts, which is harder than it sounds and worth more than it looks.
Our approach to NetSuite implementation sets out what we ask of client side project managers and what we take on ourselves. Where the timeline question is your immediate concern, our guide to the NetSuite implementation timeline covers what drives duration. And where a project is already underway and no longer going well, implementation rescue exists for that.
If you have been handed a project and would like to talk it through with someone who has seen a few, get in touch.
