THE ORGANISATION’S ROUTE TO 100%

Delivery carries the examined and approved product into its intended use. By this point, the project should be able to identify the candidate, the scope it fulfils, the grounds on which it has been accepted, and any limitations that accompany it. The remaining operations belong to the organisation’s delivery system. Their sequence depends on the product, recipients, operating environment, and responsibilities being transferred.

A desktop application, a hosted service, an internal library, and a professional design package require different delivery arrangements. The preceding chapters establish the information and responsibility that those arrangements consume. The organisation can append its established testing, approval, publication, deployment, or issuance workflows at this boundary. The manual supplies no substitute command sequence, release threshold, or universal set of signatures.

6.1Join the established delivery workflow

Identify the selected workflow and the scope of its authority. Establish which candidate it receives, which decisions must already have been made, and what further examinations or approvals it requires. Name the actor responsible for the delivery undertaking and the people authorised to decide its consequential questions. A general instruction to finish the project should not leave publication authority to inference.

Use the existing records to supply that basis. The accepted PRD and amendments identify the intended result. Deliverable contracts, evidence, and review records identify what has been produced and examined. The product decision identifies the use accepted by the responsible human. These sources should agree about the candidate and any limits that the recipient must understand. Resolve a material inconsistency before the affected delivery action proceeds.

The organisation may use one decision to approve the product and authorise delivery, or may allocate those acts separately. Preserve the actual arrangement. Model capability, a completed local graph, and permission to operate repository tools do not confer either authority.

Establish what the selected workflow returns. The result may include published artifacts, a deployed version, recipient instructions, external acknowledgments, and a record of the operation. Include only what the product and governing method require. The return should establish whether delivery occurred and whether the intended recipient can use the result on the stated terms.

6.2Preserve the identity of the delivered result

The delivery record must reach the result actually supplied. Source changes can be assembled, packaged, configured, signed, or deployed through several operations before they become the recipient’s product. Retain the relationships necessary to establish which approved candidate those operations used and what they produced.

Where delivery changes the candidate or the conditions under which it was examined, assess the affected evidence and approval under the governing workflow. Preserve earlier results with their original scope. The organisation’s method determines the required repetition or further examination. Chapter 5 develops the underlying candidate and evidence relationship; the delivery workflow applies it to the actual product and environment.

Record events outside the source repository with their outcomes. An external operation may return a receipt, an artifact identifier, an acknowledgment, or an inspection result. Retain the non-secret evidence needed for the stated conclusion. A command log can show that an operation was attempted while leaving its outcome unknown. Report that distinction and recover or repeat the required examination through the selected method.

If delivery fails or is interrupted, identify what occurred, what state was left, and what continuation is permitted. Preserve the approved candidate and the record of the failed attempt. Recovery and rollback follow the organisation’s arrangements and their actual effects on recipients or operating systems. Such actions require the same care with scope and evidence as the original delivery.

6.3Transfer the continuing responsibilities

A product can outlive the project that produced it. Handover therefore concerns the continuing responsibility for use, support, correction, and change as well as possession of the artifacts. Identify who receives each responsibility and what information they need to carry it. The receiving party should be able to locate the delivered baseline, its applicable requirements, significant decisions, evidence, and known limitations.

Provide the records in a form suited to their use. A maintainer needs a route from the observed problem to the governing obligation and affected implementation. An operator needs the applicable conditions and instructions. A person responsible for further acceptance needs the earlier decision and its exact scope. These needs can be served by references into the retained project record; duplicating the complete development history in every handover document would make future amendment harder.

Account for unfinished matters explicitly. Required work still within the present commitment remains an obligation until fulfilled or changed by the appropriate decision. Work allocated to a later undertaking retains its owner and basis. A concern that cannot yet find an executable home is retained with the missing allocation and an arrangement for reconsideration, as described in §5.6. Neither the transfer nor an action-item disposition supplies evidence that an unfinished commitment was met.

Confirm the receiving arrangement through the method the organisation uses. Sending a notice or placing files in a shared location establishes a communication event. Acceptance of an operational responsibility is a further matter whose terms should be recoverable. A handover record gives the project a definite basis for its concluding account.

6.4State the project’s outcome

Close the project with an account of its purpose, delivered result, accepted changes, and continuing obligations. Relate the outcome to the objectives and constraints that governed the work. Preserve the distinction between the original intention and any revised undertaking accepted during development. A sensible reduction in scope may produce a useful result while leaving part of the original objective unachieved.

The assessment should identify both achievements and limitations. An unsuccessful investigation may have answered its assigned question. A technically complete product may fail to provide the intended benefit. A useful product may have required more time or resources than the owner considers acceptable. The human judges these relationships; the project record supplies the work, decisions, and evidence needed to make that judgment intelligible.

A project can also be suspended or ended before delivery. Preserve the work worth retaining, its state and evidence, the reasons for stopping, and the responsibilities that remain. Prevent incomplete artifacts from being mistaken for an issued product. The organisation’s termination or suspension arrangements govern contracts, access, retention, and external obligations. This manual does not invent those procedures.

6.5Give subsequent work a sound starting point

Retain the delivered baseline and the records that explain what it must continue to satisfy. Stable claim identities, dependency references, and named verification methods help a later participant locate the affected obligation and its consumers. Earlier evidence identifies what was examined, under which conditions, and for which version. These relationships reduce particular reconstruction tasks when they remain accurate and accessible.

Maintenance begins from that existing product and its current condition. A bounded repair can use the appropriate maintenance authority and methods without repeating conceptual definition. A change to the intended outcome or governing scope may require a new development undertaking. The scale of that undertaking follows what is changing and what depends on it.

Keep incidental mechanisms in developer documentation so their revision need not restate an unchanged production obligation. A maintainer can replace an internal implementation while preserving the requirement and its evidence relationship. A mechanism that is itself a contractual or adopted design choice remains visible in the production contract. This distinction helps separate a local repair from a change requiring a broader decision.

Preserve the relationship between the current design and its predecessors. Retained code may belong to an older implementation that no longer governs the product. Identify that status and the replacement path, or remove the old code through an authorised change while preserving version history. When ownership moves, update the affected scope and dependency records. A successor should be able to locate the current implementation without inferring it from whichever code is easiest to find.

These records provide a more definite starting point; they cannot guarantee easy maintenance. An undocumented external dependency, an obsolete environment, an inadequate test, or an unfamiliar failure may still require substantial investigation. Record what that investigation changes so later work can use its result.

The working method is also a result worth examining. Retain observations about effective assignments, costly waits, useful tools, recurring misunderstandings, and the checks that found consequential defects. Distinguish measured results from impressions and later explanations. Changes to reusable workflows receive their own review and adoption so that another project can use them with an identifiable basis.

Project completion leaves a product, a record of what has been accepted, and a distribution of continuing responsibility. Their consistency gives the next participant something definite to use and something definite to question when circumstances change.