MODULE 2 OF 6 · FOUNDATIONS

Context and Drivers

30 min read 4 outcomes PESTEL explorer 3 knowledge checks

By the end of this module you will be able to:

  • Apply the PESTEL framework to map external drivers of digitalisation with UK-specific examples
  • Explain how COVID-19 compressed digital adoption timelines using named organisational data
  • Identify and rank the principal barriers to digitalisation and explain their organisational roots
  • Conduct a structured context assessment for a specific organisation using the PESTEL lens
driver map: Why is this change needed now?

NHS Digital Triage

How COVID-19 forced the NHS to digitalise in weeks

Before March 2020, fewer than 1% of GP consultations in England were conducted by video. By May 2020, more than 71% of consultations were remote - telephone or video - and the NHS 111 online triage tool was handling 250,000 enquiries per day at peak. The systems, the clinical pathways, and the regulatory permissions that made this possible had existed for years. What changed was the external context: the cost of not digitalising became unbearable overnight.

NHS England relaxed information governance requirements that had previously made video consultations administratively burdensome. GP software vendors activated video modules that had sat unused. Clinicians who had resisted remote consulting for a decade adopted it within days because the alternative was no consulting at all. The technology was not new. The drivers were.

This module uses the NHS case as a lens for the analytical framework at the heart of the module: PESTEL. The external context - political permission, economic necessity, social anxiety, and technological readiness - did not create new digital capability. It changed the cost-benefit calculation so decisively that change became unavoidable.

What organisational and technical factors allowed the NHS to scale digital triage so rapidly?

With the learning outcomes established, this module begins by examining pestel drivers of digitalisation in depth.

2.1 PESTEL drivers of digitalisation

PESTEL (Political, Economic, Social, Technological, Environmental, Legal) analysis provides a structured approach to mapping the external environment. Applied to digitalisation, it surfaces the forces that create pressure, incentive, or obligation to change - and the constraints that must be designed around. No digitalisation programme operates in a vacuum: it operates inside a specific context that determines what is possible, what is necessary, and what is risky.

The DCMS UK Digital Strategy of 2022 represents a political driver: government commitment to digital infrastructure, skills investment of £2.5 billion, and public-sector procurement preferences that reward digital suppliers. The UK digital economy, valued by DCMS at £151 billion and accounting for 6.7% of GVA, represents an economic driver - the opportunity cost of digital lagging relative to sector peers.

On the social dimension, ONS data shows 92% of UK adults were recent internet users in 2022 - up from 79% in 2011. Customer expectations have shifted accordingly. Organisations that cannot meet digital self-service expectations lose customers to digital-native competitors who built their models around those expectations from day one.

The UK digital economy now accounts for around 6.7% of total GVA and is growing at twice the rate of the wider economy. Digital investment is no longer a sector concern; it is a macroeconomic imperative.

DCMS (2022). UK Digital Strategy - Chapter 1: The Opportunity

The DCMS framing matters because it signals government as an active driver rather than a passive regulator. Procurement policy, skills investment, and regulatory sandboxes are political tools that directly change the economic case for digitalisation across both public and private sectors.

Drivers of digitalisation

Drivers of digitalisation. Drivers matter because they determine which outcomes and controls must be designed in.

PESTEL drivers of UK digitalisation, with the control set each one forces Six stacked rows, one per PESTEL category: Political, Economic, Sociocultural, Technological, Environmental, Legal. Each row carries the category letter on the left, the category name and a real UK driver in the middle, a CONTROL SET column naming the controls the driver forces into scope, and a source citation on the right. The Environmental row is emphasised because the 2026 Energy Digitalisation Framework is the most current binding driver. PESTEL DRIVERS OF UK DIGITALISATION P Political GOV.UK Service Standard for cross-government services CONTROL SET Service-assessment evidence pack GOV.UK SM E Economic Made Smarter review: digital adoption tied to productivity CONTROL SET Unit-economics model, ROI gates DBT 2025 S Sociocultural NHS App expectations: 30 million users by 2024 CONTROL SET User research, accessibility audit NHS Digital T Technological Open standards for APIs, identity, and data CONTROL SET Architecture board, API catalogue OpenAPI 3.1, OIDC E Environmental Net-zero reporting and Energy Digitalisation Framework CONTROL SET Telemetry, carbon dashboards EDF 2026 L Legal UK GDPR, Data Protection Act 2018, lawful basis CONTROL SET Records of processing, DPIA ICO built by ransfordsnotes.com

Drivers determine which controls must be designed in from day one. PESTEL keeps the analysis disciplined; the controls turn the driver into a delivery obligation. GOV.UK Service Manual, DESNZ + Ofgem (2026), DBT (2025).

Standards and reliable operation are delivery obligations

Standards and reliable operation are delivery obligations. Open standards and reliable operation are part of service quality, not optional polish.

GOV.UK Service Standard 13 and 14 as cross-government obligations Two side-by-side cards. The left card is Standard 13 with five obligations: choose open standards, reuse common components, publish APIs, contribute back, document deviations. The right card is Standard 14 with five obligations: define service levels, plan on-call, test recovery, monitor real users, run a learning loop. Each card carries an ASSESSMENT TOUCHPOINT band naming when the standard is checked. STANDARD 13 Use and contribute to openstandards, common components, andpatterns 1 Choose published open standards over proprietary 2 Reuse common platform components first 3 Publish your APIs to the GOV.UK API catalogue 4 Contribute fixes back to shared components 5 Document any approved deviation ASSESSMENT TOUCHPOINT Checked at alpha and beta STANDARD 14 Operate a reliable service 1 Define the service levels users can rely on 2 Plan on-call and incident response 3 Test recovery, not only backup 4 Monitor real user experience, not synthetic only 5 Run a learning loop on every incident ASSESSMENT TOUCHPOINT Checked at beta and live built by ransfordsnotes.com

Service Standards 13 and 14 are not polish at the end. Both are checked at alpha, beta, and live, so the evidence pack must update with the service. GOV.UK Service Manual.

PESTEL maps the drivers in aggregate. The COVID-19 pandemic is the most dramatic recent demonstration of how those drivers can combine to compress years of adoption into weeks.

2.2 COVID-19 as a contextual accelerant

McKinsey's 2020 global executive survey found that COVID-19 had accelerated the digitalisation of customer interactions and supply chains by approximately seven years. The mechanisms were straightforward: physical contact became impossible, regulatory barriers to digital alternatives were relaxed under emergency powers, and organisations that had previously cited implementation complexity as a barrier discovered that necessity reduced that complexity rapidly.

Ocado, the UK online grocery platform, provides a supply-side illustration. Its customer order volumes surged approximately 40% in the eight weeks following the first UK lockdown in March 2020. Ocado had spent over a decade building the warehouse automation, logistics software, and demand forecasting systems that allowed it to absorb that surge without service collapse. Competitors who had not digitalised their fulfilment operations could not match the capability. The pandemic did not create Ocado's advantage; it revealed it.

The lesson for practitioners is not that crisis is a digitalisation strategy. It is that organisations with pre-existing digital capability absorbed shocks that defeated less prepared competitors. Contextual pressure creates opportunity only for organisations whose digital foundations are already in place.

The COVID-19 crisis has compressed a decade's worth of digital adoption into roughly eight weeks. Companies that had been thinking about future digital strategies were suddenly implementing them, whether they were ready or not.

McKinsey Global Institute (2020). How COVID-19 has pushed companies over the technology tipping point - Executive findings

McKinsey's seven-year acceleration claim is based on survey data, not measurement of actual technological state, so it should be interpreted as a signal of intent and pace of adoption rather than a precise empirical result. The directional finding - that crisis compressed adoption timelines dramatically - is well-supported by sector-level data from retail, healthcare, and financial services.

Common misconception

Crisis-forced adoption proves the technology was ready all along - the barriers were just cultural resistance.

This conflates barrier type with barrier cause. Some barriers were cultural - clinician reluctance to adopt video consultation, for example - and crisis overcame them by changing incentives. But other barriers were genuinely structural: procurement rules, liability frameworks, interoperability standards, and payment models all required policy intervention before adoption was possible. The crisis changed both the incentives and the rules simultaneously, which is why progress was so rapid.

External drivers explain why organisations must digitalise. But understanding barriers explains why so many fail - and what distinguishes the organisations that succeed.

2.3 Barriers to digitalisation

McKinsey's 2023 research across 1,200 organisations found that 70% of digital transformation programmes fail to achieve their stated objectives. The failure is rarely technological. Four barrier categories appear repeatedly: legacy infrastructure, skills deficits, cultural resistance, and regulatory constraints.

Legacy infrastructure is the most frequently cited. TSB's 2018 migration from Lloyds Banking Group's systems to a new Sabadell platform failed catastrophically: 1.9 million customers lost access to online banking for weeks. The FCA and PRA fined TSB £48.65 million in 2022. The technical complexity of migrating 30 years of accumulated banking data and business logic from a legacy core onto a new platform had been underestimated. Legacy systems are not merely old: they encode institutional knowledge and operational rules that were never fully documented, making migration substantially more complex than technology vendors typically represent.

Skills deficits are structural. The UK government's own estimates projected a 1.5 million person digital skills gap by 2030. The gap is not only technical: it includes data literacy, digital product management, and the analytical skills needed to extract value from digitalised processes. Organisations that digitalise processes without building the skills to exploit the resulting data typically achieve operational efficiency gains but not the insight-driven advantages that justify transformation investment.

Common misconception

Technology is the main barrier to digitalisation - once the right platform is in place, adoption follows.

McKinsey consistently finds that 70% of digital transformation failures cite people and process factors as primary causes, not technology. The most common barriers are cultural (risk aversion, siloed working, lack of leadership commitment) and structural (legacy systems encoded with undocumented business rules, skills gaps, and misaligned incentive systems). Technology is typically the least constraining variable.

People, process, and technology stay balanced

People, process, and technology stay balanced. Technology changes only stick when people, process, controls, and evidence move together.

People, process, and technology pillars on a shared evidence base Three pillar cards side by side: People, Process, Technology. Each card splits into a top SUCCEEDS WITH zone listing the discipline owned by the pillar, and a red-soft FAILS WITH zone naming the failure mode if the pillar is missing. Each card carries a PUBLISHES line that names the evidence the pillar contributes to the shared base. A footer callout states the evidence-base rule. PILLAR 1 Leavitt (1965) People SUCCEEDS WITH - Skills inventory - Decision rights, RACI - Career and pay paths - User research practice FAILS WITH No one accountable for thenew way of working PUBLISHES capability and decision logs PILLAR 2 GOV.UK SM Process SUCCEEDS WITH - Standard work, runbooks - Approval, escalation paths - Service-level commitments - Change and incident loops FAILS WITH Old work survives next tothe new system PUBLISHES operating measures PILLAR 3 Kotter (2012) Technology SUCCEEDS WITH - Platform, architecture - Integration, APIs - Security, identity - Cloud, operability FAILS WITH A capable platform thatnobody uses well PUBLISHES service telemetry SHARED EVIDENCE BASE Each pillar publishes evidence the other two depend on. Without the evidence, the pillars do not balance. built by ransfordsnotes.com

Funding only the technology pillar tips the load onto people and process until the change collapses. The evidence base is what makes the three pillars hold together. Leavitt (1965); GOV.UK Service Manual; Kotter (2012).

With the individual PESTEL dimensions and barrier categories in mind, the interactive explorer below lets you apply the framework to a UK financial services scenario.

Loading interactive component...
Loading interactive component...

A PESTEL scan generates raw material. The section below explains how to use that material to make prioritised, organisation-specific assessments rather than generic lists.

2.4 Assessing context for a specific organisation

PESTEL analysis generates strategic input only when applied to a specific organisation in a specific sector at a specific point in time. A general PESTEL of digitalisation drivers is a starting point, not an output. The analytical task is to identify which drivers are most material to the organisation in question and to weight them against the organisation's specific constraints.

A useful diagnostic question for each PESTEL dimension is: does this factor create urgency, create opportunity, or create constraint? The FCA Consumer Duty creates urgency for UK financial services firms - it is a compliance obligation with a deadline. Open Banking creates opportunity - it enables new product propositions. UK GDPR creates constraint - it limits cloud provider choice and data architecture options. The same factor can operate differently for different organisations within the same sector.

Context assessment is not a one-time exercise. The environment changes - regulation is updated, competitors launch new products, technology economics shift. Organisations that build a rhythm of contextual scanning, rather than conducting a single analysis at strategy inception, maintain a more accurate picture of what the digitalisation mandate looks like at any given moment.

The most common failure in PESTEL analysis is treating it as a list-making exercise rather than a prioritisation tool. The output that matters is not how many factors you identify - it is which three or four factors are creating the most pressure on your specific organisation's digitalisation timeline right now.

Check your understanding

A retailer operates 200 physical stores but has no online presence. Smartphone ownership in its core demographic has reached 91% and a competitor just launched an app with 1 million downloads in its first month. Which PESTEL factor most immediately threatens this retailer's business model?

A manufacturer digitises all paper quality-control forms into PDFs stored on a shared drive. Inspectors access forms on a tablet rather than carrying paper. The inspection process, the sign-off workflow, and the reporting to management remain unchanged. Is this digitisation or digitalisation?

Which of the following best describes a digital transformation?

Loading interactive component...

Key takeaways

  • PESTEL analysis maps the six categories of external driver (Political, Economic, Social, Technological, Environmental, Legal) that create pressure, opportunity, or constraint for digitalisation.
  • The UK context includes specific high-pressure drivers: DCMS Digital Strategy, £151bn digital economy, 92% internet use, Making Tax Digital, UK GDPR, and the FCA Consumer Duty.
  • COVID-19 accelerated digital adoption by approximately seven years by simultaneously changing incentive structures and removing regulatory barriers under emergency powers.
  • 70% of digital transformation programmes fail - McKinsey identifies cultural resistance and legacy infrastructure as the primary barriers, not technology.
  • TSB's £48.65 million fine illustrates that legacy infrastructure complexity is not merely a technical problem: it encodes undocumented institutional knowledge that makes migration harder than vendors represent.
  • Context assessment is most valuable as a recurring diagnostic rather than a one-time project-inception exercise.

Standards and sources cited in this module

  1. DCMS (2022). UK Digital Strategy. Department for Culture, Media and Sport.

    Chapter 1: The Opportunity

    Primary source for the £151bn UK digital economy figure, the 6.7% GVA figure, and the government's digital skills investment commitment cited in Section 2.1.

  2. McKinsey Global Institute (2020). How COVID-19 has pushed companies over the technology tipping point - and transformed business forever.

    Technology adoption findings

    Source for the seven-year acceleration claim cited in Section 2.2 and the underpinning survey methodology.

  3. McKinsey Digital (2023). Delivering the digital transformation. Global survey of 1,200 organisations.

    Failure root causes analysis

    Source for the 70% failure rate and barrier categorisation cited in Section 2.3. The culture and people finding is consistent across multiple McKinsey publications from 2018 to 2023.

  4. FCA/PRA (2022). Final Notice: TSB Bank plc. FCA Reference: 183004.

    Findings

    Primary regulatory source for the TSB case. Provides detailed account of the migration failure, the customer impact (1.9 million affected), and the basis for the £48.65 million fine cited in Section 2.3.

  5. NHS England (2020). Remote consultations guidance and statistics. NHS Digital.

    Primary Care activity statistics

    Source for the GP consultation modality data: 1% video pre-pandemic, 71% remote (telephone and video) by May 2020, and the subsequent settled rate of approximately 50% in 2022.

  6. ONS (2022). Internet users, UK: 2022. Office for National Statistics.

    Main results

    Source for the 92% UK adult internet use figure cited in Section 2.1 and the historical comparison to 79% in 2011.

With the PESTEL framework mapped and barriers identified, the next question is: what are the technical building blocks that make digitalisation possible? Module 3 examines cloud computing, microservices, APIs, and DevOps as interdependent components of a digital operating model.

Module 2 of 15 in Foundations