ICT Changeover: Agree the Go/No-Go Decision and Service Checks

Agree the decision before booking the interruption

Before an ICT changeover, agree who may authorise the start, which business tasks must work afterwards, and when the team must stop or begin the agreed recovery procedure. Put those decisions beside the affected systems, dependencies and evidence. A maintenance appointment alone does not show that the change is ready to proceed.

For an occupied office, factory administration area or project compound in Tanzania or elsewhere in East Africa, this separates a proposed work window from permission to interrupt a service. The worksheet below helps an owner and supplier discuss the change. The responsible technical team still needs to develop and approve the equipment-specific work, testing and recovery procedures.

• Review how DETIAN defines installation and upgrade scope

Define the change boundary and the people affected

Give the change a reference and a revision. Identify the site, room or area, the current arrangement, the proposed arrangement and the reason for changing it. State which services may be interrupted and which must remain available. Keep optional improvements outside the agreed change unless their scope is separately reviewed.

List the business tasks that depend on the affected connection. For example, an office network change may affect access to a shared application, a meeting room and a network printer. These are separate checks even if they use the same switch. Ask the relevant service owners to confirm the dependency list; an equipment drawing alone may not describe how people use the system.

Name the person approving the operational interruption, the person directing the technical work, the owner of each dependent service and the person communicating with users. Record their availability for the actual window, including any other provider whose participation is necessary. A contact name without confirmed availability leaves a dependency open.

For a multi-site project, identify the local date and time zone for each participant. Do not assume that an overseas team and the site read an unlabelled time in the same way. Record any changes to the agreed window with the change revision.

• Check the actual systems and interfaces in the project

Use five readiness rows with evidence and an owner

Create these columns: requirement; responsible person; evidence reference; checked date; status; and unresolved question. Use explicit statuses such as ready with evidence, awaiting confirmation, or outside this change. An empty cell does not mean ready.

R1 — Scope and interruption: identify the approved change revision, affected users and permitted activities. Confirm that the operational owner has accepted the proposed interruption, and record how users will be informed. Permission to enter a building is a separate matter from permission to interrupt its systems.

R2 — Technical work and dependencies: ask the technical lead to identify the applicable work procedure, required personnel and prerequisites. List dependencies on the application owner, internet provider or another project team. Keep access arrangements in the authorised administration process; do not attach passwords or recovery secrets to the general worksheet.

R3 — Recovery readiness: ask the responsible team to identify the previous usable arrangement, the recovery procedure and the evidence that required records or resources can be used. Record the owner and expected recovery duration with its basis. The existence of a backup file, by itself, is not evidence of a workable restoration procedure.

R4 — Service checks: name the agreed checks, observers, sample material and evidence to retain. Confirm that the people who can assess the affected business tasks will be available. Mark any check that cannot be performed as an unresolved decision, not a presumed pass.

R5 — Decision and communication: name who can say go, stop or recover; define the decision checkpoints and escalation route; and confirm how the site will receive an accurate progress update. Resolve conflicting instructions before the window starts.

Check usable services as well as equipment status

For each service, record its identifier, location, normal task, permitted test method, expected result, reviewer and evidence reference. The technical owner should set suitable criteria for the actual system. A link light, a reachable device or a successful sign-in may be useful observations, but each answers a narrower question than whether the agreed work can be completed.

A fictional office might list S1 as opening an approved sample record in the required application from an agreed workstation, S2 as printing an approved test page at the intended printer, and S3 as completing an agreed meeting-room call with a nominated remote reviewer. The examples illustrate how to describe a task; they are not a test specification or proof that any proposed network supports those functions.

Record the relevant starting condition before the change when an authorised check is appropriate. If a task already fails, keep that observation separate so it is not silently blamed on the new work or declared fixed without evidence. Use approved sample information rather than customer records or confidential meeting content.

Microsoft’s safe-deployment guidance uses health checks between rollout phases and calls for halting and recovery when a deployment causes an issue. It is guidance for software and infrastructure workloads. Your technical team must define the checks and recovery approach suitable for this particular site and equipment.

• Microsoft: safe deployment checks and recovery principles

Work backwards from the required return to service

The work window needs time for both the proposed change and the agreed recovery path. Ask the responsible team to explain its duration estimates, what evidence supports them and what conditions could invalidate them. Include service checks and communication in the timetable instead of treating the end of equipment work as the end of the interruption.

Consider a fictional planning example, not a DETIAN delivery promise. Suppose the site approves a window from 19:00 to 21:00 EAT. The technical team supplies a supported estimate of 35 minutes for recovery, the service owners require 15 minutes for the agreed checks, and the project assigns a 10-minute contingency. These are assumed project inputs, not standard allowances.

The protected time is 35 + 15 + 10 = 60 minutes. Working back from 21:00 gives a latest recovery decision point of 20:00. The two-hour window therefore does not provide two hours for change work. This calculation only tests whether those stated assumptions fit together; it does not establish that recovery will take 35 minutes or that the proposed work is feasible.

If a prerequisite is late, the estimated recovery time increases, or an essential reviewer becomes unavailable, recalculate and return the decision to the authorised owner. Do not spend the reserved recovery time on extra work merely because the appointment has already started. Any extension needs a new explicit operational decision under the project’s arrangements.

Keep go, hold and recovery decisions visible

At the agreed starting checkpoint, review the current worksheet revision and the open items. Record the actual decision, decision maker, time and evidence references. If a required dependency is missing, record hold with the missing condition and the owner who must resolve it. A supplier arriving onsite does not resolve a missing application reviewer or an unapproved interruption.

During the window, keep a short event record: time and time zone; action or observation; affected service; evidence reference; and decision or next owner. Separate a reported symptom from a confirmed result. If a stop condition is reached, the authorised technical and operational owners should apply the agreed procedure rather than continue on an undocumented assumption.

Recovery is also an outcome to verify. Record which agreed tasks work after recovery, which remain untested and whether any restrictions continue. Do not describe the attempt as a successful upgrade when the site has returned to its previous arrangement. Retain the failed or incomplete observations so the next proposal can address them.

Close the record without losing the remaining work

After the window, compare the actual arrangement and observed service results with the approved scope. Record completion, recovery to the previous arrangement, or remaining restrictions accurately. Assign unresolved items and state who decides the next step. A later attempt should be reviewed against the then-current conditions rather than treated as an automatic repeat of the first plan.

Keep the approved worksheet, event record, service checks and updated document references with the project handover records. Maintain controlled access to configuration and recovery material. The general index should identify the custodian and location without exposing credentials.

Where existing equipment is being retained, connect the final arrangement to the reviewed reuse decision. If the agreed role or interface changed during planning, have that change assessed and documented before claiming that the earlier reuse decision still covers it.

• Organise the resulting ICT handover records
• Review existing equipment against its intended future role

Bring DETIAN the change scope and the unanswered questions

For an initial upgrade discussion, prepare the project country and town, systems involved, current arrangement, intended change and business tasks that must remain available or be restored. Include the proposed local-time window, responsible contacts, other providers involved and the points that still need technical assessment. Share only approved non-sensitive records initially.

DETIAN’s public services include design, equipment supply, installation and maintenance, with the work defined for the actual site. Use the official contact page to discuss the proposed scope, dependencies and service checks. Availability, interruption arrangements and recovery responsibilities need agreement for the enquiry; this worksheet does not promise a fixed completion or restoration time.

• Discuss your ICT upgrade and operating constraints with DETIAN

Sources

• ICT Design, Installation & Maintenance | DETIAN ICT
• AV, CCTV, Networks & Smart Building Systems | DETIAN ICT
• Contact DETIAN ICT | Tanzania & East Africa
• Existing ICT Equipment: Build a Reuse Decision Register Before an Upgrade | DETIAN ICT
• ICT Project Handover: Build a Document Index the Receiving Team Can Use | DETIAN ICT
• Architecture strategies for safe deployment practices - Microsoft Azure Well-Architected Framework | Microsoft Learn