Every implementation slips in the same three places

If you keep a slip log for a year, the causes stop being varied. Nearly everything falls into three buckets, and all three are visible from day one if you look.

One: the data is not ready

You asked for the customer's data in the agreed format. What arrived was an export with three different date formats, a column of free text where the reference numbers should be, and 1,200 rows that duplicate each other in ways that require a human to adjudicate.

This is not a customer failing. Their data was fine for the system it lived in. It became messy the moment it had to mean something in yours.

The front-load: ask for a sample in week one, not the full extract in week five. A hundred rows will tell you everything the full file will, six weeks earlier. Write the cleaning rules against the sample while the rest of the project proceeds.

Two: nobody can get in

Environments, VPN, SSO configuration, firewall rules, a service account that needs an approval from a team that does not know the project exists.

Access is almost never hard. It is just slow, and it is slow in a way that is invisible until someone actually tries — usually on the morning they planned to start building.

The front-load: make a working login the first milestone, before design, before configuration, before anything. Not "access requested". A person on your team logging in successfully. It sounds trivial. It routinely saves two weeks, because the approval chain starts running in week one instead of week four.

Three: a decision nobody knew was needed

The most expensive of the three, because it has no owner until it blocks something.

Which of your two org structures should the system reflect? Who approves refunds over a certain value? Do the regional teams see each other's customers? These are business decisions, not technical ones. Nobody on the project can answer them. They surface mid-build, go to a steering committee that meets fortnightly, and cost eleven days each.

The front-load: publish the decision list at kick-off with dates, and treat each decision as a deliverable owned by a named person on the customer's side. Not "we will need to discuss X" — "X must be decided by the 14th, owner: Priya". Decisions behave like tasks when you treat them like tasks, and like weather when you do not.

Why these three stay invisible

None of them are on the plan.

Plans contain the work you will do. Data quality, access approvals and pending decisions are all things you are *waiting* on — dependencies that sit outside the team, usually outside the organisation, and therefore outside the tool.

So the plan shows a project proceeding normally right up until the moment it stops, because the thing that stopped it was never represented.

That is a modelling failure, not a discipline failure. If a project can be blocked by something, that something needs to exist in the system as a first-class item with an owner and a date — whether it is a task, a decision, a data file or an access request.

What good looks like

A project view where a customer-side dependency that is three days overdue is as visible as a late task, and the status reflects it. A decision register that is part of the plan rather than a separate document. A defect or ticket that can block a milestone and does so explicitly.

PlaNath holds the project, the workplan, the defects, the escalations and the customer record in one system for exactly this reason. Most of what delays an implementation is not work. It is waiting — and waiting only becomes manageable when it is visible.