An ERP replacement needs your best people, and your best people are the ones the business cannot spare. Second them or protect their time, but decide, because "do it alongside the day job" is how projects stall. Who belongs on the customer side of the team, how much time each role really takes and when, why contractors belong on your side of the table from partner selection onwards, and the gatekeeper role that stops you signing a solution design you have not understood.
Every ERP project has the same unresolved tension at its centre. The project needs the people who know the business best: the finance manager who knows every exception, the warehouse supervisor who knows which bins are really used, the sales administrator who knows the customers with special terms. And those are exactly the people the business cannot do without on a Tuesday afternoon. Business as usual comes first. It always will. If the project plan does not take that as a given and design around it, the project loses every argument with the day job, one afternoon at a time, until it is six months late and nobody can say why.
This post is about building a project team on the customer's side that can actually win those arguments: who is on it, how much of their time it takes and when, why you should second people where you can and protect them where you cannot, and the case for bringing experienced contractors on to your side of the table from the very start, before the partner is even chosen.
The partner brings a project manager, consultants and developers. That is half a team. The other half is yours, and its shape is the same on every successful project:
| Role | Who | What they own |
|---|---|---|
| Project sponsor | MD, FD or COO | The decision to do it, the budget, the scope calls, and saying in public, repeatedly, that the project matters more than this week's convenience. Chairs the steering group. |
| Your project manager | A senior person with authority, often a contractor (see below) | The plan from your side, the partner relationship, the resourcing of your own people, the risk register, the escalations. Not the partner's PM wearing a second hat. |
| Process owners | Heads of finance, operations, sales, warehouse, production | The decisions about how their area will work, the sign-off of its design, and the release of their people's time. They do not do the detail; they decide it. |
| Subject matter experts / super users | One or two per department, the people who actually do the work | Requirements, fit-gap, testing, training, first-line support after go-live. Covered in super users. |
| Data owner | Usually finance, with a counterpart in operations | What migrates, cleaning it, reconciling it. A named person, because nobody wants this job. |
| Technical architect | Yours, not the partner's; usually a contractor | The design integrity: integrations, extensions, data model, environments, security, what is standard and what is built. The gatekeeper for everything technical the partner proposes. |
| Functional consultant (finance) | Yours; usually a contractor | Translating what finance needs into what Business Central should do, challenging the partner's design, writing and running the finance test scripts, sitting with finance at the first month-end. |
| Functional consultant (operations) | Yours; a contractor who knows manufacturing or warehousing, if you have either | The same for the shop floor and the warehouse, where the partner's generalist will not know what they do not know. |
| IT / systems | Your IT lead or support provider | Identity, devices, printers, scanners, network, the Microsoft 365 side, the old system's decommissioning. |
Developers are optional on your side. The partner can build; what you need is someone who can judge what they built, which is the architect. Many businesses have no internal developer and lose nothing by it, provided the architect is strong and the code lives in your repository.
There are two honest ways to resource the process owners and SMEs, and one dishonest one.
Secondment. The person leaves their day job for the duration, is backfilled, and joins the project full time. This is what large programmes do and it is the cleanest: the project has the person, the department has a replacement, nobody is doing two jobs. The cost is the backfill and the disruption of moving a key person out of their role, and the risk is that the backfill becomes permanent and the seconded person has nothing to come back to. It suits the long, complex projects and the roles that are needed throughout (the finance SME on a multi-company manufacturing implementation).
Protected part-time. The person stays in their role and gives the project a defined share of their time, with the business explicitly accepting that their day-job output drops by that share. The share is the point: around 20 per cent on average, a day a week, written into their objectives and their manager's, with the manager's own objectives adjusted to match. It ramps:
The dishonest way is the common one: ask for the time, do not backfill, do not adjust anyone's targets, and let the project compete with the day job. The person is told the project is important and then measured on something else. They skip the workshop because of month-end, turn up to UAT having not seen the system, and sign off things they have not tested, because that is what the incentives told them to do. It is not a failure of the person. It is the business pretending it could have the project for free.
Which brings it back to the sponsor. Protecting people's time is a decision made at the top and enforced down the line: the sponsor to the process owners, the process owners to the department managers, the managers to the SMEs. If the sponsor will not say "Sarah is on the project one day a week and your targets reflect that", nobody below them can, and the project has already lost. Buy-in is not a kickoff speech. It is the sponsor's willingness to absorb the day-job cost, visibly, for a year.
Most businesses doing an ERP replacement have never done one, or did one fifteen years ago with different people. The partner has done fifty, and the partner is selling. That asymmetry is where projects go wrong, and the way to fix it is to have experienced people on your side of the table who have also done fifty, whose only interest is yours. That is what contractors are for, and the time to bring them in is earlier than almost anyone does.
A senior contractor (an architect or a very experienced functional lead) during selection. They write the requirements the partners are responding to, so the responses are comparable. They sit in the demos and ask the questions a first-time buyer does not know to ask. They read the proposals and tell you what is not in them. They do the due diligence. A few weeks of their time at this stage is the best money spent on the whole project, because it is the stage where the biggest decisions are made with the least information.
The same people stay for the workshops, so that the functional requirements document says what the business actually needs rather than what the partner's template suggests. Then the critical bit: that document becomes a technical design, and the technical design becomes a solution design document, and the solution design document is what you sign. It is, in effect, the specification in the contract. What it says will be built is what you will get; what it does not say, you will pay for later as a change. A lot of businesses are caught out here, because they sign a hundred-page document they have read but not understood, and discover in UAT that "integration with the web shop" meant something narrower than they assumed.
Somebody has to be the gatekeeper for that document: read every line, trace every requirement from the workshops into it, challenge every "out of scope" and every "standard functionality" claim, and refuse to let it be signed until it says what the business thinks it says. That person needs to know Business Central well enough to tell what the words mean, and to owe the partner nothing. It is the architect, or the senior functional contractor, and it is the single most valuable thing they do.
The architect reviews what is built against the design, owns the environments and integrations plan, and keeps the extensions in your repository. The functional contractors write and run test scripts with your SMEs, so that UAT is real, and are the ones who sit with finance at the first month-end and with the warehouse on the first Monday. They are the continuity on your side when the partner's people change (and they do).
Not developers, usually; the partner builds and the architect judges. Not a large team; three or four people, part time, for the duration, is typical for a mid-sized business. Their cost is real and it is a fraction of what a project that stalls, overruns or signs the wrong design costs, and unlike the partner's fee it buys people whose only client is you.
The sponsor announced at the start who was on the project and what it would cost each department, and nobody was surprised in UAT. The SMEs were in every workshop that mattered and tested from a sandbox they already knew. The solution design document was read, line by line, by someone who could tell what it meant, and the three things that were not in it were put in before signature instead of billed afterwards. The architect kept the integrations honest and the code in the right place. The finance contractor was in the room at the first month-end. And the partner, which did the building and did it well, found it the easiest project of its year, because the customer's side of the table knew what it wanted and had the time to say so.
That is the team. The expensive version is the one that does not plan for business as usual coming first, and finds out. If you are at the start of a project and the customer-side team is "the finance manager, when she can", talk to us before the partner is chosen; the selection phase is where we add most, and the architect and functional roles above are exactly what we provide.
