Finance transformation has sat at the top of the CFO agenda for three consecutive years. According to Gartner’s Evanta CFO community research, “executing finance transformation” has been the number one priority among finance chiefs for the third year running heading into 2026, with AI and automation in finance climbing to number two. The investment is real, the mandates are serious, and the urgency is genuine across Egypt, Saudi Arabia, the UAE, and the broader GCC.
The outcomes are not keeping pace.
Only 48 percent of digital initiatives enterprise-wide meet or exceed their business outcome targets, according to Gartner’s 2025 CIO survey covering more than 3,100 technology executives across 88 countries. The RAND Corporation documented that 80.3 percent of all enterprise AI projects fail to deliver their promised business value. Research from BCG and McKinsey consistently reports that approximately 70 percent of digital transformation programmes fail to achieve their stated objectives.
In the GCC and Egypt, these global failure rates are not lower — the regional evidence suggests they may be higher, for specific and addressable reasons that are not widely discussed honestly.
This guide is an attempt at that honest discussion. It is written by a specialist consultancy that has conducted project assessments, rescue engagements, and independent advisory for organisations across the Arab world. What follows reflects what we have seen in practice — not what the organisations involved chose to publicise.
The goal is not to catalogue failure for its own sake. It is to give CFOs, CIOs, and boards the pattern recognition to identify failure risk before it is too late to address it affordably, and to understand what recovery actually looks like when the risk has already materialised.
Why This Guide Is Different From What Vendors and Large Firms Publish
Most of the literature on technology project failure is produced by one of three parties: the vendors whose products were involved, the consulting firms whose practitioners delivered the project, or the industry analysts whose research is funded by vendors. None of these parties has a commercial interest in producing an honest account of how and why their own engagements failed.
The pattern that results is predictable. Failure is attributed to “change management challenges,” “insufficient executive sponsorship,” or “data quality issues” — descriptions that are technically accurate and practically useless, because they identify the symptom without identifying whose decisions created it or what should have been done differently.
What CFOs and CIOs in the GCC and Egypt need to make better decisions going into their next transformation investment is a specific, causally accurate account of how projects fail in this specific regional context — and what the corrective action looks like for each failure mode.
That is what this guide provides.
The Scale of the Problem in the GCC and Egypt in 2026
Vision 2030 Phase 3, formally launched in 2026, has been described as a phase of “accelerated implementation” — characterised by narrower scope, harder delivery gates, and more commercial discipline. Of 1,290 Vision 2030 initiatives tracked by the Saudi Performance Measurement Centre (Adaa), 130 have been flagged for re-scoping or restructuring as of the 2025 annual report. That is not a failure rate; it is the formal acknowledgement that a significant proportion of ambitious programmes require correction when delivery reality meets planning ambition.
At the enterprise level, the pattern is similar. The Saudi Arabia management consulting market reached USD 3.98 billion in 2025. Organisations across the Kingdom and the UAE are spending at scale on technology and transformation. The firms delivering these programmes — Big Four practices, global system integrators, regional consulting firms — are doing so at volumes that make consistent quality difficult to maintain.
The GCC management consulting services market sits at USD 6.83 billion and is growing. Demand is real and accelerating. So is the gap between what is being promised and what is being delivered.
For CFOs and CIOs navigating this environment, the ability to diagnose risk before a project starts — and to recognise failure early enough to recover rather than simply absorb the cost — is a material operational capability.
The Ten Root Causes of Finance and Technology Project Failure in the GCC and Egypt
These are not theoretical categories. They are the causes that appear, with consistent frequency, in the projects that Loop Wise Solutions has been asked to assess, rescue, or advise on across the region.
Root Cause 1: Requirements Were Defined After the Vendor Was Selected
The single most consistent cause of finance and technology project failure in the GCC is the sequence error: a vendor or platform is selected before the organisation’s requirements are clearly defined.
The procurement process produces its own momentum. A vendor demonstrates a system. The demonstration is impressive. The evaluation committee is persuaded. A proposal is issued, commercial negotiation happens, a contract is signed. Requirements are then gathered during the implementation kick-off — or defined by the implementation team based on their standard templates for “organisations like yours.”
The result is a system configured for a vendor’s reference model rather than the organisation’s actual processes. The EPM system that does not match how the finance team plans. The ERP that handles 70 percent of the business processes and requires customisation for the 30 percent that matter most. The BI environment that shows what the data contains rather than what the leadership team needs to decide.
The fix is structural: complete requirements definition independently before any vendor demonstration. Requirements defined before the vendor engagement are constrained by the business; requirements defined after it are constrained by the vendor’s system.
Root Cause 2: The Business Case Was Built From Vendor Benchmarks Rather Than Organisational Data
The investment justification for most large technology projects in the GCC is built from benchmarks: “organisations implementing Oracle EPM reduce their close cycle by 30 to 40 percent,” “AI-enabled AP automation reduces processing cost by 70 percent.” These figures appear in vendor sales materials and in consulting firm proposals whose implementation practices have a commercial interest in the programme being approved.
When the board approves an investment on the basis of benchmark ROI and the actual performance falls significantly short, the investment is labelled a disappointment. In most cases, the actual performance was achievable — the benchmark was not wrong — but the specific conditions that produce the benchmark outcome were not present in this organisation, and nobody assessed them before the business case was submitted.
A credible business case for a technology investment in the GCC is built from the organisation’s own operational data: the actual close cycle duration and its actual cost, the actual cost per invoice processed, the actual finance team hours consumed by the processes being replaced. The improvement case is modelled against the specific implementation scope and the organisation’s assessed readiness — not against what is theoretically achievable in a best-case implementation.
Root Cause 3: The Delivery Team Was Junior-Heavy Against a Complex Requirement
This cause is the least discussed in the region and arguably the most consequential. The consulting and implementation firms operating in the GCC — from Big Four practices to regional integrators — operate on leverage models that deploy senior practitioners to win and design engagements and junior consultants to deliver them.
The configuration decisions that determine whether an Oracle EPM implementation correctly reflects how the business plans, whether an ERP integration correctly maps the chart of accounts, or whether an AI automation programme correctly handles the exception logic of an Arabic-language invoice workflow are made by consultants in the build phase. When those consultants have two to four years of platform experience, they make decisions that an experienced senior practitioner would make differently — and the gap between those decisions accumulates into a system that is technically operational and functionally wrong.
The test is direct: ask any implementation firm, before signing, what percentage of billable implementation hours on your project will be delivered by consultants with five or more years of direct experience in this specific platform and domain. In our experience across the region, the honest answer to this question changes the engagement decision in a significant proportion of cases.
Root Cause 4: Arabic-Language and Regional Requirements Were Treated as Scope Additions
For GCC and Egyptian enterprises, the requirements for Arabic-language system operation, ZATCA Phase 2 compliance, UAE corporate tax configuration, ETA integration in Egypt, Hijri calendar support for Saudi regulatory reporting, and PDPL-aligned data architecture are core requirements — not optional features. They determine whether the system is usable by the people it was built for, and whether it meets the regulatory obligations under which the organisation operates.
Most technology implementation proposals produced by firms without deep GCC delivery experience describe these requirements as additional scope, Phase 2 items, or optional configurations. They are not. Including them in the original scope is cheaper than retrofitting them after go-live. Deferring them creates an adoption gap that finance teams bridge through manual workarounds — workarounds that become permanent when the Phase 2 project never arrives.
Root Cause 5: The Implementation Ended at Go-Live
Go-live is presented as a project milestone in every implementation plan we have seen. In practice, go-live is the beginning of the period when the project’s success is determined — not its end.
The six to twelve months after go-live are when the finance team runs their first live planning cycle, manages their first close on the new system, and encounters the scenarios that did not appear in the test scripts. It is when the questions that were not answered in training arise, when the integration issues that were masked by test data volumes appear under production loads, and when the adoption pattern is set — whether users embrace the system or route around it.
An implementation that closes the project at go-live, hands over a support ticket queue, and moves the delivery team to the next engagement is an implementation that leaves the adoption decision to chance. The organisations that achieve the highest post-implementation adoption are those where the delivery team remains available — for the first live cycle, for the questions that arise in production, for the calibration adjustments that production conditions reveal.
Root Cause 6: Organisational Readiness Was Assumed Rather Than Assessed
Every technology implementation depends on four readiness factors: data quality in source systems, process documentation maturity, team capacity to participate alongside operational responsibilities, and active leadership commitment. When any of these is absent, the implementation encounters the gap as a project risk — at the point when addressing it is most expensive.
Data quality issues discovered during integration testing extend the project by weeks. Process gaps discovered during UAT generate change requests that add cost. Team members who cannot participate in design and testing because their operational workload does not allow it produce a system configured against assumptions rather than validated requirements. Leadership disengagement allows scope, budget, and quality decisions to be made without the authority needed to enforce the right outcome.
All four of these factors are assessable before the project begins. An implementation readiness assessment is not a formality — it is the mechanism by which expensive mid-project discoveries are made affordable pre-project corrections.
Root Cause 7: The Integration Layer Was Never Properly Governed
In almost every multi-system technology programme we assess in the GCC — ERP connected to EPM, EPM connected to BI, AP automation connected to ERP — the integration layer is the source of the most persistent operational problems. Data arrives from one system to another with incorrect account mapping, inconsistent currency translation, missing intercompany transaction flags, or entity hierarchy translations that were correct at implementation and wrong after the first organisational restructuring.
Integration failures are insidious because they often do not announce themselves clearly. The system does not error; it loads data that is plausible but wrong. The finance team discovers the discrepancy during close, applies a manual correction, and absorbs the integration error as a routine step. The manual correction becomes normalised. The integration is never fixed because the workaround has made the problem invisible.
Integration governance — documented transformation logic, automated exception alerting, a change management process for when source systems change — prevents this pattern. It is almost never included in implementation projects as a formal deliverable, which is why it is consistently the source of post-go-live operational problems.
Root Cause 8: The Wrong Firm Type Was Engaged for the Project’s Primary Risk
The match between project type and firm type determines whether the primary risk is managed or ignored. A project whose primary risk is scale and organisational change management across thousands of users benefits from a large firm’s capacity. A project whose primary risk is the accuracy of Oracle EPM configuration and the depth of Arabic-language finance requirements benefits from a specialist with senior practitioners throughout.
When a large firm is engaged for a project whose primary risk is configuration depth and regional knowledge — because the brand provides governance comfort or because the procurement process favoured the largest proposal — the project’s primary risk is addressed by the firm’s least experienced consultants, operating from a methodology template rather than from direct domain knowledge. The outcome is predictable.
The discipline required to choose the right firm type for the right project — not the most impressive firm or the most comfortable relationship — is one of the most valuable things a CFO or CIO can apply to a technology investment decision.
Root Cause 9: The Project Lacked a Clear, Measurable Success Criterion
An investment without a defined, measurable success criterion cannot be held accountable for its performance. When the business case is built on vendor benchmarks rather than organisational data, the success criterion is implicitly “the system went live” rather than “the close cycle reduced by X days” or “the finance team hours consumed by manual processes reduced by Y percent.”
Without a specific measurement, the gap between expected and actual performance is not formally identified. Finance team workarounds are treated as normal post-implementation behaviour. The system is described as “live” when it is in reality functioning at a fraction of its intended capability. Nobody escalates, because there is no defined threshold for escalation.
Define the success criteria before the project starts. Specify the measurable outcomes — the close cycle duration at six months post-go-live, the automation rate for specific processes at three months, the proportion of management reporting produced directly from the system without manual adjustment at twelve months. These criteria make the project accountable and make the recovery conversation possible before the gap becomes permanent.
Root Cause 10: AI and Technology Were Treated as the Solution Rather Than the Enabler
The 2026 AI failure statistics are specific and alarming: 80.3 percent of enterprise AI projects deliver no business value; 88 percent of AI agent pilots never reach production; 95 percent of GenAI pilots showed no measurable financial returns within six months. AI adoption across the GCC has reached 84 percent by some measures — yet fewer than one in three GCC organisations have the operating model and formal governance needed to scale it.
The pattern that produces this outcome is consistent: organisations invest in AI capability — tools, models, agents — without first establishing the data foundation, process design, and governance architecture that AI depends on. The data quality is insufficient for the AI to produce reliable outputs. The processes the AI is automating were not understood well enough to be automated correctly. The governance model for managing AI outputs, exceptions, and changes was not designed before the AI was deployed.
AI is an enabler of better processes on a clean data foundation with clear governance. It is not a substitute for any of those three things.
The Warning Signs That Appear Before a Project Fails
The following signals, visible during a project’s execution, indicate that failure is developing — and that intervention is still more affordable than recovery.
| Warning Signal | Stage It Appears | What It Indicates |
|---|---|---|
| Requirements still being gathered during the build phase | Build | Requirements definition was not completed before configuration began |
| Change requests accumulating faster than they are resolved | Build / UAT | Scope was underestimated; original requirements were insufficient |
| Finance team not participating in design workshops | Design | Capacity was not assessed; operational workload is crowding out the project |
| Integration testing producing systematic variances with no clear root cause | Integration testing | Integration mapping was not validated at the business logic level |
| UAT scripts producing consistently unexpected outputs | UAT | System was configured against assumptions rather than validated requirements |
| Executive sponsor attending steering committees but not making scope or budget decisions | Throughout | Leadership commitment is nominal rather than active |
| Delivery team personnel changing without formal handover | Throughout | Junior-heavy model; original knowledge is not being transferred |
| Arabic-language requirements appearing as UAT defects | UAT | Arabic-language scope was not included in the original requirements |
| Go-live date being held constant as scope is reduced to meet it | Approaching go-live | Timeline is being protected at the cost of delivery quality |
| Post-go-live support plan describing a helpdesk, not a delivery team | Go-live | Implementation partner is closing the project at go-live |
What Recovery Actually Looks Like: The Honest Assessment
When a finance or technology project has failed — or is failing — the organisation faces three options: absorb the cost and close the project, attempt to recover the project internally, or engage an independent firm to assess and rescue it.
The first option is chosen more often than it should be, because the political cost of acknowledging failure prevents an honest assessment of whether recovery is achievable. Closing a failing project is not always wrong — sometimes the architecture is fundamentally incorrect and the most efficient path is a fresh start. But in the majority of cases across the GCC and Egypt that we have assessed, the failing project had specific, correctable problems rather than fundamental architectural errors.
The second option — internal recovery — works when the internal team has the capability to diagnose the problems accurately and the authority to implement the corrections. In most cases, the internal team was part of the original project and carries assumptions about what is and is not fixable that an independent assessment would challenge.
The third option — independent assessment and recovery — is the most reliable path to an honest diagnosis. An independent firm with no commercial relationship to the original implementation partner or vendor can assess what went wrong without the constraints that those relationships impose.
What Independent Recovery Assessment Covers
A properly structured recovery assessment covers four areas in sequence.
Current state of the system: What is technically in place, what is in use, and what the gap is between the two. EPM configurations that were built but not validated. Integrations that were delivered but not tested against production data volumes. Arabic-language requirements that were configured but not adopted by the finance team.
Root cause analysis: Which of the failure modes described in this guide are present, in what combination, and with what relative impact. The root cause is rarely one thing; it is usually a combination of two or three factors whose interaction created the outcome.
Remediation options: For each identified problem, the options for correction — reconfigure, rebuild, or replace — with the effort, cost, and timeline for each. Most problems are cheaper to remediate than to replace. Some are not.
Recovery plan: A sequenced, costed, and milestone-defined plan for closing the gap between the current state and the functioning system the organisation invested in. Not a project plan for starting over — a recovery plan for closing specific gaps.
The assessment itself — independent of any subsequent recovery work — is the most valuable thing an organisation with a failing project can commission. It converts a situation of political ambiguity and escalating cost into a specific problem with a specific solution and a specific price.
The GCC-Specific Failure Amplifiers
Several factors specific to the GCC and Egypt amplify the impact of the generic failure modes described above. Understanding them does not change the root causes, but it explains why the same project problems produce larger consequences in the regional context than they might elsewhere.
The Vendor Relationship Complexity
In the GCC, the vendor relationship — with Oracle, SAP, Microsoft, or a large consulting firm — is often a multi-dimensional relationship that extends across the organisation. The same Big Four firm may be the organisation’s auditor, its tax advisor, its regulatory compliance counsel, and its ERP implementation partner. The political cost of formally acknowledging that the implementation has failed is compounded by the risk that the acknowledgement damages relationships that extend beyond the project.
This dynamic creates a specific incentive to avoid the honest escalation that would trigger a recovery conversation. The project drifts. The finance team builds workarounds. The CFO commissions a “lessons learned” exercise that identifies generic categories of challenge without addressing the specific failures that require correction.
Independent assessment by a firm with no existing relationship with the vendors or implementation partners involved is the mechanism that breaks this cycle. The assessment’s conclusions are not constrained by relationship preservation.
The Arabic-Language Gap
A technology system that does not support Arabic-language operation is a system that the majority of the finance team in most GCC and Egyptian enterprises will not fully adopt. The adoption consequence of missing Arabic-language configuration is larger in the GCC than in most other markets because the proportion of the workforce whose primary working language is Arabic is larger — and because the cultural expectation that systems serve users in their working language, rather than requiring users to adapt to the system’s language, is more firmly established.
The financial consequence of low adoption — the system is paid for, maintained, and licensed but produces its output through a parallel manual process — is the same as not implementing the system at all, with the additional cost of the implementation investment already spent.
The Regulatory Complexity Multiplier
ZATCA Phase 2 in Saudi Arabia, the UAE corporate tax framework, the ETA mandate in Egypt, PDPL data governance requirements, and IFRS 18 adoption all create compliance obligations that intersect with technology implementations in ways that implementation teams without specific regional experience underestimate. When a technology project fails to account for these obligations — either by omitting them from the original scope or by misunderstanding their technical implications — the compliance gap that results is not just an operational problem. It is a regulatory risk that the board and audit committee are accountable for.
An independent assessment that explicitly validates the compliance status of the technology environment — confirming that ZATCA integration is production-tested, that Arabic regulatory reporting is correctly configured, that PDPL data residency requirements are met — provides the documented basis for regulatory confidence that a go-live report from the implementation partner cannot provide.
A Pre-Project Checklist for CFOs and CIOs
Before committing budget to the next technology or transformation programme, the following questions deserve specific answers.
On requirements: “Have we defined our requirements independently — before any vendor demonstration or partner proposal — at the level of specificity that a system can be configured against?” A requirements document that describes outcomes (“the system should support driver-based forecasting”) rather than process detail (“the system must accommodate these specific allocation rules for these specific cost categories against these specific entities”) is not a requirements document.
On the business case: “Is this business case built from our own operational data — our actual close cycle duration, our actual cost per invoice, our actual finance team hours — or from vendor benchmark statistics?” If vendor benchmarks are the primary ROI source, the business case needs to be rebuilt from organisational data before board approval.
On the delivery team: “Who specifically will deliver this project — not who will manage it or present at our steering committee, but who will attend the design workshops, make the configuration decisions, and be available during UAT?” Require CVs and verify them. Ask what percentage of billable hours will be delivered by consultants with five or more years of relevant domain experience.
On regional requirements: “Are Arabic-language configuration, ZATCA compliance, UAE corporate tax, PDPL data architecture, Hijri calendar, and ETA integration explicitly named deliverables in the statement of work — or are they described as ‘available features’ that will be addressed as needed?” The difference between an explicit scoped deliverable and an available feature is the difference between being delivered and being deferred.
On readiness: “Have we assessed our data quality, process documentation maturity, team capacity, and leadership commitment — against the specific requirements of this programme — before this project was scoped?” If the readiness assessment was done by the implementation partner as part of their sales process, it was not an independent readiness assessment.
On success criteria: “What are the specific, measurable outcomes this investment is committed to delivering — with timeline targets and defined escalation triggers if the targets are not met?” Success criteria defined as “the system goes live” are not success criteria.
Frequently Asked Questions
Q: What is the failure rate for finance and technology transformation projects in the GCC? The global failure rate for digital transformation programmes is approximately 70 percent not meeting their stated objectives, according to consistent research from BCG and McKinsey. Only 48 percent of digital initiatives enterprise-wide meet or exceed their business outcome targets, according to Gartner’s 2025 CIO survey. In the GCC and Egypt, several regional factors — the Arabic-language requirements gap, regulatory complexity (ZATCA, UAE CT, ETA, PDPL), the shortage of senior practitioners with genuine regional delivery experience, and the political dynamics of vendor relationships in a relationship-based business culture — suggest these failure rates are not lower than the global benchmarks and may be higher for specific technology categories.
Q: What are the most common reasons ERP and EPM implementations fail in Saudi Arabia and the UAE? The four causes that appear with the highest frequency in the GCC project failures we assess are: requirements definition that happened during or after vendor selection rather than before it; business cases built from vendor benchmarks that were not achievable in the specific organisational context; delivery teams whose junior-to-senior ratio was not matched to the complexity of the engagement; and Arabic-language and regional compliance requirements (ZATCA, UAE CT, Hijri calendar) that were treated as scope additions rather than core deliverables. These four causes frequently appear together — a project that selected its vendor before defining its requirements is also likely to have used vendor benchmark ROI and to have received the implementation firm’s standard delivery team rather than the senior practitioners who won the engagement.
Q: How do we know if our current technology project is at risk of failing? Specific warning signals include: requirements that are still being gathered during the build phase; change requests accumulating faster than they are resolved; the executive sponsor attending but not making decisions at steering committees; the delivery team changing personnel without formal knowledge transfer; Arabic-language requirements appearing as UAT defects rather than as scoped deliverables; and the go-live date being protected by reducing scope rather than extending timeline. Any three of these signals appearing simultaneously in an active project indicate that independent assessment is warranted before the project reaches go-live — when the cost of correction is still manageable.
Q: What should we do when a technology or transformation project has already failed or stalled? The most reliable first step is an independent assessment — conducted by a firm with no commercial relationship to the original implementation partner, vendor, or consulting firm. The assessment diagnoses what specifically went wrong, what the correctable problems are, what the irrecoverable elements are, and what a realistic recovery plan looks like in terms of scope, cost, and timeline. The output is a specific, evidence-based decision: recover the existing implementation, rebuild specific components, or restart with a different scope or partner. The assessment itself — which typically takes three to five weeks and costs USD 15,000–35,000 — converts an ambiguous failure situation into a specific problem with a specific solution, before additional budget is committed to either recovery or replacement.
Q: How do we build a business case for a technology investment that will survive board scrutiny in the GCC? A business case that survives board scrutiny from a Gulf family conglomerate principal, a sovereign fund counterparty, or a listed company audit committee is built from four specific components: a current-state cost baseline measured from the organisation’s own operational data; an improvement case modelled from the specific, contractually committable implementation scope and the organisation’s assessed readiness; a total cost of ownership that includes Arabic-language configuration, regional compliance setup, post-go-live support, and ongoing maintenance alongside the implementation fee and licence cost; and an explicit readiness assessment confirming that the data quality, process maturity, and team capacity required for the modelled improvement are present before the project begins. A business case missing any of these components is a business case built on assumptions — and assumptions that are not stress-tested by the CFO before board approval will be stress-tested by the delivery reality after it.
Q: Should we use an independent advisory firm or let the implementation partner advise us? The implementation partner’s advice on implementation risk, scope, and approach is structurally influenced by their commercial interest in the project being approved and their preferred delivery methodology being adopted. This does not mean their advice is wrong — it means it is not independent. An independent advisory firm with no commercial arrangement with the vendor or the implementation partner produces advice constrained only by the organisation’s requirements and an honest assessment of what the available options can deliver. The cost of independent advisory — typically USD 15,000–70,000 depending on scope — is consistently recovered from the implementation budget through more accurate scoping, better vendor evaluation, and the identification of readiness gaps that would otherwise become expensive mid-project corrections.
About Loop Wise Solutions
Loop Wise Solutions is an enterprise performance consultancy based in Cairo, serving medium and large enterprises across Egypt, Saudi Arabia, the UAE, Qatar, and the broader Arab world. Our Business and Technical Consultancy practice provides independent project assessment and recovery advisory — with no commercial arrangement with Oracle, SAP, Microsoft, or any implementation partner.
We have assessed and recovered technology programmes across Oracle EPM, ERP, BI, and intelligent automation for organisations in the region — and the pattern recognition in this guide reflects what we have consistently found in those engagements. We are direct about what went wrong, specific about what can be fixed, and honest about what cannot.
If your organisation is in the planning phase of a major technology investment, or is managing a programme that is not performing as expected, we are happy to have a direct and honest conversation — starting with your situation, not with our service offering.
Contact: contact@loop-wise.com | Website: www.loop-wise.com
Where performance meets precision.
