Contents
When a software project has stalled, the next team needs a reliable picture of what exists before it can promise a recovery. Start with the business outcome, the working product and the access needed to inspect it. A fresh schedule based only on the previous task list can repeat the uncertainty that caused the original difficulty.
Separate immediate service needs from project recovery
Establish whether users currently depend on the application and whether an urgent operational problem is present. Identify the person responsible for the live service, the current support arrangement and any changes already scheduled. Agree who may authorise production actions during the assessment.
Keep immediate containment work distinct from decisions about the product's future. A necessary service repair does not establish that the whole system is ready for continued development. Record what was changed and what remains unknown so the recovery team can work from a consistent starting point.
Build an inventory of the material and access available
Locate the source repositories, build instructions, environments, deployment configuration and existing documentation. Identify account owners and arrange authorised access for the receiving team. Keep credentials in the approved access-management process rather than sharing them in ordinary project documents.
Gather the brief, acceptance criteria, design decisions and known issues. Treat these as evidence of intent, not proof that the corresponding work is complete. Ask the outgoing team to explain the deployed version, unfinished work and areas where the documentation is incomplete. Have the relevant commercial owners resolve rights and contractual questions separately from technical access.
Demonstrate what works and what does not
Choose representative journeys from the business requirements and exercise them in an appropriate non-production environment. Include permissions, error states and administrative tasks. Record the expected result, actual behaviour and evidence for each journey. Distinguish a missing capability from a defect in something that is already implemented.
Establish whether the team can reproduce a build and run meaningful checks. Review failing checks rather than assuming they are irrelevant because the application appears to start. Identify integrations that were replaced with demonstrations or test doubles and determine what is still needed to connect to the real service safely.
Ask operational users to review the findings. A technically working screen may not support the required process, while a feature described as unfinished may already be usable within a narrower scope. Reconcile those differences before estimating the remaining work.
Define a recovery outcome with explicit exclusions
Choose the smallest useful outcome that addresses the current business need. List the defects, missing work and operational preparation required for it. Keep later enhancements separate. If an architectural concern threatens that scope, explain the evidence and the investigation needed before committing to a remedy.
Compare stabilising the existing implementation with replacing a bounded part of it. Include the cost of preserving data, integrations and service continuity. Avoid treating the effort already spent as proof that the current design must be retained, or frustration with the previous project as proof that everything must be rebuilt.
Reset decisions, reporting and acceptance
Name the person who owns priorities and the people who can accept the recovered journeys. Agree how changes enter the scope, how risks are escalated and what the team will demonstrate at each review. A recovery plan needs timely decisions from the commissioning organisation as well as engineering work.
Use a short first phase when important uncertainties remain. Give it defined outputs, such as a verified baseline and a tested integration path, followed by a decision on the next commitment. Update estimates from the evidence gathered rather than presenting the first assessment as a guaranteed completion date.
Make the recovered product supportable
Include release, monitoring, support and handover in the recovery scope. Confirm who will operate the software after the rescue team leaves and what information that team needs. Demonstrate the relevant deployment and recovery procedures in an appropriate environment.
At the end of each phase, record the accepted result and remaining limitations. Keep unfinished scope visible without presenting it as delivered. A successful recovery creates a product and an operating arrangement the organisation understands, with a credible basis for the next decision.
A recovery assessment for a project that has stopped working
Consider a fictional portal whose latest release cannot accept requests and whose original supplier is unavailable. First stabilise the operating situation: name an incident owner, preserve the existing release and logs through authorised access, identify unresolved requests and agree a controlled manual route. Avoid starting with a rewrite while the business cannot tell which work was accepted.
The assessment produces four records: what can be reproduced; what is demonstrably failing; which code, accounts and data can lawfully be accessed; and what remains unknown. Test one essential request in a safe environment, including permission denial and a lost response. Mark an inaccessible production account as an access dependency, not proof that the application is beyond repair.
Give the sponsor options with acceptance evidence: restore an earlier compatible version, correct the failing boundary, narrow the operating scope or commission a replacement assessment. Each needs a record-reconciliation plan and a responsible support owner. This is failed-project recovery: continuity and diagnosis come first. The separate supplier-transition checklist covers a planned transfer where a working service and cooperating owners can be inspected before the change.
How this relates to Veda Software’s work
Encounter provides an adjacent example of customer and operational workflows needing to work together. Its case study is not a failed-project rescue claim or evidence of emergency recovery times.