Thirty clients don't need thirty plans

If you've run a rollout across many client sites, you'll know how it tends to feel from the inside: thirty separate projects, each with its own plan, its own checklist, its own spreadsheet that someone is keeping up to date by hand.

It feels that way because each client really is different. Different people, different history, different ways of describing what they do. But the work itself is far less different than it feels. Rolling out to many client instances is one plan with variations, not many plans. The evidence for that is usually sitting in your own files.

Two checklists, thirty-nine lines

Here's a real example. Two client go-live checklists, prepared by the same implementation partner for two different sites.

They were identical for 37 rows. The same items, in the same order. And — this is the telling part — with the same typos. Both said "create purchase orders ferom Replenishments". Both said "Enter Creditor Invoices for Receipted Stck".

Nobody wrote those two checklists independently and happened to make the same spelling mistakes. One was copied from the other, or both from a common original. Which is exactly what you'd expect, because the work was the same.

One of the two added exactly two items specific to its site. That was the entire variation between those clients: two lines out of thirty-nine.

This isn't unusual. It's what most multi-site rollouts look like once you put the checklists side by side. The sense of thirty unique projects comes from thirty separate files, not thirty separate kinds of work.

Sites cluster by what they run

The variation that does exist isn't spread evenly across sites. It clusters.

Sites tend to differ by what they run rather than by who they are. A site using the warehouse module needs the warehouse steps. A site that doesn't, doesn't. Sites on the same version need the same upgrade path. Sites with a particular integration share the same extra testing. Once you group sites by the modules and configuration they actually use, most of them fall into a handful of patterns.

Within each pattern, the per-site tail is tiny. A local data quirk, a site-specific report, a contact who needs to be told about a cutover. Real, worth tracking, and small — a couple of lines, as in the example above, not a different plan.

So the honest shape of a thirty-site rollout is one master plan, a few variations by what sites run, and a short list of genuinely site-specific items. That's a very different thing to manage from thirty independent plans.

Fix it once, not thirty times

The practical cost of thirty separate plans shows up the moment something needs to change.

Take those typos. In a world of copied checklists, fixing "ferom" means finding every copy and correcting each one, and you'll miss some. The same goes for anything that matters more than spelling: a step that turns out to be in the wrong order, a check that should be added after a site goes badly, a responsibility that should move from one side to the other. Each improvement has to be applied thirty times by hand, and in practice it gets applied to the next few sites and forgotten for the rest.

With a shared master list, the fix happens once and every site gets it. Lessons from site four reach site twenty-nine without anyone remembering to copy them. The sites that went live early aren't stuck on an older, worse checklist just because of when they happened to start.

It's also kinder to the people on the client side. Each client's team is fitting go-live preparation in around their normal work — a second job done in the gaps of the first. A checklist that's been refined by every site before theirs is a smaller, clearer request than one copied from an early draft. They get the benefit of everyone else's experience without having to know it exists.

The same task is the same task

There's one thing that makes all of this harder than it sounds, and it's the reason most rollouts end up with thirty plans despite good intentions.

Different people word the same task differently. One partner writes "Enter Creditor Invoices for Receipted Stock". Another might write "Post supplier invoices against goods received". A third abbreviates it. Read literally, these are three tasks. Understood properly, they're one.

If your master list can't recognise that, it fills up with near-duplicates, each site's checklist drifts from the others, and within a few months you're back to thirty plans that happen to live in one place. The step that makes a shared list work isn't storing it centrally — it's matching incoming work to what's already there, so that the same task is treated as the same task whoever wrote it and however they spelled it.

That matching needs judgement, not just string comparison. Two lines that look alike can be genuinely different steps, and two that share hardly a word can be the same one. The workable approach is for the list to suggest the likely match and for a person who knows the work to confirm it. Most of the time the suggestion is right and confirming it takes a second. The occasional case where it's wrong is exactly the case worth a human look, because it's usually where a site really does do something differently.

The matching also has to cope with the people who aren't on your team. Each partner and each client brings their own vocabulary, built up over years of describing their own processes their own way. Asking them to rewrite their checklists in your wording is asking for one more job on top of the one they already have. Recognising their wording as the task you already know respects that, and it's the only approach that keeps working at site thirty.

Get that right and the arithmetic of a rollout changes. You stop maintaining thirty plans and start maintaining one, plus the two lines that are genuinely different about each site.

---

ProjectPlanOS builds each site's checklist from one master list. Imported checklists are matched against it, so the same task isn't filed under five different names, and site-specific items stay attached to the site they belong to.

If you're about to start a multi-site rollout, putting two of your existing checklists side by side is the place to start, with or without us.