The situation, and the trap in it
The project was meant to be finished by now. Perhaps the development company keeps reporting that it is nearly done. Perhaps the developer has stopped answering. Perhaps the budget is spent and the system is half usable. You have something, you are unsure what, and every option looks expensive.
The trap is to decide by feeling. Loyalty to the original plan and to the money already paid pushes toward continuing unchanged. Frustration pushes toward starting again from nothing. Both can be wrong. An assessment replaces the feeling with facts, and it can usually be completed in a short, fixed period.
First, secure what exists
Before raising concerns with the current team, make sure you hold what you have paid for. Relations can deteriorate quickly once a project is questioned.
- 01
Obtain the complete source code
With its full history, in a repository your organization controls. Check the date of the latest change.
- 02
Take control of accounts
Hosting, domains, app store listings, third-party services. Your organization should be the account holder, with your own administrators.
- 03
Back up the data
Any live or test database, uploaded files and configuration, copied to a place you control.
- 04
Collect the documents
Contract, scope, change requests, designs, invoices, status reports and key correspondence.
- 05
Check the agreement
Ownership and licensing terms are defined in the project agreement, so read what it says about the work delivered so far and about ending the engagement.
Our software project handover checklist lists everything to ask for in more detail.
Establish what really works
Take the original scope and walk through it feature by feature on a running copy of the system, with a person who will use it. Put every item into one of four groups. This is slow, and it is the most valuable day of the assessment.
| Status | Meaning | Worth |
|---|---|---|
| Works | Does what the scope says, with real data, including the awkward cases | Full value, if the code beneath is sound |
| Works in a demonstration | Succeeds on the expected path and fails otherwise | Partial. The remaining work is often larger than what was done |
| Started | Screens or code exist but the feature cannot be used | Little, until proven otherwise |
| Not started | Nothing exists | None |
Be sceptical of a reported percentage. A project described as ninety percent complete for months is telling you that the remaining tenth contains the hard parts: integrations, permissions, error handling, data migration and performance.
Have the code reviewed independently
Working features can sit on code that nobody can safely extend. An independent developer, with no interest in the outcome, should answer a short list of questions in writing.
- 01
Can it be built and run from the repository alone?
Why it mattersIf a new team cannot start the system from what you hold, something essential is missing.
- 02
Is the structure consistent and understandable?
Why it mattersA new developer must be able to find their way. Chaos multiplies the cost of every later change.
- 03
Are there automated tests?
Why it mattersWithout them, each fix risks breaking something else, and nobody will know.
- 04
How current are the technologies?
Why it mattersOutdated or unsupported components mean upgrade work before new work.
- 05
Are there security problems?
Why it mattersSecrets in the code, missing access checks and unprotected data are common in rushed projects.
- 06
How much is original, and how much is a template or copied?
Why it mattersIt affects both quality and what you are entitled to use.
A technical code audit delivers these answers with an estimate of what it would take to bring the code to a maintainable state.
Find out why it stalled
The cause matters because some causes follow the project to any new team. Read the correspondence, compare the original scope with the change requests, and talk to the people involved on both sides.
| Cause | Signs | Follows the project? |
|---|---|---|
| Scope never settled | Requirements changed monthly, no signed baseline | Yes, until you fix it |
| Decisions too slow | Questions unanswered for weeks, no single decision maker | Yes |
| Team lacked the skill | Simple things took long, quality poor throughout | No |
| Team was reassigned or shrank | Fast start, then long silences | No |
| Wrong technology or approach | Constant workarounds, performance problems | No, but it may limit what can be salvaged |
| Underpriced | A fixed price far below other quotes, corners cut | Partly. The true cost was always higher |
Be honest about the first two rows. If the scope was never stable, a new team will stall in the same place unless that changes first.
A worked example
A booking platform, a year late
This example is invented to show how the facts change the decision. A training company commissioned a course booking platform that is a year overdue and reported as nearly finished.
- AssetsThe code turns out to be in the developer's private repository, and hosting is in his name. Both are transferred before any other step.
- What worksOf 46 scoped features, 19 work, 11 work only in a demonstration, 9 are started and 7 are not started. Payments and invoicing are among those not started.
- CodeAn independent review finds a reasonable structure and current technology, no tests and two serious access control gaps. The reviewer estimates the code is worth keeping.
- CauseA single developer took on the work alone at a fixed price that was half the next quote. The scope was stable. The cause does not follow the project.
- DecisionThe company appoints a new team to continue on the existing code: fix security first, add tests around the working features, then build payments. The estimate to finish is about the same as the original fixed price.
The honest cost of the platform was always roughly double the first quote. Knowing that, the company can compare finishing with stopping on real figures, and chooses to finish.
Compare the real options
Continuing makes sense when
- A good share of features truly work
- The code can be built, read and extended
- The cause of the delay can be removed
- The business need is unchanged
- Cost to finish from here is less than cost to rebuild
Rebuilding or stopping makes sense when
- Most features work only in a demonstration
- The code cannot be built or is unsafe to change
- The technology is unsupported or unsuitable
- The business need has moved on
- A packaged product now covers the need
Whichever route you take, compare only future costs and future benefits. What has been spent is gone in every scenario. If you continue, do so under new terms: a settled scope, short cycles with working software at the end of each, and payment tied to what you can test.
Assessment checklist
Unfinished project assessment checklist
0 of 10 checkedWhat to do next
Today, confirm where the code is and whose name is on the hosting account. Tomorrow, book half a day with someone who will use the system and walk through the scope together. Those two steps cost almost nothing and remove most of the uncertainty.
Our software project rescue page describes how we assess and take over stalled projects. Tell us where yours stands and we will say what we would look at first.
Common questions
Should we start again from scratch?
Only if the assessment says so. Starting again feels clean, but it discards whatever does work and repeats the risk. If the code can be built, understood and extended, continuing is usually cheaper. If it cannot, or the technology is unsuitable, a rebuild that reuses the designs, the lessons and perhaps some components is the sounder route.
Can a new team take over someone else's code?
Yes, provided the code is complete, builds from the repository and is reasonably structured. A competent team will ask for time to review it before committing to an estimate, and will usually begin by adding tests around what works. Be cautious of anyone who promises to finish quickly without having read the code.
How long does an assessment take?
For most business systems, a short fixed period is enough for the feature walk-through and an independent code review, provided access is available. The collection of documents and accounts can begin immediately and often takes the longest, because it depends on the cooperation of the current team.
What if the developer refuses to hand over the code?
Refer to your agreement and put the request in writing. Many disputes are about unpaid invoices on one side and undelivered work on the other, and can be settled by agreeing what is exchanged for what. If that fails, take legal advice promptly. Keep communication factual, since you may still need the developer's cooperation for a clean handover.
How do we avoid this happening again?
Hold the repository and accounts from the first day. Work in short cycles that each end with software you can test. Tie payments to what you have received and verified. Settle scope before development and control changes in writing. And compare quotes critically: a price far below the others is a forecast of trouble, not a saving.