The 5 warning signs a digital project is about to slip

A real case first: in one technical review the code was better than expected. The danger was that a single contractor held the only credentials to the production database and the deployment pipeline, and had not been paid in seven weeks. It was named, and fixed in four days. The signs below are how you see that kind of problem coming.

In short: projects don't derail suddenly — they drift, and the signs appear weeks before the delay becomes visible. The five signals below are, in my experience, the most reliable. None of them is technical: they are all symptoms of governance, which is exactly why they can be fixed without rebuilding anything.

1. Reporting turns qualitative

Early on you're told "the orders module is done, testing left". A few weeks later you're told "it's coming along well". The shift from factual to reassuring is the earliest signal and the most ignored.

Fix: ask for progress per deliverable, with a percentage and what remains. Same format, same cadence, every time.

2. Decisions take more than a week

The vendor asks a question and nobody rules on it. The project doesn't stop — it continues on an assumption. Those unvalidated assumptions accumulate, and they all surface together at acceptance.

Fix: one person accountable for business decisions, with a stated response time. The specific deadline matters less than the fact that one exists.

3. Scope grows while nothing else moves

Requests accumulate in meetings — "while we're at it, could it also…" — without the timeline or budget being revisited. This is the most common cause of overruns and the easiest to prevent.

Fix: every addition is costed in time and budget before it is accepted. Not a blanket refusal: an explicit decision.

4. Testing is done by whoever built it

When developers test their own work, they test what they anticipated, not what a user will actually do. Defects then surface in production, at the worst moment, with maximum internal visibility.

Fix: someone on the business side validates each release against the acceptance criteria written at the start. Half a day per release is usually enough.

5. Nobody knows what happens if the vendor stops

No code access, no documentation, one person who understands the configuration. The project may be progressing perfectly well — it has simply become fragile to a single event.

Fix: confirm in month one that you have the access and that documentation exists. Not at the moment you need it.

What these five have in common

None is a technical problem. They are all scoping and governance problems, which is good news: they can be corrected in a few weeks, without rewriting anything, provided you address them while they are still signals and not yet facts.

If several of these sound familiar, the most useful next step is an assessment before adding anything else to the project.

A weekly slip-signal checklist

Print this, answer it every Friday, and keep the history. Two or more "yes" answers in the same week is the point to act, not to wait.

• Did this week's report describe progress per deliverable with a percentage and what remains? (If it said "going well", answer yes to the warning.)
• Is any vendor question older than five working days without an answer?
• Was anything added to the scope without a stated impact on date and budget?
• Did anyone from your side run a release against the written acceptance criteria?
• Can you currently access the repository, hosting and database with your own credentials?

What a real slip looked like

On a $90,000 build, six sprints in, every status report was green. Graded against the written acceptance criteria, three of the six sprints turned out to be only partially delivered. The vendor had been demoing the happy path and deferring error handling, permissions and data migration to a phase that did not exist in the contract. Signs 1 and 4 above (reporting turning qualitative, testing done by whoever built it) were both present from the first month. Caught at sprint six, it was renegotiated at no cost. At acceptance it would have been a change request in the high five figures.

The case at the top of this article is sign 5 (nobody knows what happens if the vendor stops) in its purest form: the project itself was fine, and one unpaid contractor was the whole risk.

Why these signs are the same everywhere

I see the same shapes across very different projects: a platform that digitalised a health-insurance workflow with four connected interfaces, a multi-tenant federation platform with six modules, a CRM for field sales teams. The technology differs; the governance failures do not. This is the practical reason to look at process before code when a project feels off.

Where these signs come from in the standard frameworks

• Sign 1 (qualitative reporting) is what a "Definition of Done" exists to prevent. The Scrum Guide defines an increment as work that meets the Definition of Done, so progress is either done or not, never "going well".
• Factual reporting can be asked for in numbers. The research programme behind DORA measures delivery with four metrics: deployment frequency, lead time for changes, change failure rate and time to restore service. You do not need all four from a small vendor, but asking for any of them turns reassurance into data.
• Sign 4 (testing by whoever built it) is why acceptance criteria are written by the business side. ISO/IEC/IEEE 29148 asks that every requirement be verifiable, which is the same idea.

What to do this week if you recognise two or more

1. Write down the acceptance criteria for the next deliverable, in plain language, and send them to the vendor.
2. Name one person who rules on vendor questions within two working days.
3. Ask the vendor for repository and hosting access in your name, in writing.
4. Book a half-day on your side to test the next release yourself.

If you would rather have someone independent do it, Build Oversight grades every sprint against written criteria and gives you a monthly verdict you can forward to the vendor unedited. For a one-off view of where a running project stands, the Delivery Risk Audit returns a ranked risk matrix in ten working days. Before signing with a new vendor, use the vendor scorecard.