The plan and the team: the real constraint

Ask any implementation manager why their last delay happened, and the answer will not be technical.

It will be: the finance key user could not find time to review the design. That is not an excuse; it is the structural constraint in this kind of project, and a plan not built on it is wrong from day one.

Why customer capacity is the constraint

On an implementation, the person who knows how the business works is the same person who runs the business.

The purchasing key user is the purchasing manager. There is no substitute: somebody who does not know the detail cannot decide the design, and somebody who does is busy doing it.

So your project runs on the surplus energy of people from whom nothing has been taken away. Plan without allowing for that and you build a schedule on time that does not exist.

The deceptive part is that the early months pass painlessly, because the load sits on your team. Then design starts, the load moves to the customer, and the schedule collapses at once — and the collapse looks sudden when it was not.

Plan in hours, not in names

“So-and-so is a key user” is not a plan. The plan is: “so-and-so, 12 hours a week, Tuesdays and Thursdays, from week 3 to week 20”.

Role	Realistic capacity	What happens without relief
Sponsor	Two hours a week	Decisions slip
Customer project manager	50% at minimum	Nobody owns the file — the worst of them
Key user	30% to 50% through design and testing	The design is approved unread
End user	Two days’ training + 5 days’ testing	Rejection after go-live

The second row makes or breaks the project. A customer-side project manager at a quarter of their time means your project has no owner on the side that is paying.

The relief question — asked once, clearly

Put one question to the sponsor at kickoff, and ask for the answer in writing.

“So-and-so needs 16 hours a week for twenty weeks. What will they stop doing, or who will cover for them?”

The question is deliberately blunt, because the polite answer — “they’ll manage” — means nothing will stop, which means the plan is fiction.

Three answers are acceptable: a temporary hire covering them, a named piece of other work deferred, or extending the schedule to match real capacity. The third is better than a schedule that breaks in month four.

Anybody who does not ask this at kickoff asks it in month four, when the answer is mutual blame.

The shape of the plan

Five milestones, not fifty.

Milestone	What it proves
1. Design approved	The customer has read and agreed how it will work
2. First reconciled data load	Data moves and can be verified
3. UAT complete	Users have tried it and accepted
4. Cutover rehearsal	The night has been run once before its night
5. Go-live	—

Between each pair, declared contingency rather than hidden. Contingency hidden inside task estimates is consumed without anybody noticing; declared contingency is a decision somebody takes.

Realistic contingency on an implementation: 15% to 20% — and most of it is consumed in the data phase, which is station six.

And the team on your side

This whole station is about customer capacity, and there is a second half that gets neglected: your own team.

Role	What they do	The common error
Project manager	Schedule, scope, communication	Also being a functional consultant
Functional consultant	Design, configuration, testing	One per two areas, not per five
Data consultant	Migration and reconciliation	Always engaged too late
Developer	Extensions and integrations	Called in before it is settled that one is needed

The first row is the commonest error at smaller firms: the same person runs the project and designs the finance module. The result is that management gets neglected whenever design comes under pressure — which it always does.

The third row deserves an early decision. A data consultant is usually engaged in month four, while their real work starts in month one, when files are inventoried and criteria set. Engage them late and you inherit a compressed data phase — the phase that consumes all the contingency, as in station six.

The critical path

Four items are on the critical path of almost every project.

1. The chart of accounts decision — it blocks everything in finance behind it.
2. Item data quality — it blocks inventory, purchasing and sales together.
3. The external integration decision — it blocks end-to-end testing.
4. Key user availability — it blocks everything.

The fourth appears on no task chart, because it is a resource rather than a task. So write it as an explicit line in the risk register with a weekly measure: how many hours did we actually get from each key user this week?

The gap between the chart and reality shows in week three, not in month four.

What you actually do in this station

• Write each person’s capacity in hours and days, not in names.
• Ask the relief question at kickoff and get a written answer for every key user.
• Build the plan on five milestones with declared contingency between them.
• Put the weekly hours measure into the status report from week one.
• Revisit ERP team roles for what each role is and what is expected of it.

The three commonest mistakes

One: planning in names rather than hours. The team looks complete and is unavailable.

Two: a customer project manager at a quarter of their time. Your project has no owner on the paying side.

Three: hidden contingency. It is consumed without a decision, and its absence is discovered in month six.

The acceptance test for this station

1. Show the capacity table in hours per role.
2. Show the sponsor’s written answer to the relief question.
3. Show the five milestones and the declared contingency between them.
4. Name the four critical path items and the status of each.
5. Show the hours measure for the last three weeks.

What comes next

You know who works and when. The next station is the first thing they do together: design and the fit-gap decision — how a design workshop is run, and when the right answer is to customise nothing.