Date:
Author:
in2o Team
001
Technology is an enabler, and enablers come second
The Kingdom’s digital government direction is well defined, and entities have clear standards to work against. That clarity has a side effect: it becomes easy to treat the platform as the objective, because the platform is the part that can be procured.
A useful discipline is to write the sentence “this will be better for X because Y” before any technology is selected, and to keep it visible through delivery. Where that sentence cannot be written, the entity is buying a capability it has not yet found a use for — which is not necessarily wrong, but it should be an explicit decision rather than an accident of sequencing.
002
Readiness is data, process and people — usually in that order
Readiness is often assessed as a technical question and answered with an architecture diagram. In practice the constraint is more often the quality and ownership of the data, then the process that produces it, then the people expected to work differently once it changes.
A short, honest readiness review at the start — who owns this data, is it complete enough to act on, does the current process depend on a workaround, and who will have to change what they do — reorders most roadmaps. It also gives the programme something to fix in parallel, rather than discovering it at integration.
003
Sequence for dependency, not for visibility
Roadmaps are frequently ordered by what will be most visible, because visible progress protects funding. The cost is that dependencies are discovered late, and the visible thing has to be rebuilt.
Ordering by dependency looks slower at the start and is usually faster overall. Where visibility genuinely matters — and in a multi-year programme it does — the answer is to schedule a small, real, complete piece of the service early, rather than a large partial one. One journey working end to end teaches more, and demonstrates more, than four journeys half-built.
004
Plan for the second year
Most transformation plans are detailed for year one and thin for the years after — which is when adoption, support and iteration actually determine whether the investment returns anything.
Budgeting for the second year at the outset — for the changes users will ask for, the training that follows the first wave of real use, and the operating team that will own the service after the programme closes — is the difference between a launched system and a working one. The launch is the beginning of the work, not the end of it.
