Everything that makes a project go well happens early

Anyone who has worked on implementations long enough has a few battle scars. The go-live weekend that ran on into Tuesday. The data load that finally balanced at four in the morning. Each one taught somebody something.

The most useful lessons, though, come from the projects nobody tells stories about. They went live on the date in the plan, the first month-end closed roughly when it should have, and everyone moved on to the next thing. Nobody writes a case study about a project that was simply fine, which is a shame, because that's where you can see most clearly what good looks like.

Having watched a fair number of both from the inside, we've come to think the successful ones share a handful of habits, and none of them is impressive. They're unglamorous, they're repeated every week, and most of them are settled in the first month. They can also be learned, which is the reason for writing them down. The lessons are worth passing on, so the next team can have the uneventful project without earning the scars first.

We work in ERP, so the examples here are ERP ones. The pattern isn't ERP-specific.

The plan describes how the work connects, not when you hope it happens

A list of tasks with dates beside them is a wish. It records when everyone hopes each thing will happen, and it's perfectly accurate right up until the first thing moves.

The plans behind the uneventful projects are built differently. Each piece of work is linked to the work it depends on: the trial migration waits for the chart of accounts to be mapped, user acceptance testing waits for the trial migration to be reconciled, training waits for a stable build.

The difference shows up the first time something slips, because the question everyone asks at that point is always the same: what does this do to everything else? A linked plan answers it in seconds. A list of dates sends someone off to a spreadsheet for an afternoon, and the answer they come back with is an opinion.

The test is simple. If a task moved a fortnight, would the plan tell you what else moved? If it would, you have a plan. If it wouldn't, you have a calendar.

Every piece of work has somebody's name on it — and for the contested ones, four names

Most plans have an owner column. On the projects that go well, it's always filled in, and with a person rather than a department.

For the contested work, one name isn't enough, and this is where RACI earns its place. Responsible: who does the work. Accountable: the one person who says it's finished. Consulted: who has to be asked before it's done. Informed: who needs to hear once it is.

It matters most where two parties both half-own something, which in an implementation is most of the interesting work. Take the decision about how intercompany transactions will post in the new system. The consultant knows the configuration options. The group accountant knows how the business actually trades. Each can reasonably assume the other is driving it, and without clear roles that decision can sit open for six weeks while both sides wait politely. Write down who is responsible and who is accountable, and it tends to get made in one.

There's a knack to running a RACI that people actually use, rather than one filled in at kickoff and never opened again. That deserves its own post, and it'll get one.

The client's share is sized honestly

A large part of any implementation is work only the client's team can do. Data cleansing. Process sign-offs. Writing and running test scripts. Attending training, then training their colleagues. All of it lands on people who already have full-time jobs, and who still have to close the month while the project is running.

The projects that go well plan that work with the same care the consultant's own work gets. They estimate it in real days. They put it on the calendar around month-end and year-end rather than through the middle of them. They ask the finance team how long closing the legacy periods genuinely takes, and they plan to that number.

This is a planning responsibility, and it sits with whoever builds the plan. A one-day placeholder against "close legacy periods and provide the trial balance" is a planning failure. The work was always going to take what it takes; the only question was whether the plan said so. When it does, the client's team can arrange cover, book the time, and do the work at the pace it deserves.

The risks are written down, and then actually looked at

Most projects keep a RAID log somewhere. Risks: what might go wrong. Assumptions: what we're treating as true without having checked. Issues: what needs dealing with now. Decisions: what's been agreed, by whom, and when.

The register isn't what makes the difference. The review is. A risk log nobody opens is a document. A risk log reviewed every fortnight, with someone asking what has changed against each line, is a project control.

Assumptions are the half everyone skips, and the half that usually turns out to be wrong. That the legacy system can export transaction history in a usable format. That the payroll provider's interface will be ready in time for testing. That the warehouse team can be released for training in the same week as stocktake. Writing them down means someone checks them while there's still time to act on the answer.

Running a RAID log that gets reviewed rather than filed is its own discipline, and we'll give it a post of its own.

Dates move, and everybody can see that they moved

Projects don't come to grief because dates slip. They come to grief because the slip isn't visible until it's too large to absorb. A week here, four days there, each one quietly made up, until the gap between plan and reality is three months and everyone discovers it at once.

The simplest protection is to keep the original plan alongside the current one. When anyone can see that the data migration was due on the 3rd and is now forecast for the 14th, the slip becomes information: something to plan around, talk about and decide on, rather than an argument about what was promised.

We've written before about why a green status report tells you nothing. The other side of that is worth saying plainly: an honest amber in week ten is worth more than a green report in week twenty, every time. Movement shown early is movement a project can absorb.

Boring is the goal

None of this is clever. There's no technique in it. The work is linked, the work has owners, the client's share is sized properly, the risks get reviewed, and the dates are honest about where they've been.

What sets the projects that go well apart is that they do these things consistently. The same five things, every week, by people who've decided that boring is the goal.

---

We built ProjectPlanOS around these habits, mostly because we kept doing them by hand. Its plans link work rather than list dates, it holds roles by phase and risks, assumptions, issues and decisions in one log, it keeps the client's work separate from ours, and it remembers the original dates when the current ones move. None of that makes the work clever. It just makes the boring version easier to keep up.