top of page

Yemen Telecom Operating Model Reset: Run vs Change, PMO Governance, and Decision Rights

  • Writer: Bridge Connect
    Bridge Connect
  • 4 hours ago
  • 3 min read

Why operating model becomes the hidden constraint

In recovery-to-growth environments, strategy is rarely the problem. Execution is. Most transformation efforts fail because the organisation tries to “transform” using the same structures that struggled to “operate.”

“Transformation fails when ‘run’ and ‘change’ share the same oxygen.”

For Yemen telecom leadership, an operating model reset is how you protect:

  • operational uptime (run),

  • delivery velocity (change),

  • financial control (governance),

  • and accountability (decision rights).


Executive summary (what to implement in 45–90 days)

  1. Separate Run vs Change explicitly—roles, time allocation, and escalation paths.

  2. Stand up a PMO with authority to prioritise, sequence, and stop work.

  3. Create decision rights that reduce meetings and increase speed.

  4. Deploy cross-functional delivery squads for the top transformation work packages (network, power, BSS, enterprise).

  5. Adopt a single delivery cadence: weekly portfolio review, monthly board update, and a standard set of KPIs.

“You don’t need more meetings. You need decision rights.”

The critical decision: What work gets priority when everything is “urgent”?

Post‑peace environments generate an infinite backlog:

  • restore sites,

  • rebuild transport,

  • modernise billing,

  • relaunch enterprise,

  • improve customer experience,

  • reduce costs,

  • fix procurement,

  • upgrade security.

If everything is urgent, nothing is delivered.

The CEO/COO must decide the portfolio logic:

  • which work protects stability now,

  • which work unlocks growth next,

  • and which work is deferred without regret.

“A PMO is only valuable if it can say ‘no’.”

Step 1 (Weeks 1–2): Define Run vs Change with real boundaries

“Run” and “Change” are not job titles; they are time commitments and responsibilities.


Run includes

  • day-to-day network operations and fault management

  • customer operations and incident communications

  • cash collection and revenue integrity controls

  • vendor delivery monitoring for continuity items


Change includes

  • restoration programmes (site clusters, transport rebuilds, power upgrades)

  • OSS/BSS modernisation and data cleanup

  • operating process redesign (complaints loop, procurement governance)

  • enterprise product and SLA relaunch


Non-negotiable boundary ruleRun leaders must have permission to reject change activity that threatens stability unless explicitly authorised by the COO/CTO.


Step 2 (Weeks 2–4): Establish a “thin but powerful” governance stack

Governance fails when it is either too heavy (slows delivery) or too light (no control).

A practical governance stack:

  1. Daily Ops Rhythm (Run): outage, power, spares, major incidents

  2. Weekly Portfolio Review (Change): progress, blockers, decisions needed

  3. Monthly Executive Steering: benefits tracking, scope changes, funding decisions

  4. Quarterly Board View: strategy alignment, risk, and investment sequencing


Each layer must have:

  • clear agenda,

  • decision rights,

  • and a standard dashboard.

“Governance is not paperwork. It is a decision factory.”

Step 3 (Weeks 3–6): Stand up a PMO that owns the portfolio, not the slide deck

In recovery-to-growth contexts, a PMO should be operational, not ceremonial.

PMO responsibilities that matter

  • maintain a single portfolio backlog (no shadow lists)

  • sequence work packages and manage dependencies

  • track delivery KPIs and benefits (not just completion)

  • manage escalation of blockers (procurement, access, data, approvals)

  • enforce standards: definition of done, acceptance criteria, and handover

PMO authorityIf the PMO cannot pause a project that is drifting, it is not a PMO. It is a reporting unit.

Step 4 (Weeks 4–10): Create delivery squads for the top work packages

Avoid structuring transformation by departments alone. Use cross-functional squads aligned to outcomes.

Example squads for Yemen telecom readiness

  • Network & Transport Squad: site clusters, backhaul stability, PoIs, redundancy

  • Energy & Resilience Squad: autonomy targets, site power upgrades, monitoring

  • Revenue & BSS Squad: billing integrity, product catalog cleanup, mediation

  • Customer Trust Squad: SLA publication, complaint loop, comms standards

  • Enterprise Squad: top accounts, SLA operating model, service delivery discipline

Each squad needs:

  • an accountable lead,

  • dedicated time allocation,

  • a weekly plan,

  • and a “definition of done.”

“Cross-functional squads turn politics into delivery.”

The operating KPIs (what executives should track weekly)

Keep it tight and action-driven:

Delivery health

  • on-time delivery rate for work packages

  • blocker aging (days blocked)

  • acceptance pass rate (quality)

  • dependency risk count (critical paths at risk)

Operational stability

  • major incident count/duration (ensure change is not increasing outages)

  • repeat outage rate on restored clusters

  • customer complaints trend (lagging indicator of operational disruption)

Financial discipline

  • capex spent vs plan by priority tier

  • procurement lead times for critical items

  • benefits realisation (e.g., autonomy hours gained, revenue leakage reduced)

“If delivery KPIs aren’t discussed alongside uptime KPIs, change will break run.”

Common failure modes (avoid these)

  • PMO with no authority (produces reporting, not outcomes)

  • Run leaders overloaded with change (stability collapses)

  • Departmental delivery (hand-offs create friction, accountability disappears)

  • No acceptance criteria (projects “finish” but don’t work in production)

  • Portfolio sprawl (too many initiatives, none delivered end-to-end)


What “good” looks like by Day 90

  • Run vs Change boundaries are explicit and enforced

  • PMO has a single portfolio and real prioritisation power

  • Squads deliver measurable outcomes (not activities)

  • Governance cadence produces decisions quickly

  • Uptime and delivery velocity improve together, not at each other’s expense

bottom of page