Planning a Multi-Site ICT Rollout: What Must the Pilot Prove?

Define the decision the pilot will support

For an ICT project covering several locations, a pilot should test a proposed common approach and identify the conditions that cannot safely be copied to the other sites. Before choosing the first location, write down which decisions the pilot must inform, what evidence will be collected and which site differences will still need assessment. A successful installation at one location is not proof that every branch is ready.

This guide is an original planning worksheet for an enterprise team in East Africa. DETIAN's public services cover design, supply, installation and support, with scope shaped by site conditions. The worksheet does not promise a particular rollout capacity, service territory at every location, equipment compatibility or delivery schedule. Those details require a project-specific discussion.

• DETIAN services

Separate the common requirement from each site's conditions

Start with the business use that should work across the locations. Examples might include an agreed staff connectivity task or a defined meeting-room use, depending on the actual project. Record the user's task and the proposed acceptance evidence before naming a preferred device. A shared equipment list alone does not establish that the sites have the same needs.

Create a comparison sheet with one row per site. Include the location, relevant user tasks, approximate scale, existing equipment, available plans, access constraints, external service dependencies and unresolved questions. Use verified information and identify the owner of each missing item. Do not copy the pilot site's values into blank cells for other locations.

Then mark which requirements are intended to be common and which are site-specific. A common user task may still need a different implementation because room layouts, existing infrastructure or operating arrangements differ. Treat this as a question for design review, not a reason to improvise an unapproved substitute during installation.

• System solutions

Choose a pilot for the questions it can answer

The easiest site to access may be useful for testing an installation procedure, but it may not represent the conditions that create the greatest uncertainty. Compare candidate pilot sites against the decisions you need to make. State explicitly which conditions the chosen site includes and which it does not.

For example, if the main uncertainty concerns integrating with existing equipment, a completely empty location may not answer it. If a location has unusual access restrictions, its installation experience may not represent ordinary sites. Neither observation automatically identifies the correct pilot; the team should select it with a documented purpose and limitations.

A pilot can also be too broad. Avoid treating it as a trial of every possible system and site condition at once. Define the agreed functions, users, interfaces and work boundaries. Identify the people authorised to review the evidence and decide whether the proposed common approach is ready to be used elsewhere.

A fictional three-site planning example

Imagine a fictional organisation planning work at sites A, B and C. A has a new room layout, B has existing equipment that the team hopes to retain, and C has restricted installation hours. These are invented planning conditions, not a DETIAN customer project or measured outcome.

Suppose the team selects B to investigate the reuse question. Its pilot record should describe which existing items and interfaces are in scope, the agreed checks and any unresolved compatibility questions. A successful result at B would address those specific conditions. It would not establish A's final layout or demonstrate that the installation can be completed within C's access window.

The rollout decision therefore needs two parts: what the pilot actually demonstrated, and which remaining site conditions still require evidence. A and C retain their open items until the responsible teams assess them. Do not mark all three locations ready because one pilot has a completed checklist.

Agree the evidence before the work begins

For each pilot question, record the proposed check, its scope, the criterion supplied by the relevant agreement, the person who will observe it and the record to retain. The criterion may be functional or procedural; this guide does not invent a universal performance threshold. An unanswered design question should remain a question rather than becoming an assumed pass condition.

Record actual results alongside the conditions under which they were obtained. State which users, locations, interfaces or operating situations were covered. If a check could not be performed, record why and who will arrange the next step. An expected result, a supplier statement and an observed result should not share the same status label.

Keep evidence proportionate to the project and follow the organisation's approved information-handling process. A planning enquiry can describe system roles and constraints without including passwords, access tokens or private configurations. The pilot worksheet is not authorisation to change access controls or bypass an existing change process.

Turn the result into a controlled reference for later sites

After review, identify the version of the agreed design and installation information that may be reused. List the pilot's unresolved exceptions and the conditions that require further site-specific review. A clear reference package can include approved drawings, equipment specifications, relevant configuration documentation, agreed test records and operating handover material, as appropriate to the actual scope.

For each next site, compare its verified conditions against that reference. Record the difference, its owner, the required decision and the approval or evidence needed before work proceeds. Do not silently change the reference package to match a local workaround, then present it as the same approved solution everywhere.

If a change affects the common approach, have the responsible team assess whether earlier sites need review as well. Keep the previous version and the reason for the change in the project's controlled records. This is a document and decision process, not a guarantee that a pilot prevents all later issues.

• Handover document index

Keep pilot acceptance separate from rollout readiness

A pilot outcome can support a decision without authorising the entire rollout. Before each site's work, confirm its remaining prerequisites, access arrangements, responsibilities and agreed checks. Record any conditions attached to proceeding. Use the organisation's existing approval process rather than treating this worksheet as permission to start.

The separate changeover go/no-go guide can help organise a particular site's transition decision. The office location schedule helps identify local endpoints. The handover document index helps people find the final records. None of those records alone answers whether a pilot's findings apply to a different location; the site comparison supplies that missing link.

• Site changeover worksheet
• Office location schedule

Prepare a useful multi-site enquiry

For a DETIAN discussion, bring the countries and cities, the intended functions, a site comparison sheet, available plans, existing equipment information and the decisions you want a pilot to support. Distinguish confirmed conditions from assumptions and identify which locations have not yet been assessed.

Ask which design, installation, supply or support work can be assessed for the proposed scope, and what additional information is needed. A useful first outcome is an agreed pilot purpose and a list of remaining site questions. Equipment, costs, attendance and scheduling remain subject to the actual project discussion, not to the fictional example in this guide.

• Contact DETIAN

Sources

• https://detianict.com/
• https://detianict.com/services/
• https://detianict.com/solutions/
• https://detianict.com/contact/
• https://detianict.com/guides/office-network-rfq-location-schedule/
• https://detianict.com/guides/ict-changeover-go-no-go-service-check-sheet/
• https://detianict.com/guides/ict-project-handover-document-index/