Implementing Behaviour Support Plans: Building a Team That Applies Strategies Consistently

Behaviour support practitioners are in a special predicament in the disability sector: responsible for results produced virtually entirely by others. It's your assessment, it's your functional analysis, it's your plan, and then the fate of your plan is given to a rotating set of support workers, house staff and family members whom you did not select, may never meet, and may not be able to roster. If behaviours have not been changed as the review data indicates, the professional discussion begins with the plan, that is, did the strategies turn out to be correct? And it never goes to the central question in the discussion that makes the difference in most cases: was the plan actually followed, by everyone, consistently, as written? In implementation science, the difference has a label and in real life, it has an impact: plans that have been deemed to have failed were never actually tested and strategies that have been increasingly tightened up in response to the perceived inconsistency were not measured.

This series is focused on bridging that divide from the practitioners' point of view. This is the first of a series of articles that will introduce the discipline and the rest of the series will develop its tools.

Consistency is the active ingredient

Positive behaviour support will work, if it works, because it is predictable, the person knows that the world will now respond to their behaviour in a stable and understandable way; that if they want to learn a new skill, that will always lead them to a successful outcome; that the escalation pathway is always going to lead to calm, not chaos. Which implies consistency is not something you're going to have as a luxury around the strategies. For many strategies it is the mechanism itself and only a partial implementation makes it only partially effective, which can be the very condition the behaviour evolved to cope with. If someone implements a plan in four different ways, by four workers, then it isn't a plan. It is weather.

Design for the team you actually have

The implementation gap can be predicted, since the reasons for it are structural; a practitioner who designs for the real team, and not the ideal one, will close most of this gap at authorship. The real team is large, is changing and is not at all present at every training you run: casuals, new starters, weekend staff, fill-in workers, family members. The design responses are this series: a worker facing strategy summary that carries the plan in plain language, since there is a different plan document written for a different reader; a briefing gate, agreed with the provider, so no one supports the person unbriefed; training built for rosters, not for workshops; worker selection is a clinical variable; data collection is designed for the people collecting it; a monitoring habit of checking implementation before judging strategies. None of these are the business's responsibility or the practitioner's responsibility; that's why they don't work when neither one does.

Make implementation part of the engagement

The shift is practical rather than clinical, contractual, rather than operational, integrate implementation support into the way you scope behaviour support work. The minimum viable version is a plan plus a handover meeting; it is seldom sufficient when it comes to complex situations. The versions that work scope the implementation layer explicitly are written with this work in mind, as is the training of the core team, the induction of the briefing gate with the provider, early data review for drift, and the NDIS behaviour support funding. Sometimes practitioners do not claim the hours; sometimes they don't implement the plan; and sometimes they don't claim the hours and they don't implement the plan.

How this plays out in practice

Imagine a plan that is 6 months old for a person in supported accommodation, data flat and provider requesting more robust strategies. The neglected question posed and the mapping of reality is the implementation-first review. The practitioner and provider fix up the machine, but not the strategies: summary written, gate installed, core team trained, data simplified. At the next review the same strategies show the trajectory the functional analysis always predicted. It wasn't that the plan was the problem. It's just that it hadn't been done before.

Next steps

For your top plan that is stuck, execute that one query that changes everything: How many people supported this person last month and how many people were briefed on the current plan? The difference between those numbers is your clinical problem.