Managing an Outsourced Software Project: 8 Verifiable Checkpoints

Outsourced projects rarely collapse suddenly. They drift. The first three weeks look fine, week five brings "almost there," by week eight the login page still does not work end to end, and by week twelve the two sides are discussing whose fault it is. By then the contract cannot rescue the project — clauses are for disputes, not for progress.

Managing an outsourced software project depends on tracking progress precisely because software development is hard to observe from outside. You can watch a wall rise. With code, you only see that someone on screen looks busy. Ten years of project work at Juhui Software produced an observation method that works for clients too: not trust, not surveillance, but a handful of verifiable checkpoints.

1. Replace "40% done" with "what can I see this week"

Percentage complete is the least reliable unit in outsourcing communication. A vendor says 40% and you cannot verify it; press further and you hear "the framework is up, the rest will be fast" — when the business logic after the framework is exactly the expensive part.

The verifiable substitute is demo-driven: at a fixed time each week the vendor shares a screen, opens the running system, and walks through the features that were due that week. What can be seen is what exists. Thirty minutes a week turns "progress" from an adjective into an observable fact.

2. Four checkpoints that must exist

You do not need a daily stand-up, but four checkpoints cannot be skipped. Each maps to something deliverable and openable:

• Prototype sign-off: a clickable wireframe or design you can walk through yourself along the full business flow. Change is cheapest here — one screen equals hours, not days.
• First working loop: one complete business path runs end to end, however rough the interface and however narrow the path. This proves the technical approach and is the project's watershed.
• Test build: deployed to a test environment where you log in with your own account, create your own data and find your own issues. Defects are still cheap at this point.
• Acceptance build: the frozen version where fixes no longer introduce new problems.

Tying checkpoints to payments is the strongest management tool available. An unbound checkpoint is a suggestion; a bound one is a constraint.

3. Three questions for the weekly report, not "how is it going"

Ask "how is progress" and the answer is always "on track." Ask questions that can actually be answered:

• Which features can you demo this week? Require feature names, not module names.
• What is planned for next week? Check alignment with the milestone. Two consecutive vague weeks mean the schedule has stopped meaning anything.
• What is blocking you right now? The most valuable question of the three. The answer is usually "waiting for you to confirm a rule" or "waiting for a third-party API to be enabled" — things you can resolve today.

4. The client's own delays get charged to the vendor

There is a truth rarely put on the table: waiting on the client side often accounts for more than a third of actual delay. Typical patterns — prototype review sitting for two weeks, design selection through four rounds, promised assets and accounts never arriving, nobody organising acceptance during testing.

On any outsourced software project, a workable fix is a client action list: every decision or input needed from your side, with a deadline and a note on which feature it blocks. Circulate it weekly. Its purpose is not blame; it makes visible where the time actually goes.

5. Change is fine — as long as the cost is visible

Mid-project, the business side will always generate new ideas. That is normal. The problem is not change; it is change absorbed silently and then surfacing all at once as a delay.

Keep a simple change log: who raised it, what it was, estimated effort, which milestone it affects, whether the schedule moves. Even one row in a shared sheet is enough. When the total reaches a certain size, both sides can see "twelve person-days were added this month" and make a trade-off deliberately — drop something, or adjust launch scope.

6. When to intervene, and when not to

Not every variance deserves intervention. The test is the critical path: will this delay push the launch date? If yes, ask for a recovery plan immediately. If not, log it and watch for two weeks.

The other signal is the same thing failing twice. The first slip can be estimation error; the second means the method is wrong, and it is time to ask for a different lead or a revised approach rather than keep waiting.

7. The two weeks before acceptance are the most wasted

Many projects stall for three to four weeks between "features are done" and "actually live." The usual causes: nobody tests systematically, issues are scattered across chat threads, and each fix breaks something else.

Start defect management two weeks before acceptance. One table — a shared spreadsheet is enough — with description, reproduction steps, severity and status. Three severity levels suffice: blocking, major, minor. Require daily status updates from the vendor and appoint one person on your side to verify fixes. The organisation of those two weeks largely determines the launch date.

8. One sentence for the client

Managing an outsourced software project is not about monitoring people. It is about converting an invisible development process into visible evidence: a system you can open, a prototype you can click through, a defect you can reproduce, a change record you can reconcile. Do those four things and you can judge whether the project is on track without understanding the code.