Sources of Resistance in Digital Projects: Study Insights

I treat resistance in digital projects as a reason to check what is wrong - not proof that staff refuse to change. Before pushing for more use, I check workload, skills, system faults and trust.

The training gap helps explain why. In 2025 UK SME research, 82% of employees wanted to upskill, yet fewer than one-third had received formal training in the previous 12 months. Willingness alone cannot close that gap.

My approach is to:

• Find the cause: ask about job fears, confidence, unclear roles and competing demands.
• Check the work: test whether the system fits daily tasks and whether staff have time to learn.
• Match the response: fix faults, explain decisions and provide role-based practice and support.
• Review the results: track task completion, errors and staff feedback - not just logins.

<u>Use is not the same as acceptance.</u> I look for signs that people can do their work well, not simply follow instructions. Research offers a starting point, but each project needs its own checks.

2. Personal Concerns, Technical Problems and Skills Gaps

Anxiety, Job Insecurity and Change Fatigue

One employee study links technology anxiety to greater resistance and digital competence to lower resistance. These findings depend on the study’s context.

Fear, skills gaps and poor delivery can all produce similar resistance. Leaders need to identify the cause before deciding how to respond.

Factor	Reported mechanism	Evidence type and indicative strength	Typical project signals
Technology anxiety	Unfamiliarity or low confidence makes the new system feel risky	Quantitative studies and reviews; moderate, context-dependent evidence	Repeated requests for reassurance; reluctance to use test environments
Job insecurity	Employees fear redundancy, reduced status or poorer employment prospects	Reviews and employee studies; recurring association, not proof of universal causation	Rumours; guarded behaviour; resistance to automation-related tasks
Perceived loss of autonomy	Standardised workflows or monitoring seem to reduce discretion	Quantitative studies; findings should be treated as study-specific	Workarounds; objections to monitoring; escalation of approval concerns
Low self-efficacy or skills confidence	Employees doubt their ability to learn or perform effectively	Reviews and skills-gap studies; moderate evidence	Avoidance of training; reliance on informal experts; high support demand
Change fatigue	Previous initiatives drain attention, energy and willingness to engage	Surveys and literature reviews; strength varies by measure and setting	Missed workshops; delayed decisions; superficial compliance
Unclear personal value	Employees cannot see how the change improves their work or career	Technology-acceptance and change-management research; context-dependent	Low voluntary use; continued reliance on legacy tools

These ratings describe confidence in the relationship, not its size. Anxiety, perceived risk and fatigue may feed into one another, but leaders should test that explanation rather than assume it.

Ask employees privately what they think they might lose, which tasks worry them and whether earlier changes left problems unresolved. Be honest about how roles may change. Do not promise job security unless that promise can be kept.

Personal concerns are only part of the picture. Design and rollout problems can lead to the same behaviour.

Usability, Skills and Implementation Gaps

Digital readiness is task-specific. Lloyds/Ipsos’s 2025 Essential Digital Skills findings show that 82% of UK labour-force adults meet the Work Essential Digital Skills measure, but only 45% can complete all 20 surveyed work tasks. These figures describe the surveyed population, not readiness to use a particular workplace system.

Source of difficulty	Evidence or diagnostic method	Leadership response
Design problem: confusing navigation, inaccessible screens, unreliable integrations or a poor fit with workflows	Usability testing, task observation and defect analysis help distinguish product faults from reported perceptions	Simplify user journeys, use familiar language and retest representative tasks
Skills gap: users lack the knowledge, confidence or practice to complete required tasks	Observed task assessments establish capability; skills surveys provide broader context	Offer role-based practice, accessible guidance and coaching
Implementation gap: weak preparation, unclear benefits, excessive transition workload or unexplained monitoring	Interviews, workload reviews and support records identify delivery gaps; a 52-study review examines organisational conditions and training design	Protect learning time, phase deployment, clarify data use and assign responsibility for support

A task may feel complex because of anxiety, but the cause could also be the interface, configuration, unfamiliar processes or too little practice. Test it under normal working conditions before choosing a fix. Passing technical tests does not prove that a system fits employees’ work.

Training needs time and opportunity, not just willingness. In 2025 UK SME research, 82% of employees wanted to upskill, yet fewer than one-third had received formal training in the preceding 12 months. Use short, practical sessions followed by supported practice, with floor-walking or responsive support after launch. The 52-study review supports tailored, psychologically safe learning as part of continuing support, rather than one-off technical demos.

sbb-itb-1051aa0

3. Organisational and Leadership Causes

If personal concerns do not fully explain resistance, examine the project’s leadership, communication and resources.

Unclear Direction, Low Trust and Limited Staff Input

A systematic review of 25 manufacturing studies found three recurring barriers: poor communication, limited resources and rigid culture. These are recurring themes, not universal causes. Their importance varies by sector, project type and workforce composition.

Assess resources in terms of project capacity. Compare the project brief with what employees hear from line managers. If priorities, affected roles or timings differ, flag a communication gap. Early signs include inconsistent messages, unclear ownership and slow decisions.

Trust follows visible action, not announcements. Reviews link leadership commitment and transparent communication with stronger engagement. Publish decisions and explain trade-offs. Check whether performance targets still reward the old behaviours the project aims to replace.

Give staff a clear say in requirements and rollout decisions, then show which suggestions changed the plan. Consultation after a decision gives staff little autonomy. When decisions do not match the messages staff hear, communication gaps can become trust problems.

Management Concerns and Resource Limits

Reviews identify role changes and doubts about leadership vision as sources of manager resistance. Treat these as questions to investigate, not motives to assign. Ask which approvals, responsibilities and performance measures will change. Delayed approvals and blocked decisions may reflect unclear accountability rather than outright opposition.

Check working conditions before asking for greater commitment. Map the added workload, competing deadlines, staffing cover and decision authority. Can managers release staff for project work without missing day-to-day targets?

Where capacity falls short, reduce scope, phase delivery or provide temporary cover. Participation needs time and decision authority, not another meeting. Use these checks to establish whether resistance stems from the system around the project before choosing a response.

4. How Leaders Can Respond

Once the cause is clear, choose a response that addresses it.

Match Responses to Causes

Test suspected causes through interviews, workflow observation and usage data. Non-use alone proves nothing. Match your response to personal concerns, technical gaps or leadership issues. Treat these responses as practical options, not proven interventions. If staff fear redundancy or losing skills, discuss role changes directly.

The table below links common causes to the most direct response.

Resistance source	Practical response
Job insecurity	Explain future roles, required skills and decision rights. Be clear about what remains uncertain.
Low skills	Provide role-specific practice, protected learning time and accessible support during live work.
Anxiety	Introduce adoption in stages, offer safe trials without performance penalties and make help visible.
Unclear value	Agree concrete work outcomes, such as fewer duplicate entries or faster approvals.
Low trust	Publish decision criteria, limitations and data-use rules; involve staff in testing.
Change fatigue	Prioritise changes and remove obsolete work before adding new tasks.
Management concerns	Define sponsorship duties and give managers a say in how work is organised and supported.

Assess Resistance Before Launch

Before launch, use interviews, workflow reviews and small pilots to test task fit, data reliability, user capability and leadership support. Use the findings to separate personal concerns from technical faults and working conditions before choosing a response.

Align planning, delivery and support before launch. Keep a resistance risk register that records the source, affected group, evidence, owner, intervention and review date. Include expected behaviour changes and alternative explanations so you can test your diagnosis.

Track Adoption and Clarify Delivery Ownership

After launch, check whether your response is changing behaviour - not just whether people are using the system.

Track training, competence, feature use, support requests, workarounds, confidence and perceived support together. Fewer support requests could mean people are working independently, or that they have disengaged.

Set baselines before launch. Review progress at pilot completion, at launch and around 30 days after launch. Compare adoption with task completion, errors and service outcomes before extending the rollout.

Assign accountable owners for business outcomes, workflow decisions, technical delivery, training, support, data governance and post-launch review. Document decision rights, acceptance criteria, workflow responsibilities and post-launch support. Delivery capacity does not replace leaders’ responsibility for organisational change.

5. Conclusion: Diagnose Causes and Review Responses

Across the studies reviewed above, resistance is better understood as a response to interacting factors, not a fixed employee attitude. A review bringing together 63 papers links resistance to perceived threats to time, energy and support. It also cautions that job insecurity alone does not fully explain resistance. Recurring themes include personal concerns, digital skills, technical fit and organisational support.

Psychological safety connects these concerns. Staff need to feel safe admitting difficulties so that the causes become clear and gaps or workflow problems can be addressed. Training works best when it is tailored, safe and provided over time. Findings from specific sectors or samples still need local testing: recurring themes do not establish a universal cause.

The practical approach is to diagnose first, match the response to the cause, and review adoption alongside staff experience. These are guidelines, not universal rules. Success means more than compliance: staff need to use the technology well, share feedback openly and keep using it over time.

FAQs

How can I uncover resistance staff are reluctant to discuss?

Build psychological safety by welcoming questions, admitting when you don’t know something, and setting ground rules against interruptions and blame. This helps staff feel safe voicing concerns. Listen closely and summarise what you’ve heard to check your understanding.

Use one-to-ones and retrospectives to gather feedback, with anonymous surveys for sensitive issues. Ask focused, non-leading questions about challenges, risks, dependencies and trade-offs to encourage honest responses.

Which causes of resistance should I address first?

Start with a focused discussion with the stakeholders involved. Listen without pushing back, and work out what’s causing the concern. Before treating resistance as a technical issue, check for unclear requirements, unrealistic deadlines or conflicting assumptions about the project’s scope.

Focus on openness and solving the problem together - not blame. Acknowledge concerns and ask what information or resources the team needs. Keep the discussion centred on specific, measurable business problems to build trust and align the team’s work with business goals.

How can I tell whether acceptance will last?

Acceptance takes continued management, not just a successful deployment. Use real-time dashboards to track user adoption rates and process completion times. Gather feedback through surveys and interviews to spot drops in adoption or bottlenecks.

Set a regular review cycle, such as a 60-minute quarterly check, to keep the solution in line with changing business requirements and regulatory updates, and to check for model drift. Adjust the workflow as your organisation changes.