Where every DCT property stands today
DCT's own platform inventory, March 2026. Properties operated by Create today move to the new squads through a three-week internal handover; the rest run the full six-week takeover playbook. Choose a property in the picker above; every page follows it.
sessions on Experience Abu Dhabi, FY2025
properties operated by Create today, internal handover to the new squads
properties for structured takeover or assessment; 5 more in Appendix 1 with scope to confirm
production releases through DCT CAB, web and app
Select a property to open its takeover checklist. Progress you tick during the session is kept on this device only.
Handover intake
Issued on day 5. The estate view first; choose a property in the picker above, or click a row below, to open its record. Rows for the properties Create operates are pre-filled for DCT to confirm. What comes back decides the handover sequence.
Estate-wide, from DCT
Unblocks the Digital Strategy workstream from day 10.
All properties
Click a row to open its record.
Property list from DCT's Appendix 1 digital platform overview, March 2026, plus DCT Corporate, Cultural Foundation, Qasr Al Hosn and Al Ain Museum from the SOW scope. Entries are kept on this device only; copy as CSV to move them into DCT's tooling.
Takeover checklist
Four phases, each with an exit signed by the Product Owner. Operated properties run a three-week internal handover to the new squads; takeovers run the full six weeks. Tick items as they land.
First 90 days
Every task from award to day 120 with an owner, a deliverable and its dependency. Week 1 kickoff and intake, then two squads: squad 1 carries the operated estate and takes over DCT Corporate then Saadiyat Island; squad 2 carries Zayed National Museum and takes the culture sites in two waves. Ramadan and Eid are on the calendar and the plan works around them; an assessment cell runs the assessments; day 90 is a checkpoint and the second wave closes out by day 120 with two weeks of contingency. Change the start date and the calendar follows.
Squad 1: destination and corporate
The 11 Digital Unit, Data & AI and Visitor Experience properties Create operates today (Experience Abu Dhabi web and app, Calendar, ADCEB, Al Ain, Al Dhafra, Saadiyat Cultural District, Maritime, Ask Abu Dhabi, Concierge, kiosks), moved to the squad structure by day 14, then run and enhanced. DCT Corporate taken over from day 15, Saadiyat Island from day 57. Carries the traffic risk; shared leads weight here in January and February.
Squad 2: culture and museums
Zayed National Museum web and app, operated by Create today and owned by Museums Shared Services, moved to the squad by day 14. Abu Dhabi Culture, Cultural Foundation and Manarat Al Saadiyat from day 15; Berklee Abu Dhabi and Qasr Al Hosn from day 57; museum benchmarking from day 78. Carries the discovery risk; shared leads weight here from March. The strategy team and the assessment cell are not squads.
Day offsets are the plan; calendar dates derive from the Day 1 you set. Pre-mobilisation assumes a four-week gap between award and contract start. Statuses are kept on this device only.
Technical assessments
Five assessments run in parallel by squad, two to three weeks per platform. Each produces a document DCT keeps. Score maturity as you go; scores are kept on this device.
Risk register
The risks we expect in a Sitecore landscape with multiple integrations, active projects and partial documentation, and what we do about each. The first is a known risk in DCT's estate today.
| Risk | Likelihood | Why it happens | Mitigation |
|---|---|---|---|
| Shared Sitecore environment | High | A deployment or issue on one site affects others. Being mitigated with DCT Technology and Security today. | Per-site release calendar, isolated pipelines, regression across co-hosted sites before every release. |
| Partial documentation | High | Knowledge lives in people and tickets, not in the repository. | Gap register in week one; reconstruct from code and runtime; AI-drafted documentation verified by leads. |
| Undocumented integrations | Medium | webMethods, partner APIs, certificates and keys with no owner or renewal date. | Integration mapping, contract tests, certificate and key inventory with a renewal calendar. |
| In-flight initiatives stall | Medium | Transition absorbs the people who were carrying them. | Protected lanes with named owners; change-freeze exceptions through CAB, not around it. |
| Key-person dependency | Medium | The outgoing vendor's knowledge leaves with individuals. | Recorded remote sessions and demonstrations, supervised execution on screen-share, a 24-hour question log, exit criteria signed per platform. |
| Debt surfaces as incidents | Low | Latent defects appear under campaign load or after a first release. | Stabilisation backlog ranked by production risk; quick wins first; burn-down reported monthly. |
Stabilisation strategy
Fix the top production risks first, keep releases flowing through CAB, and confirm operational readiness against a written checklist before any Phase 2 scaling.
Incident runbook
Severity model, escalation ladder and communication rhythm. Response and resolution targets are proposed for agreement with DCT and aligned to the scoring used in the current Experience Abu Dhabi support model.
Severity model
| Severity | Definition | Score | Respond | Restore |
|---|---|---|---|---|
| P1 | Site or key journey down, or major degradation during an active campaign | 8.0 to 10 | 15 min | 4 h |
| P2 | Major journey degraded, key pages impacted during an active campaign | 6.0 to 7.9 | 1 h | 1 business day |
| P3 | Minor degradation, workaround available, no campaign exposure | 4.0 to 5.9 | 4 h | 3 business days |
P2 matches the scoring band in the current support model; P1 and P3 are proposed.
Escalation ladder
A P1 reaches L2 at declaration. L3 is engaged if restore targets are at risk or a business decision is needed.
Communication rhythm
- First update within 15 minutes of declaration
- Every 30 minutes until restored, next update time stated
- One channel, one voice: the comms lead, in plain language
- Closure note with timeline; RCA within five business days
Roll back when
- The last release is inside the blast radius
- A rehearsed rollback exists, which it always does
- A fix cannot be validated within 30 minutes
Fix forward when
- The cause is external or configuration, not code
- Rollback would lose data or campaign changes
- A hotfix is tested and CAB-expedited
Either way
The decision is logged with owner, time and evidence. Recovery is verified with smoke tests and synthetic checks, integrations re-enabled one at a time, and confirmed with DCT before it is declared.
Incident drill: a campaign launch degrades the site
A simulated evening: 18:00 campaign launch, traffic climbs, a partner integration starts timing out. Watch the runbook execute, then make the T+60 decision yourself.
T+60 decision gate: roll back or fix forward?
- Cause: partner booking API timing out under load; our side healthy
- Last production release was two days ago and is outside the blast radius
- Containment in place: 6 instances, circuit breaker in degraded mode, campaign pages served from cache
- A tested configuration change (timeouts + retry budget) is ready and CAB can expedite
Incident record
Press Start drill. Time runs at one simulated minute per second.
Simulated data. The runbook steps, escalation ladder and communication rhythm are the ones proposed for the engagement.
AI in the lifecycle, with a person accountable at every stage
How AI is used today across requirements, design, development, testing, code review, security review and documentation, and the gates every change passes on its way to CAB.
Pull-request gates
Every AI-assisted change carries the same audit trail as any other: author, reviewer, pipeline run, CAB record.
| Stage | How AI is used today | Human oversight |
|---|---|---|
| Requirements | Drafts stories and acceptance criteria from briefs and data packs; classifies signals; summarises stakeholder input. | Business Analyst and Product Owner validate every story. |
| Solution design | Options analysis, architecture drafts, API contracts, threat-model prompts. | Solution Architect owns the decision; DCT technical owner signs off. |
| Development | Pair-programming assistant in the IDE for boilerplate, refactors and test scaffolds. | Engineer owns every commit; peer review before merge. |
| Testing and QA | Test cases from acceptance criteria; regression upkeep; synthetic data; the evaluation harness. | QA Lead designs the strategy and signs the release gate. |
| Code review | Automated first pass on every pull request. | Findings are advisory; approval is human. |
| Security review | SAST, secret scanning, dependency advisories, AI-triaged findings. | Technical Lead triages; DCT Security reviews each release. |
| Documentation | Runbooks, release notes, architecture docs and KT packs drafted from code and tickets. | Leads verify accuracy and add DCT context. |
Governance controls
- Approved services only, within DGE and DCT policy
- Data classified before any prompt; no PII, secrets, raw CRM or campaign strategy leaves the approved workspace
- AI change log for prompts, models and data sources, with DCT sign-off
- Human sign-off on every AI-touched deliverable
Evidence in production
- Ask Abu Dhabi: 75% fewer billable tokens per request, response time 24.6 s to 3.8 s
- 610 evaluation cases every release; 24 security findings closed; no production rollbacks
- Prompt caching above 90%; monthly technical health report on tokens, cost and latency