Warning Signs Your Software Project Is Heading Off a Cliff

Warning Signs Your Software Project Is Heading Off a Cliff

You don't need to read a line of code to see a software project heading off a cliff. The signs show up in email threads, standup notes, and invoices, weeks before anyone says the word "failing." Seven signs below are what I check when I'm asked to review a project someone else started, roughly in the order I'd look for them.

Standish Group's CHAOS Report put a number on this back in 1994: only 16.2% of software projects landed on time, on budget, with the full feature set promised. The figures are decades old and genuinely contested. Standish never published its raw sampling data, and a later academic reanalysis called the success/failure categories one-sided.

But the underlying pattern hasn't gone away. PMI's 2018 Pulse of the Profession survey is more recent and better documented. Of over 4,000 project professionals surveyed, scope creep alone hit 52% of projects, and roughly half missed their delivery date.

None of that needs a technical audit to catch early. It needs knowing what to watch for.

1. No working demo after weeks

A project that's actually being built produces something you can click on almost immediately, even if it's ugly. If week three arrives and there's still nothing to look at — just descriptions of what's "in progress" — one of two things is true: nothing real has been built yet, or something has stalled and nobody wants to say so.

Guidance written for non-technical founders flags repeatedly postponed demos — "we're almost there," "the environment is down today," especially three times running — as the clearest sign the software doesn't functionally exist yet, or the team is hiding its actual state.

Cheap fix: put a working demo every one to two weeks into the contract from week one, however rough. A shaky demo you can click through beats a polished status email every time.

2. Vague progress reports stuck at round numbers

"90% done" for four weeks running isn't a status update. It's a number with no shared definition behind it. Guidance on spotting stalled outsourced projects names this pattern directly, along with technical jargon standing in for evidence, as one of the clearest signs a project has gone off track.

Percentages invite this kind of drift because nobody agreed, in writing, what "done" means for any given feature.

Cheap fix: replace percentage updates with a visible task board — even a shared spreadsheet works — showing exactly what shipped, what's in progress, and what hasn't started. A task is either demoable or it isn't. There's no honest 90%.

3. One person holds all the critical knowledge

Ask who else on the vendor's side can explain the architecture. A long pause is itself an answer. This is what software engineering calls "bus factor": the number of people who'd have to disappear before a project stalls. It works like a football team with one star player — the moment they're injured, the game stops.

A 2016 study of 133 popular GitHub projects found 65% had a bus factor of two or fewer, meaning the loss of just one or two people could stall the whole codebase. If that's true of well-maintained open-source projects with dozens of contributors, it's close to a certainty on a small vendor team where one developer wrote everything.

Cheap fix: require a README or handover document before you sign anything, and ask directly: "who besides this person can explain this code?" No good answer means no signature yet.

4. Scope keeps growing but nothing gets written down

A feature request in a chat message. A change agreed on a call. A "sure, we can add that" with no follow-up email. Each one feels small on its own.

Together they're how a fixed budget quietly becomes an open one — the mechanism behind the 52% scope-creep figure cited above. It's rarely one big change that derails a project. It's dozens of small, undocumented ones.

Cheap fix: require every scope change, however minor, to get a one-paragraph written addendum stating the added cost and time before work on it starts. A vendor who resists writing it down is telling you something.

5. Invoices arrive ahead of completed milestones

Once a vendor has been paid, their incentive to finish shifts, even with good intentions on both sides. Guidance on structuring milestone payments documents a case where a founder paid 50% of a contract upfront and discovered, by week six, that the build was 30% done with 70% of the budget already spent.

It's rarely fraud. It's just what happens when payment and progress stop being tied together.

Cheap fix: cap upfront payment at 20-30%, tie every payment after that to a demoed and accepted milestone, and hold the final 20-30% until sign-off on a working build.

6. You don't have access to your own repository or servers

If you can't log into your own GitHub organization, your own hosting account, or your own domain registrar, you don't own your project. You're renting access to it from the vendor.

Source-code escrow guidance notes what happens when that vendor becomes unreachable: the client faces costly downtime, no way to apply security fixes, and no path to continue independently.

Cheap fix: put every repo, domain, hosting, and DNS account under your own organization from day one. If a vendor insists on holding the keys, require source-code escrow in the contract instead.

7. Testing gets postponed to "the end"

"We'll add tests later" sounds efficient. It's the opposite. A NIST-commissioned study estimated the annual US cost of inadequate software testing infrastructure at $22.2 to $59.5 billion. Over half of it is borne by users dealing with defects that shipped, the rest by developers running extra tests after the fact.

Defects caught during development are cheap to fix. The same defects caught after launch, by your customers, are not.

Cheap fix: make QA a parallel deliverable from week one, not a final phase, written into the contract with the same weight as the features themselves.

When to actually pause

Any single flag on this list is a reason to ask a pointed question, not necessarily to panic. A first-time vendor might genuinely be slow to set up a demo environment.

But these flags compound. A team hiding behind vague 90% updates is far more likely to also be sitting on undocumented scope changes — both trace back to the same root cause: no shared record of what was promised and what's been delivered.

The same discipline that keeps a hotel management system project on track under a dozen competing stakeholder demands — written scope, a visible task board, a regular demo — is what catches drift on any software project before it gets expensive.

Two or more flags together is the signal to stop. Bring in someone with no stake in the outcome to look at the actual state of the build, and decide whether to fix the engagement or end it, before the budget that's left disappears too.