Assess a troubled software project before promising a rescue

OutsourcingVN is operated by Netbase JSC, which may sell the assessment work discussed here. Apply the same questions to any provider. A supplier cannot responsibly promise a date, outcome or recovery plan before it has read the system, its dependencies and the evidence of the problem.

Start by stabilising the decision

• What an assessment should answer
• Choose the next route deliberately
• Run the first review in sequence
• Keep transition separate from repair
• A published record and its limits
• Make findings usable after the assessment
• Decide what not to do yet
• Common questions
• Return the assessment to a delivery decision
• Start with the facts you can share

What an assessment should answer

An assessment is not a forensic conclusion, legal opinion or security guarantee. Where those are needed, involve the specialists and advisers appropriate to your organisation. The practical output here is a decision record: known facts, open risks, the first bounded action and the evidence needed to accept it.

Choose the next route deliberately

Recovery is one possible route. If the existing code and data can be inspected, a bounded repair may be safer than a rewrite. If ownership or access cannot be established, the first work may be transition rather than engineering. If requirements are still changing, the right output may be a revised brief and a new milestone plan. If the system does not support the intended business decision, stopping can be more responsible than layering another feature over it.

The project delivery guide explains how a scoped milestone should name inputs, deliverables and acceptance. Use the software project brief template to capture the revised outcome once the assessment has made the constraints visible.

Keep transition separate from repair

Changing a supplier is a governance and access exercise as well as a code exercise. Ask for repository ownership, deployment instructions, environment variables, architecture notes, known defects, backlog status and contacts. The handover and exit guide gives a practical transfer checklist. Do not treat a folder of source code as a usable handover when the accounts, data paths and operating knowledge remain elsewhere.

The next team should be able to describe what it has verified and what it has not. A confident plan based only on a sales call creates a second rescue risk. Make the first scope small enough to inspect the facts and stop if the evidence does not support continuing.

A published record and its limits

The Magento recovery and hardening record describes a three-phase scope for one compromised store: investigate and assess, clean and restore, then repair and harden. It is related to the Technical Audit Sprint. It publishes no outcome, security guarantee, general rescue result or assurance that another system has the same route to recovery.

That limitation is useful. It shows why an assessment comes before a promise: even a focused recovery record keeps its result and duration limits visible. The methodology page explains how published claims are bounded by their source.

Make findings usable after the assessment

The assessment should leave the buyer with material that survives a change of people: an access inventory, observed baseline, dependency map, risk list, list of unknowns, proposed first scope and the acceptance evidence for that scope. Keep the evidence with the buyer rather than only in a supplier workspace. That makes a pause, a transition or an internal decision possible without repeating the entire investigation.

Ask the assessor to distinguish facts observed in the system from statements supplied by a previous team, and to identify the date and source of each. A current incident note is not proof that a historical explanation is correct. A test that passes today is not proof that an unobserved user path works. These distinctions feel slow in an urgent project, but they prevent a repair from being accepted on confidence alone.

Decide what not to do yet

Avoid broad upgrades, architecture replacement, database moves and feature additions until the first bounded risk is understood. Each can be appropriate later, but combining them with a recovery assessment makes it hard to identify what changed and why. If the first review finds that access, ownership or business direction is missing, document that as the result. The honest next action may be a transfer request or management decision, not more engineering.

Keep a short decision log throughout the assessment. Record the observation, its source, the responsible owner, the action taken and the reason a risk was accepted, deferred or escalated. It protects the next team from repeating a discussion without its evidence, and it makes the first bounded scope reviewable by the buyer rather than dependent on memory.

Return the assessment to a delivery decision

Use project delivery to turn accepted findings into milestones, the project brief to restate the outcome, and IP ownership to identify dependencies before a handover. A subsequent Custom Product Engineering scope requires its own acceptance decision; buying an assessment does not authorize a rebuild.

Start with the facts you can share

Submit a project with the system, the immediate risk, who controls access and what decision is blocked. OutsourcingVN is Netbase's own outsourcing-services platform, and the first response should identify whether a bounded assessment is the honest next step.

Related services and solutions