Continuity is king: why you want the same consultants from the first workshop to the last support call

Ask a finance manager what went wrong on their last ERP project and, surprisingly often, the answer is not the software, the data or the partner's competence. It is: "we had three different consultants and we explained our business to each of them." Every swap reset the project. Nobody planned it; it just happened, and by the end the business was more tired of the project than of the old system.

Continuity is king. This post is about why, what it costs when you do not have it, how to make it a condition of the contract, and the related question of who on the project should be talking to whom, because the two are connected.

Why continuity matters so much

A consultant on a Business Central project is not just applying product knowledge. Over the first few weeks they accumulate three things that are not written down anywhere:

• Business knowledge. Why your returns process has the exception for one customer. Which "item" is really three items. Why the warehouse ignores the system's bin suggestion on Fridays. This is learned in workshops and corridors and it is the raw material of a good design.
• Decisions and their reasons. Hundreds of them, most never minuted: why you chose average cost over FIFO, why that field is on the order and not the line, why phase two has the EDI in it. A new consultant does not know the decisions were made, so they get made again, sometimes differently.
• Rapport. The super users trust the person who sat with them in the design workshops. They will tell that person that the process does not actually work the way the manager described it. They will not tell a stranger in week twelve.

Swap the consultant and all three are lost. The replacement is competent, reads the documents, and then asks the finance team the same questions they answered in March. The users feel unheard, the design drifts, the timeline slips by the weeks it takes the new person to catch up, and nobody can point to the single thing that went wrong.

Why partners swap people

Rarely for a good reason, and it is hard to list every reason, but the usual ones are: the consultant was double-booked and another project's go-live won; a bigger customer needed them; they left the partner; the partner's resourcing model assigns people by phase (a "design consultant" then a "build consultant" then a "deployment consultant"); the sales team promised a senior person who then moved to the next sale; or sickness, holiday and life, which are legitimate and should be planned for rather than improvised around.

The structural one is worth naming: a partner whose utilisation targets are set per consultant per week will always be tempted to move people to wherever the billable hours are this week. That is not malice; it is how the business is measured. It is also exactly why you make continuity a contractual term rather than a hope.

Writing continuity into the contract

Ask for these, in the statement of work, before you sign:

1. Named individuals for project manager, lead functional consultant and lead developer, with CVs, and a statement that these are the people who will do the work.
2. No substitution without your written agreement, except for departure from the partner or long-term absence, and then with a replacement you approve.
3. A minimum weekly commitment for each named person during each phase, so "they are still on the project" cannot mean two hours a fortnight.
4. A handover standard for the cases where a change is unavoidable: a written handover document, two weeks of overlap at the partner's cost, and the outgoing person's attendance at the handover meeting with your team.
5. Continuity into support. The people who built the system are available to support it for at least the first year. The worst swap is the one at go-live, when the project team leaves and "support" is a different department that has never seen your configuration.
6. A price for breach. A credit or a rate reduction if named people are removed without agreement. Partners who are confident in their resourcing will accept it; the ones who will not are telling you something.

And ask the reference customers one question: "Did you have the same people throughout?" The partner due diligence post has the rest of that conversation.

Who talks to whom

Continuity is easier to keep when the project has a clear communication structure, because then each relationship has one owner and a swap is visible. The structure that works, and that Sure Step and most mature partners use:

Two rules in that table matter more than the rest.

The business does not generally talk to the developers directly. Not because developers are precious, but because a developer who takes a requirement straight from a user builds what that user said, which is often not what the business needs and is never what was specified. The functional consultant's job is to hold the whole design in their head and make every change fit it. Every request routed around them is a change nobody has checked against the design, and it is how a system ends up with three ways of doing the same thing. Developers hearing requirements first-hand is valuable, which is why they sit in on the relevant design workshops; but the specification comes from the consultant.

The project manager does not go to the developers either. A project manager asking a developer "can you just" turns a plan into a queue of favours, bypasses the specification, and leaves the functional consultant discovering in testing that something was built they did not know about. The PM manages the plan and the people; the consultant manages the solution; the developer builds what the consultant specifies. When the PM wants something built, it goes through the consultant and lands on the plan with an estimate.

The structure is not bureaucracy. A good project has the consultant and developer talking all day, and the developer in the room when a tricky process is being designed. It is about who owns each relationship, so that when a person changes, the handover has a shape, and so that the design has one keeper.

On your side of the table

Continuity cuts both ways. If your project lead changes halfway, or your super users are rotated, the partner has the same problem in reverse. Name your people, protect their time (see super users), and keep the same sponsor from kick-off to hypercare. A project with the same people on both sides for its whole life is a project where the knowledge compounds instead of leaking.

What good looks like

The consultant who ran the first workshop in March is the one who sits with the finance team at the first month-end in November and picks up the phone in the support contract the year after. The developer who built the courier integration is the one who fixes it when the courier changes their API. Nobody in the business has had to explain the returns process twice. That is the project everyone remembers as the one that went well, and the only thing it needed was the partner keeping the people on it.

It is how we work, mostly because we are small enough that there is nobody to swap in, and it is in our terms. If you are about to sign a statement of work and continuity is not in it, ask us what to add.

More from the blog

• The right project team: business as usual comes first, and that is the problem Projects
• Field types, field lengths and overflow errors: getting the data model right the first time Development
• Coding patterns in AL: why use fifty lines when three will do Development