Software Projects With an Outside Team: A Playbook for SMEs

Software Projects With an Outside Team: A Playbook for SMEs

Most owners run their first outside software project like a home renovation: agree a price, agree a date, wait for the result. Software doesn't work that way. Requirements shift once people see the thing running. A fixed date says nothing about whether what ships is what you needed.

What follows keeps a non-technical owner in control anyway. Not by reading code, but by controlling what gets measured and when money moves.

"On time, on budget" is the wrong headline metric

The stat everyone quotes is from the 1994 Standish Group CHAOS report: only 16.2% of projects hit time, budget, and scope. 52.7% were "challenged" and ran 189% over their cost estimate on average. 31.1% were cancelled outright.

That number got repeated for three decades with little scrutiny of how it was produced, until a peer-reviewed replication supplied that scrutiny. Eveleens and Verhoef applied Standish's own definitions to 5,457 real forecasts across 1,211 projects. They found the definitions "misleading, one-sided, pervert the estimation practice, and result in meaningless figures": an accurately forecasting organization scored only 35–59% "success" by Standish's method, while one that padded its budgets scored 67%. Pressed on this, Standish's chairman said the reports "should be considered Standish opinion and the reader bears all risk in the use of this opinion" — a line absent from the reports themselves.

That skepticism matters more once you look at the risk that's actually well documented. Flyvbjerg and Budzier's analysis of 1,471 IT projects found an average cost overrun of 27%. But one in six was a "Black Swan", running 200% over cost and nearly 70% over schedule. That's a fat-tailed, power-law pattern a follow-up study of 5,392 projects confirmed.

Most projects finish close to plan. A minority blow up completely. Good structure catches that minority early, not the average.

Write scope as outcomes, not features

"User authentication" is a feature. "A returning customer can log in with their phone number and receive an OTP within 10 seconds on a 3G connection" is an outcome — something you can watch happen and know is true.

A feature list reads differently to different people. An outcome statement resolves on its own, and Standish's own data on why projects fail backs this up. Incomplete and changing requirements top the failure list. A clear statement of requirements (13.0% of cited success factors) and user involvement (15.9%) top the success list.

A checklist can be "complete" and still be wrong. Writing the outcome forces that gap open before a line of code gets written.

Pay on milestones tied to acceptance criteria

Once scope is written as outcomes, payment follows naturally. Each milestone is a deliverable, its acceptance criteria, and a deadline. The invoice fires when the criteria are verified, not when a date arrives.

"Smaller project milestones" was Standish's sixth most-cited success factor, so chunking the work is right — the mistake is sizing chunks wrong. A milestone every three days becomes status theater. One at three months hides problems until they're expensive. Two to four weeks is the right grain for an SME engagement, with a fixed three-to-five-day review window to test acceptance criteria before payment is due.

Replace the status report with a weekly demo

A status report is a claim. A demo is evidence. The official Scrum Guide frames the Sprint Review as "a working session," explicitly not a scripted presentation. The UK government's own delivery standard calls the same practice a "show and tell": the team shows what's done, talks through what it learned, and takes questions.

A non-technical owner doesn't need a paragraph claiming 80% progress when they can watch the login flow work, or not, in four minutes. Put it on the calendar weekly at a fixed time, and treat a cancelled demo as a signal worth asking about.

One change-request rule, nothing more

Scope creep isn't rare. PMI's global survey of thousands of practitioners found 52% of projects experience it on average. That's against a backdrop where 43% overrun budget and 48% overrun schedule.

None of that needs a change-control board, just one rule, applied without exception. Any addition to scope gets its own estimate and acceptance criteria, none of it riding free inside the milestone already underway. It can live in a paragraph of a shared doc, but it has to exist before work starts. Otherwise "just one more field" quietly becomes the reason the whole project misses its date.

Settle ownership before day one

Two questions decide whether you actually own what you paid for.

Who owns the code: a bare "work made for hire" clause is often not enough. Under US copyright law, contractor work counts as work-for-hire only if it fits one of nine narrow statutory categories most custom software misses. Contracts need present-tense language: "agrees to assign, and hereby does assign...", since courts read a promise to assign later as granting no ownership now.

And who holds the accounts: register your own domain, hosting, and analytics from day one, with the vendor added as a collaborator, not the owner. Owning your code doesn't erase your dependencies' own obligations — a separate check covered in what open-source licenses actually require in commercial software.

The documents that actually matter

Four documents line up with what Standish's own data ties to success: user involvement, executive support, a clear statement of requirements. None of it needs a PMBOK binder:

1. A one-page scope-as-outcomes document.
2. A milestone and payment schedule, each milestone with its acceptance criteria attached.
3. A one-line change-request log: date, request, new estimate, decision.
4. An IP and ownership clause with present-tense assignment language.

That's the whole stack. Risk registers, RACI charts, weekly steering committees — a project this size rarely needs any of it. That's true even on a hotel management system built milestone by milestone.

What this buys you

None of this requires reading a line of code. It requires watching a demo every week, checking acceptance criteria against what's on screen, and refusing anything into a milestone that wasn't estimated first. Control built on evidence, not trust in a vendor's word. That's the difference between catching a project going off track in week three and finding out at the final invoice.