Everyone supports the change. Until the new process becomes real work.

AI summary: New organisational processes may fail to become everyday practice even when employees express support. Positive attitudes do not ensure capability, opportunity, role clarity, safe learning, suitable habits or a credible social norm. Associations with extra work, risk, loss of control or previous failed initiatives can matter, but technical and organisational obstacles must be diagnosed separately. Combine process evidence, observations and interviews with association research where appropriate. Use COM-B, implementation intentions and normalisation theory to frame hypotheses, then test actual task execution, quality, workload and sustained use. No neuroscience method provides a universal measure of employee resistance or adoption.

Imagine a field-service organisation introducing a shared ticketing system for incoming customer requests. Most employees agree with the goal: fewer missed handovers, clearer accountability and one record of what has been promised. In a meeting, they can explain why the new process is sensible. Yet during the morning rush they continue using email, personal notes and a familiar spreadsheet.

Many change programmes ask, 'Do you think this is a good idea?' and then treat the answer as if it were 'Will you use the new procedure correctly when three urgent requests arrive at 8:15?' Those questions refer to different realities. One concerns a general judgement. The other concerns skills, available time, interfaces, social expectations and the consequences of acting.

Ajzen's theory of planned behaviour distinguishes attitudes, perceived norms, perceived behavioural control and intentions. These concepts help explain why approval alone should not be confused with execution. [1] They do not mean that a positive staff survey predicts reliable use of a particular organisational system. An employee can approve of the desired outcome yet have good reason to believe that the necessary action is impossible without another department's assistance.

Collective changes require more than personal goodwill. Weiner's theory of organisational readiness distinguishes shared commitment to a change from the shared belief that the organisation can implement it. [3] The paper proposes a theoretical account, not a numerical promise about any one company. A team may strongly value the goal while estimating that staffing, equipment or coordination are inadequate.

This is why 'resistance' makes a poor umbrella explanation. Sometimes there is an objection to the proposed process. Sometimes the software is broken. Sometimes people follow an old habit even though they intended to do something else. Sometimes their manager still treats the old report as the real source of truth. A dashboard records the same result: the new process is not followed. But the reasons, and the appropriate responses, differ sharply.

That distinction matters to employees as much as to leadership. Calling a genuine obstacle 'unwillingness' can harm trust. Trying to remove a valid concern through more persuasive messaging can make an unsafe process seem acceptable. Before asking how to increase enthusiasm, ask what makes the required action possible, intelligible and safe when it is needed.

An association is a connection between an object, event or idea and a meaning. 'New workflow' may spontaneously suggest 'finally, one clear overview' to one person and 'more administration' to another. The two associations can coexist. They are not permanent psychological types. The same employee may like the change in a meeting and dread using the software during a time-critical customer call.

This matrix contains hypotheses, not observations from a Neurofactor client study. An adoption percentage alone cannot tell us which association is dominant. Even when a negative association can be demonstrated, the underlying concern may be justified. If the procedure takes longer and produces no benefit for the task, employees do not need a more cheerful label for it. The process needs work.

Different tasks also create different meanings. A scheduler handling urgent work needs rapid access to accurate details. A technician away from the office needs usable access in the field. A manager responsible for audit trails may need different evidence. These are differences in task context, not proof that people with particular job titles share fixed psychological traits. Ask what each situation demands before designing a survey or an intervention.

Research should explore attractive and aversive associations separately. 'Fewer mistakes', 'better customer support' and 'clear accountability' may coexist with 'bureaucracy' and 'lost autonomy'. A single average favourability score hides this conflict. The important question is which meaning matters at the precise moment the employee can choose between the old and new action.

The origin of a concern also matters. It may come from an unsuccessful previous launch, a confusing demonstration or a concrete operational problem. Treat that origin as something to investigate rather than assuming every objection is an irrational psychological barrier. Otherwise change communication becomes a way of hiding inadequate design.

Every implementation diagnosis should separate three practical questions. Does the employee support the goal? Can they carry out the action? Does the environment allow the action at the relevant time? A fourth follows naturally: what happens when the person tries?

An employee may know why the new process matters but not where the appropriate field is. They may find it but lack access rights. They may have rights but be unable to leave a caller waiting while a long form loads. They may complete the form only to discover that the manager still expects the old weekly spreadsheet. A single adoption metric will combine these causes unless the research is designed to separate them.

The COM-B model by Michie, van Stralen and West places capability, opportunity and motivation at the centre of a behaviour system. [2] It explicitly includes physical and social opportunity. It therefore challenges the idea that all shortcomings should be met with further persuasion or training. If the environment prevents the action, enthusiasm cannot repair it.

Klein and Sorra approach implementation by considering the fit between an innovation and users' values, alongside a climate that supports the innovation's actual use. [4] The environment communicates what counts. Does the new action save real effort? Are exceptions accepted? Is support available? Does management act according to its own new rules? These questions can carry greater behavioural weight than the wording of a launch poster.

Some apparently positive data also deserve caution. A staff member can log in every morning while continuing to work from email. Tickets can be created at the end of the day without supporting the intended handover. A manager can report that the training is complete even though the first genuinely difficult scenario has never been practised. A system login is an event. It is not equivalent to correct process execution.

The simplest useful research step can be to watch one authentic task. Record when the old routine takes over, which systems are involved and why the alternative is or is not available. Only then determine whether the priority is training, interface design, permissions, management behaviour, workload or associative meaning.

Most organisations have some data about workflow adoption. Those data are useful but not self-interpreting. A decline in system activity can reflect a change in task volumes, access problems or a lack of adoption. A rise may reflect genuine use or bulk entry after the work has already been done. Interpretation must match the measurement.

A strong study starts with competing explanations. Without them, every disappointing figure is retrofitted to the story that leadership already prefers. That may make for a convincing meeting, but not a defensible design decision.

Distinguish patterns from anecdotes. One error message may prevent a specific person from working, but it does not automatically explain an entire department. Conversely, high overall adoption can conceal a critical handover that regularly fails. Segment by meaningful tasks and situations, not convenient stereotypes. Protect privacy, especially in teams small enough for individual performance to be inferred.

The Consolidated Framework for Implementation Research, or CFIR, proposed by Damschroder and colleagues, encourages investigation of the innovation, context, people and implementation process. [9] It originated in healthcare implementation research, so transferring its concepts to another industry requires judgement. It is not proof of any one barrier. Its value lies in stopping a researcher from treating 'employee attitude' as the only possible explanation.

Servicebedrijf Rivierlijn, its employees, the comments below and all proposed interventions are entirely fictional. The case illustrates hypotheses and research design. It is not a measured Neurofactor project or a claim about a real client.

Servicebedrijf Rivierlijn coordinates business maintenance requests. Work arrives by phone, email and a customer portal. Management wants to replace separate inboxes and personal tracking sheets with a central workflow. Every new job must be created, assigned, updated and closed within a shared ticketing system. The goal is clear: fewer failed handovers, better traceability and less searching for information.

Employees helped define the process in three workshops. They described it as 'logical', 'better for the customer' and 'finally, one overview'. Two weeks after launch, however, urgent jobs still travel by email. Some tickets are entered retrospectively. Management proposes additional training and a communication campaign saying 'Working smarter together'.

A hypothetical observation could reveal a different picture. The scheduler answers multiple calls while looking for a location code that was instantly visible in the old sheet. A field technician cannot always connect from the customer's site and records details on paper first. The team leader continues asking for the previous Excel report because it feeds an established management dashboard. Employees therefore do some of the same work twice.

Several associations might arise: 'the new system is extra work', 'I could lose information' and 'management clearly trusts the old report more'. But these are hypotheses, not measured results. The practical task is to test which explanation matters in each situation, including whether the problem is an observable lack of access rather than a belief.

The change team considers three hypothetical interventions. No version is presented as a proven winner.

If A solves the main problem, a motivational campaign would be misdirected. If C is necessary, leadership needs to change its own conduct. If B proves relevant, employees require accessible learning and fair error handling. More than one change may be necessary, and evaluation should determine their contribution rather than selecting a preferred explanation in advance.

The business outcome is more demanding than a higher count of tickets. Faster records are not useful when technicians receive incomplete information. More completed forms are not success if duplicate requests rise. Follow the entire journey from the initial call to handover, delivery, customer communication and correction of mistakes.

A reliable implementation must also make room for discovering that the design needs revision. Support means little if employees are invited to co-design the process and then forbidden to report where it fails. A workable workflow is not a fixed slogan. It is something the organisation must maintain and improve.

Step 1 - Define the precise target behaviour. Say who must do what, under which circumstances, using which tool and with what quality requirement. 'Everyone should use the new process' is not an adequate operational definition. 'Before transferring a new urgent service request, the scheduler records the correct location and responsible colleague in the shared system' is testable. Define legitimate exceptions.

Step 2 - Describe current behaviour without blame. Observe what people actually do during routine work and exceptions. Document informal tools, workarounds and dependencies between departments. Do not rely exclusively on an official process map; it may differ from the real practice that currently keeps services running.

Step 3 - Audit practical conditions. Test account access, permissions, response times, mobile use, forms, accessibility, integrations and recovery from mistakes. Measure time spent on the action. Check that old reports have actually been retired. Technology and organisation problems should not be mislabelled as motivation problems.

Step 4 - Explore associations with the proposed change. Before offering another explanation, ask what the change spontaneously suggests: 'overview', 'control', 'more work', 'safe', 'complicated' or 'better for customers'. Separate the purpose, system, management and personal consequences as objects of judgement. Approval of the goal should not be mistaken for confidence in every step.

Step 5 - Examine capability, opportunity and motivation separately. Use COM-B as an organising framework. [2] Can employees perform the action? Does their environment provide a realistic opportunity? What outcomes do they expect? Repeat the questions for peak hours and unusual cases instead of assuming conditions are stable throughout the day.

Step 6 - Observe first use in a real task. Give employees a representative scenario with permission to request help and discuss errors. Look for the point where familiar routines reappear. Where possible, keep the evaluation separate from individual performance management. Minimise personal data, document retention and make reporting appropriately anonymous.

Step 7 - Define competing intervention hypotheses. One might be: 'If the location code appears automatically, urgent registrations will require less time and will be more complete.' Another: 'If management no longer demands the old report, the new process becomes the visible norm.' Specify the assumed mechanism, target behaviour, success measure and possible harm for every change.

Step 8 - Compare observed behaviour responsibly. Where feasible and ethical, use phased introduction, team-level randomisation or another appropriate evaluation. Account for differences in workload and case complexity. If using before-and-after evidence without randomisation, report confounding and avoid treating correlation as proof of a particular psychological mechanism.

Step 9 - Check whether the process becomes ordinary and useful. Continue after launch week. Measure complete tasks, rework, customer errors, appropriate exceptions, workload and sustained adoption. Check that new starters can learn the system and that temporary project support can eventually be reduced. Launching software and embedding a work practice are different accomplishments.

These nine steps turn a broad change narrative into a practical study. What precise behaviour is missing? What competing explanations could account for it? What evidence would change the team's mind? Which intervention is necessary, proportionate and testable? Association research earns its role by helping answer those questions, not by adding a decorative psychological score to a dashboard.

When people continue using the old route six weeks after launch, an extra communication campaign is tempting. It will help only if misunderstanding the purpose or value of the change is the main obstacle. COM-B highlights the importance of capability and opportunity as well as motivation. [2] These should be examined separately before a team decides what to improve.

Capability is more than knowing where a button is. Employees need to understand the information required, recognise exceptions and recover from an error without unreasonable consequences. An intricate handover can require specialist knowledge that an online lesson cannot replace. Do not ask only whether training was completed. Observe whether the person can carry out a critical task reliably under the conditions in which it actually occurs.

Opportunity is not a matter of attitude. Consider a system that fails in the field, two reporting processes that are still mandatory, a manager who cannot handle justified exceptions, or a schedule with no capacity for practice. The physical and social environment makes the target behaviour easy, difficult or impossible. Sometimes the most important intervention is a permission change, a better integration or the removal of duplicated administration.

Motivation involves more than explicit agreement. People anticipate consequences, feel uncertainty, learn from others and follow familiar routines. A procedure may mean 'professional and customer-focused' while simultaneously implying 'slower' or 'less autonomy'. None of these associations can be inferred from general employee sentiment alone. Their relevance must be examined at the actual point of choice.

Do not use COM-B to sort people into supposed personality categories. Someone is not a 'motivation problem' because one part of a process feels risky. The model helps organise explanations about behaviour and context. It does not promise that choosing a particular intervention function will always produce a predictable improvement. [2]

Weiner's work offers a useful complementary distinction between collective commitment and perceived collective capability to implement change. [3] Employees may value the goal while genuinely doubting that the team has enough time, equipment or support. One response is a slogan that insists the transition will be easy. Another is to examine whether the doubt is reasonable and adapt the implementation. The second usually creates a more credible foundation for collaboration.

The old way of working is often not an act of defiance. It is the response that people and their environment have practised together. A customer calls, a familiar spreadsheet opens, the number is available and the employee continues. That sequence is fluent because it has worked many times. The new system is expected to compete with it at precisely the same moment.

Research on habit formation by Lally and colleagues shows that developing automaticity through repeated behaviour in a context takes time and varies substantially. [7] It does not establish one fixed number of days required to implement a complex organisational workflow. Such a workflow is not the same as repeating a simple individual health behaviour. It does, however, make a useful point: a completed training session is not a new habit.

Implementation intentions offer a practical way to focus on the point of action. Gollwitzer and Sheeran reviewed plans that link a recognisable situation to an intended response: if situation X occurs, then I will do Y. [6] In Rivierlijn's fictional example, the plan could be: 'If a customer reports a new fault by telephone, I will open the shared ticket before forwarding the request.' The plan must remain realistic. If the application regularly freezes, better intention-setting cannot make the software work.

Context should also be redesigned. Put the new route where the task starts. Make its first step obvious. Remove duplicate reports when it is safe to do so. Provide practical help at the moment of first use. A reminder can help when people genuinely forget; it becomes noise when they already remember but have no time or opportunity to act.

Many organisations jump from 'training completed' to 'habit established'. The space between them includes repetition, errors, feedback, competing demands and exposure to unfamiliar cases. Study whether the behaviour survives holidays, staff changes, illness and busy seasons. Only then is it reasonable to discuss whether the new route has become part of the working routine.

A whole department can attend a workshop, yet one urgent message from a manager asking for the old spreadsheet can override the stated plan. Employees observe what actually matters when pressure rises. Formal policy is only one influence on behaviour; the social norm is communicated through everyday decisions.

Klein and Sorra's model emphasises implementation climate and the alignment between innovation and user values. [4] It does not require an organisation to monitor every click. A supportive environment also makes it possible to challenge faulty design, seek help and address errors. Support is not the same as pressure disguised as encouragement.

Psychological safety deserves particular attention when a new system makes work more visible. Edmondson's research examined psychological safety and learning behaviour in teams. [8] It provides reasons to investigate the social cost of asking questions, admitting errors and reporting inconvenient findings. It is not proof that one safety workshop will improve every company's adoption rate. A narrower and testable idea is that a fair response to problems may make them easier to identify and correct early.

Leaders can examine this with concrete observations. What happens when a worker finds a wrong record? Does the manager ask about the process or immediately blame the person? Can a team member explain why a field is unusable without acquiring a reputation for being difficult? Are justified exceptions documented rather than concealed? These answers may differ across locations and time periods.

Baer and Frese studied process innovations in relation to a climate for initiative and psychological safety in organisations. [10] Their findings are context-bound, and they cannot establish the outcome of any fictional Rivierlijn intervention. They reinforce the importance of investigating organisational conditions rather than measuring personal attitudes alone.

A credible norm also asks management to do the same work differently. Use the new reports, clarify the escalation route and follow the agreed exceptions. Avoid public rankings of employees supposedly 'behind the change'. Such rankings can encourage cosmetic compliance and discourage truthful reporting. The goal is not a team that hides mistakes. It is a team able to do reliable work and improve it when conditions change.

A process is not yet part of daily work while the project manager must send reminders every morning. Sustainable implementation requires people to understand why the new practice exists, coordinate their contributions, make room for it in their responsibilities and continue checking whether it is useful. May and Finch's normalisation process theory offers a way to analyse the work involved in embedding practices. [5]

This is different from a launch checklist. A launch asks whether software has been installed, training is scheduled and communication has been distributed. Normalisation asks who will do the work tomorrow, what has changed in the handover, which resources are permanently necessary and how problems will be corrected. In a complex organisation those questions recur.

A serious change project must be able to revise the process itself. A mandatory step may prove ineffective or introduce avoidable errors. In that case insisting on greater compliance would be the wrong intervention. Fix the design. Workability matters more than an aesthetically flawless kick-off.

Use a repeating cycle: observe, explain, modify and test again. Start with real work cases, not generic statements about resistance. Give reported problems an owner, decision and feedback loop. If every concern disappears into a shared mailbox with no visible response, the experience may weaken confidence in later initiatives.

Maintenance is part of the design. Software, staffing, client requirements and working conditions change. Schedule an evaluation during the first weeks and another after project support has reduced. Clarify who maintains instructions, handles exceptions, trains new colleagues and checks information quality.

Normalisation process theory emerged from the study of embedding practices, including in healthcare. [5] Its mechanisms can help frame organisational work elsewhere, but it is not a ready-made forecast for a specific service company. Apply the concepts to measured tasks and document where the model does or does not fit.

1. Start with a specific event, not an abstract change slogan. Say what the employee must do when a recognisable situation arises. Include real exceptions and peak demand. 'We work together more efficiently' describes an aspiration, not a procedure for handling an urgent customer request.

2. Remove duplicate work before rewarding adoption. Audit which old reports, spreadsheets and email routes still serve a purpose. If two systems remain mandatory, the old behaviour may continue for entirely rational reasons. Clear authority and process redesign are more useful than another motivational presentation.

3. Put knowledge at the point of action. A long pre-launch lesson is not necessarily the best place to explain unusual cases. Provide concise instructions, a colleague or a contextual prompt during the real task. Check whether help is available across shifts, locations and devices.

4. Practise difficult cases rather than only the polished demonstration. Demos usually run smoothly. Real work includes missing information, exceptions, network failures and multiple simultaneous demands. Let people practise these conditions and measure correct recovery and independent task completion, not just satisfaction with the training.

5. Create a fair route for reporting problems. Explain what happens to feedback and who is responsible for decisions. Do not call employees resistant when they identify a broken process. Psychological safety does not mean accepting every proposal, but it does require a serious learning process. [8]

6. Make leadership follow the same operational rules. A manager who still asks for the old report keeps the old practice relevant. Align management dashboards, priorities and escalation procedures with the intended workflow. Check that performance expectations do not inadvertently penalise the new behaviour.

7. Use feasible if-then plans. A recognisable trigger can help connect intentions with action. [6] Include professional exceptions and emergency alternatives. A behavioural prompt should not suppress justified judgement or conflict with safety requirements.

8. Provide feedback on quality, not just frequency. Logging in and opening a form are weak indicators. Check whether handovers are complete, customers are served correctly and rework decreases. Numbers help only when the metric represents the purpose of the process.

9. Test whether interventions undermine one another. Extra reminders may distract. Additional checking may make error anxiety worse. A cheerful campaign may seem dishonest when software repeatedly fails. Define the proposed mechanism and potential side effects before adding new elements.

10. Assign long-term ownership to adaptation. A launch rarely reveals every edge case. Review the workflow after the first month and again later. Ask what new starters need, what has become unnecessarily difficult and how the process changes with workload. Continuous improvement is part of successful implementation.

These are not ten universally proven conversion levers for organisational change. The appropriate answer may be just one system improvement and one management decision. Choose interventions based on evidence about the actual barrier. Motivation cannot substitute for access to the system.

Explicit association research can explore meanings employees spontaneously connect to a change. 'More transparency' might mean better coordination to one person and closer management scrutiny to another. Interviews, sorting tasks and well-constructed questions can reveal competing meanings. Their value depends on the exact research objective and the context of the respondents.

Implicit association tasks may sometimes provide complementary evidence about relative links among concepts. They require a suitable instrument, meaningful comparisons, prespecified stimuli and attention to reliability, validity, order and practice effects. A reaction-time difference does not reveal why someone failed to complete a ticket. It is not mind reading, a universally valid individual diagnosis or a replacement for workplace evidence.

Task observation and process analysis are often the most direct starting point. They show where the workflow stops, which information is needed, what systems permit and how old habits reappear. Combine them with questions about meaning. A new application may feel difficult because a person does not understand it or because an essential function really is missing. One interview or one log file may not separate these explanations.

Eye tracking can help investigate visual attention in a specific interface task. It may reveal that a critical instruction or control is missed. But gaze patterns do not directly measure trust, approval or motivation. Long fixation may reflect reading, surprise or confusion. Eye tracking may add little when the main problem concerns phone calls, permissions or interpersonal coordination rather than visual information.

EEG can examine time-related brain responses to stimuli under defined research conditions. It does not offer a direct universal score for 'resistance to change', 'trust' or 'willingness to comply'. Interpretation depends on stimulus, task, signal quality and behavioural context. Many implementation problems are better approached first through software audits, observation and interviews. More advanced technology is worthwhile only when it addresses a well-defined and relevant question.

Employees are not freely available test subjects. In an employment relationship consent may be less voluntary than it appears. Minimise identifiable data, use aggregated or anonymous results where possible, restrict access and retention, and avoid making neural or emotion-based rankings of individuals. Explain who may see the findings and what decisions the data may and may not support.

A defensible Neurofactor study can combine methods where justified, but it should never treat them as interchangeable. A skipped field does not automatically indicate a negative association. A positive word in an interview is not proof of adoption. Looking at a button does not establish comprehension. Good research describes what was measured, why its interpretation is reasonable and which uncertainty remains.

Sometimes the most useful finding is that associations are not the principal obstacle. Software is too slow. Access rights are insufficient. A mandatory step conflicts with a customer agreement. Employees are measured on speed while being asked to perform a new, time-consuming control. Nobody has been given authority to resolve a cross-team exception. None of these difficulties should be presented as an employee attitude problem.

A second possibility is that the design itself is poor. A process can appear elegant to management yet add steps and errors in practice. If that is the case, the organisation must improve the process rather than try to give employees more favourable associations with it. Support for the general goal never justifies forcing an unsafe or ineffective procedure into use.

Third, the outcome measure may be misleading. An employee following an authorised emergency route is not necessarily failing to adopt. A team facing more complex cases may naturally take longer. Comparisons that ignore task mix, shift conditions and access can create unfair conclusions about people and groups.

Values and legitimate interests also matter. A workflow may serve a worthwhile goal while restricting professional autonomy or increasing data collection. Employees can reasonably question those effects. Klein and Sorra's implementation model incorporates fit with users' values. [4] That is not a promise to adopt every preference, but a reason not to dismiss a values conflict as simple stubbornness.

Keep observed behaviour, factual constraints, anticipated consequences and measured associations separate throughout the project. An organisation can collect very precise data and still reach the wrong conclusion if these layers are confused.

A change dashboard can look reassuring: training completion is high, logins are increasing and sentiment is positive. Yet the critical question remains. Are customer requests more complete? Is rework lower? Can another employee take over a case safely? Are employees saving time or doing unseen additional work after hours?

Choose a primary outcome that represents the target behaviour directly. For example, the proportion of relevant urgent service requests completely and correctly recorded before handover. Define the denominator and legitimate exceptions. Identify the data source. A change in volume or case mix can make an adoption percentage rise even when daily behaviour has not improved.

Add balancing outcomes: time per task, duplicate records, complaints, errors, unexpected escalations, employee workload and the customer's actual result. More system activity is not a success when service quality or safety deteriorates. The point of implementation is better work, not more form submissions.

Where possible, compare the intervention with an appropriate alternative. A randomised phased roll-out can be valuable under suitable conditions, but not when it would delay essential safety protections. Other settings may require a carefully designed quasi-experiment or time-series evaluation. Record competing changes in staffing, seasonality and workload. Avoid claiming causality from a simple before-and-after comparison with no consideration of alternatives.

Continue measurement after launch. Examine what happens when special project support is removed. Include new employees and unusual situations. Normalisation research distinguishes initial implementation from the continuing work required to embed a practice. [5] A promising first week is therefore not the same as sustainable success.

Finally, make evaluation safe and proportionate. Report at a level that limits identification. Use the findings to improve workflow, training and organisational support rather than to stereotype employees. Discuss differences with teams before attributing causes. A credible implementation KPI helps an organisation understand reality instead of simply confirming the story it wanted to tell.

When a new process fails to take hold despite support, it does not automatically say something negative about employees. The reason may involve uncertainty, habits, an inconsistent group norm, missing skills, inadequate opportunity or a workflow that does not fit the work. The same low adoption score can emerge from very different mechanisms.

Do not start with another campaign. Start with the exact action you want to change. Observe the current task, explore what the new process means to employees and check the technical and organisational conditions. Then select a targeted improvement and test what happens to real behaviour, task quality and working conditions.

People do not need to be even more enthusiastic about a process they cannot use properly. They need a process that makes sense within their work. When the action becomes feasible, understandable, safe and relevant, expressed support has a better chance of becoming actual practice. That is not a guarantee of success. It is a more responsible way to investigate change.

Evidence boundary: These papers include models, reviews and empirical studies in particular settings. They do not establish that the fictional Rivierlijn company was studied, that a specific change would certainly work there or that a neural or association score could predict the implementation success of individual workers. The sector, design and context of the original evidence matter.

• Associations in behaviour change: why knowing is not doing
• Why does explaining a change rarely change behaviour? The missing step comes afterwards
• Neurofactor - research methods