Vision 2030 set technology ambitions on a scale most countries never attempt, and the hard part was never the ambition. It is the distance between a mandate approved in a boardroom and a system running in production with real users on it. That distance is engineering, and it is where most programmes stall. Below: why large programmes struggle everywhere, what carries one across, a four-question test, a worked example, and the traps we see most.
The strategy is clear and the money is real. PwC projects that AI alone will contribute about $135bn to Saudi Arabia’s economy by 2030, the largest gain in the Middle East (PwC, via US ITA). And where the engineering has been done, the results are visible: Saudi Arabia jumped 25 places to 6th globally on the UN E-Government Development Index 2024 (UN EGDI via Arab News, 2024). That ranking was earned by services like Sehhaty that people use every day, not by strategy documents.
Why big technology programmes struggle, everywhere, not just here
Start with the honest number. The most-cited study of large IT projects, by McKinsey and Oxford across more than 5,400 projects, found that large IT projects (initial budget over $15M) run on average 45% over budget, 7% over time, and deliver 56% less value than predicted, and 17% go so badly they threaten the company’s existence (McKinsey, 2012). Those are everyone’s numbers, and a national programme is a large IT project with a bigger audience.
A few patterns repeat no matter the country:
- Strategy doesn’t survive contact with reality on its own. It still has to be translated into an architecture, a sequence of decisions, and disciplined delivery. That translation is where programmes lose their way.
- Scale amplifies every mistake. At giga-project scale, one poor early architecture call or one wrong vendor doesn’t cost thousands. It costs millions and years, because everything built afterwards sits on top of it. We covered this in the technology lessons from building at giga-project scale.
- The slide-deck trap. Too much technology work stops at strategy, roadmaps, and operating models, and never becomes a shipped, maintained system. Decks don’t run anything.
The bridge: what carries ambition into production
Picture a bridge. Boardroom ambition is on one side, a running system on the other, and the structure that carries you across is engineering discipline. Skip a span and you produce a deck.
flowchart LR A(["Boardroom ambition"]) --> B(["Independent, accountable decision"]) B --> C(["Sound architecture, honest risk"]) C --> D(["Incremental build, real ownership"]) D --> E(["A shipped, maintained system"]) A -.->|stops at strategy| F(["A deck that runs nothing"])
Each span is checkable:
- Independent, accountable advice. Vendor-neutral guidance from people who will stand behind the result, not resellers steering you toward what they sell. This is the core of our technology assessment and digital transformation work: the advice is not tied to a product.
- No lossy hand-off. The best partners advise and build, so nothing is lost handing a thick document to a partner network that was not in the room.
- Discipline at scale. Sound architecture, honest risk registers that name the ugly dependencies, delivery in slices that go live, and a named owner for the outcome.
- Local capability. Vision 2030 is about lasting national capability, not permanent dependence on outsiders. Pair Saudi engineers with the delivery team from day one.
The slide-deck test: four questions to ask any programme
Four questions, asked in order, tell you whether a programme will ship without reading a line of architecture. If any answer is a committee, a study, or a vendor, you have found the weak span.
flowchart TD
A(["Any Vision 2030 technology programme"]) --> Q1{"Who owns it in production?"}
Q1 -->|a named team and a named director| Q2{"What goes live in the first 90 days?"}
Q2 -->|one real service, real users| Q3{"Who runs it after the consultants leave?"}
Q3 -->|Saudi staff trained inside the build| Q4{"Who profits from the vendor choice?"}
Q4 -->|nobody who advised you| S(["It will ship"])
Q1 -.->|a steering committee| D(["It will present"])
Q2 -.->|a phase-one study| D
Q4 -.->|the advisor| D
- Who owns it in production? Not who sponsors it. Who gets the call at 2am when it is down. If the answer is a steering committee, nobody owns it.
- What goes live in the first 90 days? The first slice can be small. It cannot be a document.
- Who runs it after the consultants leave? If the answer is “the vendor, under a support contract,” you have bought dependence, not capability.
- Who profits from the vendor choice? If the people advising you also resell what they recommended, the advice is not independent, whatever the slide says.
A worked example: one licensing service, two ways to build it
The numbers here are made up to show the shape. Say a government entity licenses businesses in one sector and handles 40,000 applications a year. Each application touches six back-office systems, takes an average of 12 working days from submission to decision, and a quarter bounce back for missing documents.
The big-bang plan: an 18-month programme replaces all six systems with one platform. A vendor is chosen on Etimad, design takes six months, integration the next nine, and nothing goes live until month 18. If integration runs late, which the McKinsey and Oxford figures above say is the default, month 18 becomes month 26, with no improvement anyone can point to.
The thin-slice plan: pick one licence type, say the one with 3,000 applications a year and the worst bounce-back rate. In 90 days, ship a digital application that validates documents up front, connects through an API to the one back-office system that matters most, and leaves the other five alone. Measure three things from day one: days to decision, bounce-back rate, and officer hours per application. Say days to decision drop from 12 to 5 and bounce-backs fall from 25% to 8%. Now you have a real number, a real service, and a team that has shipped once. By month 18 most of the six are connected, and the programme learnt what integration actually costs before committing the whole budget to it.
The lesson is not the numbers. The second plan produces evidence at month three; the first produces a status report.
Where Vision 2030 programmes go wrong
The failures we see are rarely technical. They are decisions that looked reasonable at the time.
- The advisor is the vendor. The firm that wrote the strategy also sells the platform in it. The recommendation was never going to be “you don’t need it.”
- Integration is “phase two.” The new platform is live, but it is fed by spreadsheets exported from the old systems every night. The real work has not started.
- Compliance is bolted on at the end. PDPL, NCA’s Essential Cybersecurity Controls, and data residency are treated as a sign-off before launch instead of a design input. Retrofitting where data is allowed to live is a rebuild, not a patch.
- The sandbox becomes a home. SAMA’s Regulatory Sandbox has been running since 2018 and has admitted dozens of fintechs to test under supervision before full authorisation (SAMA). Its purpose is a path to production. A pilot that never leaves supervised conditions has not shipped.
- Lowest price on the tender, highest price over the life of the contract. The cheapest bid to sign is often the most expensive to leave. Exit terms, data ownership, and documented interfaces belong in the RFP, not the renegotiation.
Most of these show up long before the deadline slips; the real reasons software projects fail are visible in the first quarter.
How to start: one service, measured, shipped, then scaled
The pattern that works is boring and reliable, whether you are a ministry, a giga-project developer, or a family group modernising its core. Pick one service that matters and that people use often. Measure what it costs today, honestly: days, hours, error rate, complaints. Get independent advice on the architecture and the vendor choice before the tender goes out, not after. Ship a thin slice to real users inside a quarter, with the Saudi team that will own it inside the build. Measure again. If it moved, scale to the next slice. If it did not, you have spent a little to learn something cheap, instead of betting a national budget on a slide deck. Some of the best examples are in digital transformation in the Saudi public sector, and they are worth studying whichever sector you are in.
Vision 2030’s technology ambitions are achievable. What separates the services that ship from the programmes that stall is not more ambition. It is the engineering discipline to turn strategy into systems, independence in the decisions, and accountability for the result.
Working on a Vision 2030 programme that can’t afford to get technology wrong? SDCG advises and builds: independent, accountable, and aligned to Vision 2030, taking you from the boardroom decision all the way to the system that ships. Book a free 30-minute review.