# Make joint delivery easy for the customer to understand. Plan a joint OT information engagement with VIEOX through clear scope, delivery roles, source access, acceptance evidence and customer communication. Canonical: https://vieox.com/partners/system-integrators/joint-delivery/ Publisher: VIEOX Published: 2026-10-20 Updated: 2026-10-25 ## What should a joint delivery plan establish? Agree the customer outcome, scope of each party’s work, access and change permissions, acceptance evidence and the people responsible for resolving dependencies. Include how the team will communicate progress and handle an unexpected gap. These decisions make a proposed collaboration concrete before implementation begins. When several organisations contribute to an industrial project, the customer should not have to discover who owns an issue by following a chain of referrals. A useful joint-delivery plan makes the contribution, dependencies and escalation route clear from the beginning. ## Write the outcome in the customer’s language Start with the review or decision the customer wants to improve. Identify the equipment, period, products and intended users involved. Clarify whether the work concerns information collection, context, interpretation, presentation or a combination that the parties can support. Record the existing systems and the responsibilities they retain. A narrower initial scope can be useful when it provides an honest test of the information journey. Keep future ambitions visible as later possibilities rather than allowing them to expand the first commitment silently. ## Agree how the contributions meet For industrial interoperability, agree both the connection and the meaning of the exchanged information. Identify which team can confirm source availability, equipment identities and operating definitions. Agree how sample records will be reviewed and how mismatches will be reported. A dependency should have an owner and a clear way to establish whether it is ready. Use an approved environment and access route appropriate to the proposed work. The team should understand who can authorise changes and who will represent operations, quality and security in the review. An information exchange should not imply permission to alter equipment or bypass a site procedure. ## Make verification part of the delivery conversation NIST’s Engineering Trustworthy Secure Systems guidance includes requirements, verification and validation within its systems-engineering perspective. For joint delivery, this is a useful reference for agreeing what evidence should connect the intended purpose to the completed work, rather than relying on an impressive demonstration alone. Sources: [1](https://www.nist.gov/publications/engineering-trustworthy-secure-systems) ## Give the customer one understandable account Agree how the partners will present progress, open questions and decisions needed from the customer. Separate a completed capability from one awaiting access, information or further evaluation. If a dependency changes the scope, bring that change into the conversation with its effect on the outcome. Before closure, review the result with an intended user. Can they follow the relevant operating record and understand its limitations? Record unresolved items and the next owner. This creates a useful starting position for the support and handover arrangements that follow. ## Practical starting points - State the intended customer task and operating boundary. - Map each contribution to a responsible party. - Agree access, change and review permissions. - Define acceptance evidence and dependency checks. - Maintain one clear account of progress and open issues. ## Questions, answered ### Who should lead a jointly delivered engagement? Leadership should be agreed for the opportunity, based on the customer relationship, scope and delivery responsibilities. The important outcome is a clear route for decisions and escalation, rather than an assumed arrangement. ### What if an existing system cannot provide the expected information? Record the gap and verify its cause with the source owner. The parties can then discuss a revised scope or another supported approach with the customer instead of presenting an unverified workaround as completed integration. ## Sources and further reading - [NIST SP 800-160 Vol. 1 Rev. 1 — Engineering Trustworthy Secure Systems](https://www.nist.gov/publications/engineering-trustworthy-secure-systems) ## Related reading - [Explore all partnership pathways](https://vieox.com/partners/) - [System Integrators](https://vieox.com/partners/system-integrators/) - [Lifecycle and handover](https://vieox.com/partners/system-integrators/lifecycle-and-handover/) - [OT observability gaps](https://vieox.com/insights/ot-observability/investigation-and-observability-gaps/) - [Start a partnership conversation](https://vieox.com/contact/)