From award to maintenance – creating a traceable delivery

Many digital assignments start with a clear requirements brief and a signed contract – only to lose direction further into the delivery. The cause is often not technical failure but unclear responsibilities, underdocumented decisions, or a lack of structured progress tracking. This article describes a practical approach for building a delivery that remains traceable from initiation through long-term maintenance.

Why governance should begin before implementation

A common shortcoming in digital assignments is that governance structures are set up late – sometimes only after problems emerge. This leads to ambiguity about roles, decision authority, and escalation paths at a point when changing course is difficult.

A clear delivery plan should be in place before the implementation phase begins. It does not need to be complex, but it should address: who is responsible for what, how decisions are made and documented, how status is reported, and what applies when deviations occur.

Roles and responsibilities

A traceable delivery requires named and acknowledged responsibilities. Common roles to define include:

• Assignment owner or client responsible – the person at the client organisation who approves deliverables and escalates decisions.
• Product or requirements owner – the person who owns the requirements brief and ongoing prioritisation.
• Delivery responsible at the supplier – the primary contact accountable for the delivery proceeding to plan.
• Technical responsible – the person who owns technical decisions and documentation.

When roles are unclear it becomes difficult to know who to contact when something goes wrong, who can make decisions, and who signs off on an accepted deliverable.

Documented deliverables and decisions

Every assignment should have an inventory of what is to be delivered, when, and what is required for a deliverable to be accepted. A contract that describes "a system" is insufficient – the delivery needs to be broken down into approvable components with acceptance criteria.

Decisions that affect scope, timeline, or cost should be documented in writing with date, decision-maker, and consequence. This applies to decisions made by both client and supplier.

Change management

Requirement or scope changes are common in digital assignments. Without a clear handling process they risk causing scope creep, unclear accountability, and mutual dissatisfaction.

1. The change is identified and described by the initiating party.
2. A consequence analysis is performed by the supplier: impact on time, cost, and other deliverables.
3. The change is approved in writing by the appropriate person at the client.
4. The change is added to the delivery plan with a new date and acceptance criterion.
5. The change log is updated.

Status reporting

Regular status reporting gives the client visibility and the ability to make informed decisions. A status report does not need to be a heavy document – what matters is that it is regular, honest, and includes risks or deviations. Useful elements in a status report may include:

• Summary of the period: what has been done, what is planned.
• Status per active deliverable: on track, delayed, blocked.
• Current risks and deviations with ownership and action responsibility.
• Upcoming decision points that require client input.

Acceptance and handover

The acceptance phase is often where the most friction emerges if it has not been prepared early. A clear acceptance process includes:

• Pre-defined acceptance criteria per deliverable.
• A named person at the client responsible for acceptance testing.
• A defined acceptance testing period.
• A process for reporting and handling deficiencies found during acceptance.
• Formal sign-off or written confirmation of an approved deliverable.

Maintenance and continuity

A delivery is not complete when the system goes live – it is complete when the client organisation can independently maintain and develop what has been delivered. This requires:

• Technical documentation sufficient for a new operations responsible to take over.
• Operational documentation for routine tasks, issue handling, and common changes.
• Details of external dependencies, licences, and third-party services.
• Clear ownership of code, data, and configuration.

The right time to plan for maintenance is not at handover – it is during the implementation phase of the assignment.