Qatar projects fail approval for procedural reasons far more often than for technical ones. The design is sound, but it was submitted to the wrong authority, in the wrong sequence, or without the supporting documentation that authority expects. This guide maps the regulatory landscape for ELV and ICT design in Qatar — who approves what, how the submissions sequence, and where designs most commonly get sent back.
Who Approves What
| Authority | Typical remit | Relevance to ELV / ICT |
|---|---|---|
| Qatar Civil Defence Department (QCDD) | Fire and life safety approval | High — fire alarm, PAVA, emergency lighting, egress interfaces, suppression |
| Ministry of Municipality | Building permit and planning | Moderate — overall building permit under which packages sit |
| Ashghal (Public Works Authority) | Public infrastructure; publishes Qatar Construction Specifications (QCS) | High — QCS is the specification baseline referenced by most projects |
| Kahramaa | Electricity and water utility | Moderate — supply, metering, and electrical interface requirements |
| Ooredoo / Vodafone Qatar | Telecom service providers | High — telecom entry, provider room provision, service riser requirements |
| Master developer (e.g. Lusail, Msheireb) | Development-specific design controls | High — often adds requirements above national baseline |
On a Lusail or other master-planned development, the developer design guidelines sit on top of the national requirements, not instead of them. A design compliant with QCS may still be rejected by the master developer review for not meeting development-specific standards on, for example, district cooling interfaces, public realm lighting or telecom provisioning. Obtain the current developer design manual at the start.
Qatar Construction Specifications (QCS)
QCS is the specification framework published by Ashghal and adopted as the reference baseline on the large majority of Qatar projects, public and private. For ELV and ICT design it matters in two ways:
- As the specification baseline. Many project specifications are written as "QCS, amended by the following" — so the QCS text governs wherever the project specification is silent
- As the arbiter in disputes. Where a contractor proposes a substitution, QCS is usually the document both sides return to
Confirm the revision in writing
QCS is periodically revised. Designing to a superseded revision is a common and entirely avoidable cause of rework. Confirm which revision applies to your project, in writing, before design starts — and state the applicable revision on the drawing title block and in the specification preamble so it is unambiguous later.
Fire and Life Safety — the QCDD Route
This is the approval that most often controls the programme, because it gates both permit and handover. The ELV design content that QCDD review typically focuses on:
- Fire detection and alarm system — device coverage and spacing, zoning, panel location and annunciation, battery standby capacity
- Voice alarm / PAVA — zoning aligned to the evacuation strategy, intelligibility, amplifier redundancy and backup power
- Interfaces to other systems — access control release on escape routes, lift homing, HVAC and damper shutdown, smoke control activation
- Emergency lighting — coverage of escape routes and duration
- Cause-and-effect matrix — the document QCDD will scrutinise most closely, and the one most often submitted incomplete
- Firestopping at every compartment penetration by ELV containment and cabling
Approvals Sequencing
The general shape of the sequence, which should be confirmed against current practice for your project type:
- Concept / preliminary submission — fire strategy and system approach agreed in principle before detailed design invests effort
- Detailed design submission — full drawings, calculations, cause-and-effect, equipment data
- Comment and resubmission cycles — plan for more than one round; single-pass approval is not the norm
- Approved-for-construction issue — construction proceeds on the approved package
- Inspection and testing — witnessed testing against the approved cause-and-effect
- Completion certification — required before occupancy
Build realistic review durations into the programme. Compressing the approval allowance is a common planning error and one that cannot be recovered later by working faster.
Telecom Provider Requirements
Telecom provider requirements are frequently discovered late, and they have real spatial consequences that architects need early.
- Provider entry room — dimensions, location relative to the site boundary, and access arrangements are set by the provider, not by the design team
- Duct entry — number, size and route of incoming ducts from the street
- Riser provision — dedicated telecom riser separate from other services, with specified minimum dimensions
- Floor distribution rooms — where the provider terminates on each floor in multi-tenant buildings
- Ownership boundary — the demarcation point between provider infrastructure and building infrastructure must be explicit in the design
Engage the provider at concept stage. A provider room requirement discovered after the core is fixed forces either a spatial compromise or a redesign.
Where Designs Most Commonly Get Returned
1. Incomplete cause-and-effect matrix
Inputs and outputs listed but interactions not fully defined, or the matrix inconsistent with the drawings and the fire strategy narrative.
2. Missing or unsupported calculations
Battery standby calculations, PAVA amplifier and intelligibility calculations, cable sizing and voltage drop. Submitting results without the working behind them invites a comment.
3. Uncoordinated egress interfaces
Access-controlled doors on escape routes without a compliant, documented release arrangement coordinated between the access control design, the door hardware schedule and the fire alarm interface.
4. Superseded standard references
Specification citing an outdated QCS revision or a withdrawn standard. Check every reference before issue.
5. Master developer requirements not addressed
A nationally compliant design that ignores the development-specific design manual — common on Lusail projects where the developer requirements exceed the national baseline.
6. Drawings and specification disagreeing
Device counts, model references or performance requirements that differ between the drawing set, the schedules and the specification. Reviewers find these quickly.
A Practical Pre-Submission Checklist
Before any ELV package goes to an authority, confirm:
- Applicable QCS revision confirmed in writing and stated on the documents
- Master developer design manual obtained and its requirements addressed
- Cause-and-effect matrix complete, and consistent with both the drawings and the fire strategy
- All calculations included with their working, not just their conclusions
- Egress door release arrangements coordinated across access control, hardware schedule and fire alarm
- Firestopping detailed at every compartment penetration
- Telecom provider requirements confirmed and reflected in the spatial design
- Drawings, schedules and specification cross-checked for consistency
- Every standard reference verified as current
- Submission format and file conventions confirmed against the authority current requirements
Compliance-Ready ELV Design for Qatar Projects
We prepare ELV and ICT design packages structured for Qatar authority submission — drawings, calculations, cause-and-effect matrices and specifications, coordinated with your Qatar-based approval team.
Get a Free Design Quote →Summary
Qatar approvals reward preparation rather than speed. Confirm the applicable QCS revision and the master developer requirements before design starts. Treat the cause-and-effect matrix as a primary deliverable rather than a late formality. Engage telecom providers and QCDD early enough that their requirements shape the design instead of disrupting it. Allow genuine time for review cycles. And confirm every specific in this article against current authority requirements with your Qatar-based team — the process shape is stable, but the detail moves.