Inventory the assets, reconstruct the intended journeys, and compare them with demonstrated behaviour before pricing completion. Do not begin with screen counts or an inherited completion percentage. An interface can look finished while the operational process stops at a staff approval. Conversely, useful functionality may exist without anyone having tested or documented it properly.
This is different from specifying a new application. You are recovering decisions from multiple versions, people, documents and code. The useful output is an agreed baseline: what the product needs to do, what has been demonstrated, what remains untested, and what must be decided before a completion estimate is meaningful.
Establish access before making judgments
Ask the project owner for an asset inventory covering the repository, deployed version, test environment, suitable test data, designs, decision records and third-party documentation. Identify the owner and available permission for each asset. Having the public application URL does not establish control of the source code, deployment account or external integrations.
A qualified, authorized technical reviewer must assess technical reuse. If repository access is unavailable, the team can describe visible behaviour but cannot confidently judge maintainability. If production is the only available environment, do not change customer bookings or other live records simply to demonstrate a feature. Agree a safe test approach first.
Before commissioning Product Discovery & Requirements, appoint an operational decision owner. An analyst cannot infer whether a button labelled “Confirm” creates a customer commitment or merely completes an internal review.
Build a journey register, not a screen gallery
Give each important journey four separate fields: required behaviour, observed behaviour, evidence, and status. Useful statuses are demonstrated, contradictory, untested, and awaiting a decision. “We could not access it” is not the same as “it does not exist.” A page loading successfully is not evidence that the entire process works.
| Area | Scope-recovery question |
|---|---|
| Entry | Who starts the journey, with which information and permissions? |
| Outcome | What must be true when the journey is complete? |
| Exception | What happens after a conflict, interruption or rejected request? |
| Operation | Who reviews the result and handles stuck cases? |
| Evidence | Which version and account were tested, and what was recorded? |
GOV.UK describes acceptance criteria as outcomes used to confirm that a need is met. User-story guidance. Apply that principle to observable results rather than writing a longer description of the screen.
Worked hypothetical example: a training-room booking portal
This is an illustrative scenario, not a client project or a real completion estimate. The inherited portal contains room listings, a booking-request form and a staff dashboard. The old brief says that customers “book a room,” while the business actually requires site-manager approval.
A review demonstrates that requests can be submitted and accepted in the test environment. There is no evidence yet that conflicting requests are prevented. A confirmation message arrives during one test, but failed delivery has not been examined. Calling this “finished except for notifications” would conceal important uncertainty.
The operational owner decides that submission creates a pending request and only approval reserves the time. Acceptance criteria now require the system to reject two accepted bookings for the same room and period, show consistent status to staff and customers, preserve the booking if notification delivery fails, and record who changed the status. These are proposed criteria for this fictional situation, not universal booking rules.
A UX/UI Audit may identify a separate issue: the button wording promises immediate confirmation even though staff review is required. That is an experience-clarity problem. Conflict prevention concerns functional behaviour. Keeping the two separate avoids treating every issue as a reason to redesign the page.
Separate missing delivery from new requirements
Maintain a decision log with the date, owner, source and effect of each decision. If the team now wants online payment and no approved scope included it, record a new requirement rather than a demonstrated defect in the previous delivery. If documents disagree, expose the contradiction for the owner to resolve instead of choosing whichever version makes an estimate easiest.
Scope recovery is not a contractual judgment about the previous supplier. It can document what was observed and what remains unclear. Contract interpretation or a dispute belongs with authorized owners and appropriate advisers. That boundary keeps the recovery report useful to the next delivery team.
It also protects the remaining budget. Without a change register, the team can spend weeks debating whether a capability was promised while nobody decides whether the business still needs it. Record historical uncertainty separately from the current decision to build, defer or exclude it.
Specify the recovery deliverables
Request a role-and-journey map, an asset and access register, an intended-versus-observed matrix, unresolved decisions, and acceptance criteria for the priority scope. The report should identify its limits: inaccessible systems, untested cases, and the precise version on which findings are based.
That provides a basis for an App Development completion or modification scope with explicit assumptions rather than an unsupported finish date. Software Quality Assurance can turn the agreed criteria into verification cases and handover evidence instead of relying on a demonstration alone.
Before accepting the recovery phase, check that:
- Every priority capability connects a user to an outcome, not just a screen name.
- Behavioural judgments have evidence or an explicit untested label.
- New decisions are separated from defects and inherited assumptions.
- Technical and operational decision owners are identified.
- The next estimate states dependencies and what could change it.
Do not require a recommendation to rebuild as a condition of accepting the report. A valid conclusion may be that selected journeys can be retained, others need investigation, and a smaller operational release is possible. The evidence should determine that recommendation.
Frequently asked questions
Must all source code be available before discovery starts?
Document and journey inventory can begin without it, but technical completion feasibility remains incomplete. Record that limitation; do not turn it into an automatic argument for rebuilding.
Are screen counts a useful completion measure?
They describe interface quantity. One screen may contain more permission, conflict and recovery logic than several static pages. Track accepted end-to-end journeys instead.
What if the previous team is unavailable?
Use authorized assets and operational knowledge, and mark what cannot be verified. Missing knowledge does not make the application’s current behaviour the correct requirement.
Will recovery produce a final fixed price immediately?
It can improve the estimate, but confidence depends on resolved access, integrations and operational decisions. A bounded technical investigation may still be necessary before commitment.
Start with a recovery phase whose outputs are explicit. Supply the assets you actually control and identify access you still need, so the completion conversation has a reviewable foundation.
Method reference
- GOV.UK: Writing user stories and acceptance criteria, used as a methodological reference rather than a Saudi regulatory requirement.
