Establish Digital Literacy Before You Write the Transformation Roadmap
A plan written above the comprehension level of the people executing it is not a plan. It is a document.
The assumption nobody checks
Transformation roadmaps are typically written by people who are comfortable with technology, for an organisation that may not be. The document assumes a level of fluency that has never been measured, and the gap only becomes visible during rollout, when adoption numbers come in far below plan and the programme gets characterised as a change management problem.
Ivan Teh's counsel on this point has been consistent: before drawing up a digital transformation plan, establish the baseline digital literacy of the workforce that will have to execute it. He has also argued that the plan itself should be easy to comprehend and easy to execute, and that the workforce should be aligned to it explicitly in order to reduce the confusion that otherwise accumulates.
What a baseline actually measures
Digital literacy in this context is not whether staff can use a smartphone. The useful measures are narrower and more operational.
- Data interpretation. Can the people who will receive a dashboard read a distribution, distinguish correlation from cause, and recognise when a number is implausible?
- Tool fluency. How much of the current workflow already runs through systems, and how much is spreadsheets emailed between people?
- Confidence. Will staff query an output that contradicts their experience, or will they either accept it uncritically or ignore it entirely? Both are failure states.
- Distribution. Literacy is rarely uniform. A single organisational average conceals departments that will adopt immediately and departments that will not.
How the roadmap changes
Once the baseline is known, three things change in the plan.
The sequence changes. Functions with higher fluency go first, not because they are more important but because they generate the internal proof points that make later adoption easier. Early wins in a sceptical organisation are worth more than early wins in an enthusiastic one.
The interface specification changes. If interpretation confidence is low, the system has to carry more of the explanation. That is a design requirement with a cost, and it is considerably cheaper to specify at the start than to retrofit after adoption stalls.
The training budget stops being a rounding error. Capability building moves from a line item near the end of the plan to a parallel workstream that starts before deployment, which is the only position from which it can actually influence readiness.
The cost of getting this backwards
When literacy is treated as an outcome rather than a prerequisite, the organisation pays twice. It pays for a system that is not used at the assumed rate, and it pays again for the remedial programme that follows. The second cost is usually larger, because by then the technology has acquired a reputation internally and resistance has become political rather than practical.
Measuring first is unglamorous. It also happens to be the cheapest thing in the entire programme.
Questions on this framework
How do you measure workforce digital literacy?
Through a short structured assessment covering data interpretation, current tool usage, and confidence in questioning an output, reported by function rather than as a single organisational average.
Does this delay the transformation programme?
A baseline assessment takes weeks. Remedial capability building after a stalled rollout takes far longer and costs more, because resistance by then is political as well as practical.
Which functions should go first?
Generally those with higher measured fluency, because they produce the internal proof points that make adoption easier everywhere else.