One integrator or many vendors: design-build-operate-maintain
Design-build-operate-maintain under one integrator versus splitting a project across vendors: where interface risk sits, and what the contract should say.
Ahuva Electronic Technologies · Published
Key points
- Design-build-operate-maintain (DBOM) means one contractor designs a system, builds it, runs it and maintains it, and is accountable for all four.
- Splitting a project across vendors moves the risk to the interfaces between them, and the owner usually ends up managing those interfaces.
- A single integrator carries interface risk inside one contract, so a fault has one owner regardless of which subsystem caused it.
- The main risk of one contract is dependence on one company. Open protocols, owned documentation and a handover clause control that risk.
- Splitting makes sense for packages with few interfaces to the rest of the project, or where the owner has a strong in-house engineering team.
What is design-build-operate-maintain?
Design-build-operate-maintain is a contract model where one party is responsible for a system from first design to the end of its maintenance period. The owner sets the requirements and the service levels. The contractor decides how to meet them and stays responsible for the result.
For a command centre, data centre or building-wide ELV project, this matters because the systems depend on each other. A video wall is only useful if the network, servers, VMS and integration software all work. When one party owns all of it, a fault has one owner.
What goes wrong when a project is split across vendors?
When a project is split, each vendor is responsible for its own package and nobody is responsible for how the packages work together. The problems show up at the interfaces, often late in the project, when changes cost the most.
- Faults bounce between vendors: the camera vendor blames the network, the network vendor blames the software
- Design gaps: power, cable routes or rack space for one package are not in anyone else's drawings
- Integration is left to the end, when each vendor considers its own scope finished
- Different warranty and support terms, so maintenance becomes several contracts with several response times
- Documentation arrives in different formats, or not at all, and the owner has no single record of what was built
What are the stages of a single-integrator project?
A single-integrator project runs through defined stages, each handing a clear output to the next. Ahuva works in six stages, in this order.
- Consultation: guidance on selecting the right products and solutions, and on reliable brands and interoperable technologies that work together
- Design and Engineering: network architecture, cabling, hardware placement, power, security and management interfaces planned in advance, so early analysis removes rework and change requests
- System Documentation: device location drawings, pre-wire, technical power, schematics, rack elevations and equipment space planning, prepared before construction and coordinated with the client's design team
- Implementation: standards-compliant structured cabling and best-practice installation, for new deployments and upgrades
- Project Management: end-to-end execution under defined procedures, with continuous coordination across clients, contractors and implementation partners
- Maintenance and Support: preventive maintenance, system tuning and performance optimisation at defined intervals, with support available 7am to 10pm, six days a week, on government contracts
What are the risks of one contract, and how are they controlled?
The main risk is dependence. If the owner relies on one integrator for design, build and maintenance, it can be hard to change supplier later or to hold the integrator to account on price. These risks are real, and the contract should address them directly.
Three controls do most of the work. First, specify open protocols and documented interfaces, so any competent integrator can maintain or extend the system later. Second, make all drawings, configurations, passwords and source documentation the owner's property, delivered and updated through the contract. Third, include a handover clause that sets out what the integrator must provide if the maintenance contract ends or moves.
When does splitting a project make sense?
Splitting makes sense when a package has few interfaces to the rest of the project, or when the owner has the engineering team to manage those interfaces itself. Civil works, furniture and some standalone systems are often let separately without much risk.
It makes less sense for tightly connected systems such as the network, servers, surveillance, integration software and control room of a command centre, or the fire alarm, voice evacuation and BMS of a building. There, the cost of managing interfaces usually outweighs any saving from separate bids.
What should a DBOM contract say?
A DBOM contract should say what the system must achieve, how that will be measured, and what happens at the end. Hardware lists alone do not do this.
- Performance requirements and uptime targets for each subsystem
- Response and resolution times, by severity, for the maintenance period
- Preventive maintenance schedule and reporting
- Ownership of documentation, configurations and credentials
- Open interface and protocol requirements
- Spares and OEM support commitments for the full contract period
- Exit and handover obligations
Frequently asked questions
- What does DBOM stand for?
- DBOM stands for design-build-operate-maintain. It is a contract model where one party designs, builds, runs and maintains a system and is accountable for all four stages.
- Is a single integrator always more expensive than separate vendors?
- Not necessarily. Separate bids can look cheaper at award, but the owner then carries the cost of managing interfaces, rework and several maintenance contracts.
- How can an owner avoid lock-in with one integrator?
- Specify open protocols, take ownership of all documentation and configurations, and include a handover clause that applies if the maintenance contract ends.
- What is interface risk in a systems project?
- It is the risk that separately supplied systems do not work together as intended. It sits between contracts, so in a split project it usually falls on the owner.
Related
Scoping a system like this? Talk to the team that designs, builds and maintains it.
Contact us