Workshop completion did not settle the handover question

By the September 2026 ZanLIS follow-up, the developers had already attended earlier workshops and had access to the code and project documentation. The question for the review was how that preparation translated into working on the system.

I facilitated the two-day session with four developers from the Ministry of Health ICT team. It produced useful evidence of progress, while also showing why workshop completion could not answer the whole handover question.

Look at what people can demonstrate

On the first day, the developers cloned and ran the repositories locally with minimal guidance. We used that setup to review recent changes and place them within the wider integration ecosystem.

On the second day, they accessed staging, configured SSH keys, and inspected the deployment stack, workflows, service status, and logs. One participant pushed a change, and the group followed the automated build and deployment flow. They also triggered deployments across the laboratory, processor, and warehouse stacks and checked the resulting services.

These activities established more than a statement that access had been provided. They showed that the access worked and that the developers could use it for concrete tasks.

The group also used the processor's production operations dashboard to trace requests and retries into laboratory instances. We revisited support and escalation: what evidence to gather, how to distinguish operational from technical issues, and who should receive the case.

Keep different kinds of evidence separate

The developers reported confidence in performing some ecosystem work. That was useful feedback, but it was different from observing independent delivery over time. Individual self-assessments were still pending in the review record.

The distinction affected how I recorded the outcome:

Evidence	What it established
Repositories cloned and run with minimal guidance	The local setup and access were usable.
Deployments triggered and checked during the session	Participants had practiced the deployment workflow.
Confidence reported by participants	Their own assessment of readiness for some work.
Ongoing tasks completed independently	Evidence still needed beyond the session.

We discussed candidate tasks, but none was assigned or implemented during that review. Treating the candidate list as completed delegation would have overstated what happened.

Regular exposure was the harder constraint

The discussion identified competing responsibilities and limited work on ZanLIS between workshops as the main constraints. No blocking access gap emerged during the review.

Another round of access provisioning would not resolve that. Continued participation in the existing work and delegation arrangement mattered: seeing changes arrive, investigating ordinary problems, proposing fixes, and receiving review often enough to keep context.

For subsequent work, bounded tasks offered a practical way to build that evidence. A small problem could move through problem review, solution review, and implementation review without transferring responsibility for an entire critical release at once. That was a direction for continued practice, not an exercise completed during these two days.

We also kept training gaps specific. Familiarity with the processor operations dashboard did not establish readiness to own the separate stakeholder reporting dashboard or data warehouse. Those needed their own attention.

Record the next responsibility clearly

The review left a more useful picture than a single “handover complete” label: working access, tasks demonstrated, confidence expressed, and areas requiring continued practice or separate training.

That is how I now think about technical handover. Documentation and workshops create the conditions for ownership. Evidence accumulates when people repeatedly use those resources to make changes, support users, and decide when they need help.