From analysis to handover

1. The connection is part of the work

A system is handed over when the receiving team can operate it, explain decisions and handle exceptions. What does a rejected transaction mean? Who decides on an exception? Which agreement applies when daily processing differs from the process model? These connections are part of the project outcome.

This paper sets out four steps: clarify the work, follow a concrete situation through the chain, record the material decisions and let the receiving team put it into practice. This gives handover a clear place in analysis, project governance and delivery.

Who is it for?

Sponsors, business analysts, project and programme managers, IT teams and the people putting change into use. Start with a bounded change in which several disciplines depend on one another.

The experience behind the question

ALBIR draws on nearly thirty years of experience in payment platforms, business analysis, international projects, service delivery and education. The common thread is connecting business, technology and everyday use. That experience informs the approach developed in this paper.

The central question: can the receiving team perform, explain and adjust the new work when the project team is no longer beside it?

2. Start with the work that needs to change

An assignment such as “renew the payment platform” is too broad to serve as a shared working picture. First choose a recognisable flow, such as an incoming payment that cannot be processed automatically. Follow it from the first notification through processing, feedback and any correction.

Ask a colleague to demonstrate the current work. Which sources are used? What information is missing? When does another team become involved? Compare this with the process model and system documentation. A difference may be an error, but it may also be a necessary response to a situation the model does not describe.

Build a shared working picture

• Purpose: what should people be able to do better or differently?
• Boundary: where does this flow start and end?
• People: who performs, reviews, decides and maintains?
• Dependencies: which systems, suppliers, data and agreements are needed?
• Evidence: how will we see that the intended work actually succeeds?

Keep this description small enough to discuss together. Reuse process diagrams, tickets and test cases. A new document is useful when it clarifies a missing connection. Record open questions and who can answer them.

Shared understanding can be tested

Ask two participants to explain the same exception separately. Different answers can reveal where terminology, responsibilities or expected system behaviour diverge. First understand the difference: a quick agreement can hide a substantive problem.

3. Make agreements that hold the chain together

Projects can make good local progress while the overall connection remains unclear. One team delivers a component, another writes instructions and a supplier changes an interface. Someone needs to examine whether their assumptions fit together.

Use one decision record for a material agreement across the chain. Describe the question, chosen option, alternatives considered, sources, responsible decision-maker and conditions that would require reconsideration. Link to existing working documents rather than copying entire records.

Example: who may resubmit?

After interrupted payment processing, resubmission can cause duplicate execution if status is misunderstood. Agree which status information is needed, who investigates and when resubmission is permitted. Carry that agreement through into system behaviour, operating instructions and tests.

• Analysis describes business meaning and exceptions.
• Technology makes states, interfaces and failure paths understandable.
• Operations checks whether a colleague can choose the appropriate next step.
• Project governance organises decisions and follows open dependencies.
• The authorised owner determines whether the remaining risk is acceptable.

This allocation of work connects with the responsibilities, phases and decision points of PM² [1]. Establish who takes the decision, who carries out the work and who follows up open dependencies.

4. Test handover with an unfamiliar case

A demonstration by the builder shows that the builder knows the solution. Handover raises another question: can a receiving colleague handle an appropriate case with the resources that will actually be available?

A fictional payment migration

An organisation replaces part of its payment processing. The normal flow works in the test environment. During handover, a colleague receives an interrupted case for which two screens show different statuses. Develop this example using test data and the future user’s access rights.

The colleague finds the source of the status, explains what is known and uncertain, and identifies who must decide. The facilitator observes where help is needed, which documentation is missing and whether escalation is workable. A subject expert defines in advance what constitutes an adequate approach for this case.

• Prepare a normal case, an exception and a disruption.
• Use the access rights and instructions intended for actual operation.
• Let the receiving colleague work first; record help from the builder.
• Distinguish missing knowledge, unclear authority and technical failure.
• Address the gap and repeat a substantively comparable exercise.

Record what the team could do independently, where it got stuck and which action is needed. Assign each gap to an owner and test the improvement again. Use the findings to decide what is ready for handover and what needs further work.

5. A worksheet for a usable handover

Use this sheet to prepare and decide on the handover of one process or change. Refer to existing sources and evidence. Discuss the answers with the people taking over the work.

What you can record

Record how quickly the relevant source was found, where support was required and which substantive errors occurred. Keep the conditions comparable when repeating the exercise. Assess capability through what a person can carry out and explain independently.

Start with one dependency that has meaningful consequences. Make the problem visible, assign an owner and check whether the action works. An open question that is followed up moves handover further than a completed checklist.

6. From a project result to lasting capability

Handover is one moment in a longer change. New colleagues arrive, a supplier changes software and a former exception becomes routine. Agree which events should prompt a review of the most important arrangements.

For example, the only administrator leaves, a critical interface changes or an incident reveals inadequate status information. A review need not repeat the whole project. First examine which agreement is affected and what evidence is needed for a new decision.

A small first application

• Choose one current handover and an authorised owner.
• Create the working picture and one decision record with the relevant disciplines.
• Ask a receiving colleague to handle a carefully selected case.
• Record gaps, actions and a decision with conditions.
• Follow up on the improvements made and what they achieved.

Through ArtiProof we develop these questions about knowledge, evidence and transfer further [2]. The connection to practice is direct: which knowledge supports the work, how can people find the reasoning, and who can carry it forward?

Sources

[1] European Commission, PM² Project Management: governance, lifecycle and available resources.

[2] ArtiProof, Keeping Organisational Knowledge Dependable in the Age of AI, 1.2 EN (2026).

ALBIR BV · version 1.1 · 4 October 2026 · info@albir.be

1. Europese Commissie / European Commission - PM² Project Management ↗
2. ArtiProof - Public Whitepaper 1.2 EN ↗