The Best Way I’ve Found to Give Feedback on a PBSP

Introduction

Feedback.

Some people say they struggle with it. Other people say they appreciate it. And some people say they appreciate it when they're trying to get employed, only for us to discover later that they don't particularly enjoy it either.

Personally, I've never been one of those mysterious people who genuinely seems to enjoy receiving feedback. For me, the worst part is often the uncertainty. It's not necessarily what someone has said — it's waiting to find out what they're going to say. How much have they found? How are they going to phrase it? Am I about to open a document containing three comments...or 73?

So when Supervisees tell me they're nervous about sending someone their work for review, I get it. But over time, I've started to wonder whether the problem is always the feedback itself.

I think how feedback is delivered matters enormously. Who is giving it? How well do you trust them? Is it delivered kindly? Do they notice what you've done well as readily as they notice what needs changing? Do their comments help you understand why they're recommending something? And when you finish reading their feedback, do you feel as though you've learned something — or just feel like you've done a terrible job?

I've been on both sides of this process many times now. I've had my own PBSPs reviewed, and through my work as a Supervisor and leader of a BSP team, I've also reviewed a lot of other practitioners' work. And I've gradually developed my own approach to giving feedback.

When I'm reviewing a PBSP, I'm actually thinking about two things at the same time:

• How can I help make this PBSP as good as it can be?

and

• How can I help this BSP become better equipped to write the next one?

Because I don't think a good review should simply identify everything that's wrong with a document. Done well, reviewing can be a form of practitioner development. It can reinforce what someone is already doing well, strengthen their clinical reasoning, identify their next areas for growth and help them think more deeply about the participant they're supporting. Sometimes you can even sneak a little training in there without them noticing (my favourite kind of training).

So in this article, I'm going to take you through the process I've developed for reviewing PBSPs and other practitioner documents — including the questions I ask myself while I'm reviewing, how I decide what is actually worth commenting on, and the final check I do before I send a document back. I'm not suggesting this is the way you need to give feedback. It's simply the approach I've developed through experience, and one that seems to work well for me and the practitioners I support.

Before We Get Into the Feedback...

This article focuses on how I give feedback when I'm reviewing another practitioner's work. Of course, there's another question sitting underneath that: What am I actually looking for when I review a PBSP?

I've explored that separately in What Does a High-Quality PBSP Look Like?, where I talk through some of the things I consider when thinking about the overall quality of a Behaviour Support Plan. The two skills really go hand in hand. First, we need to be able to recognise where a PBSP is strong and where it could be improved. Then we need to work out how to communicate that to the practitioner in a way that's actually useful.

Before I Start: How Am I Going to Give the Feedback?

Before we even get into what I'm looking for when I review a PBSP, it's worth thinking about how the feedback is going to be delivered. Personally, I prefer to write my feedback directly into the document using comments and tracked changes. I've experienced live document reviews where I've sat with a Supervisor while they worked through my PBSP and gave feedback as they went.

Let me tell you, I did not have a good time.

That's not to say live review is inherently a bad approach. Some practitioners might actually prefer being able to discuss feedback immediately, ask questions and work through changes together. But for me, written feedback has a few advantages. It gives me time to think carefully about what I'm actually trying to say. I can consider my wording, decide whether the comment is really necessary, give an example or resource where it might help, and make sure I'm not focusing so heavily on things that need changing that I've forgotten to point out everything the BSP has done well.

It also gives the practitioner some control over how they receive the feedback. They can open the document when they're ready, work through the comments at their own pace, and then bring questions back to me afterwards.

Whatever method you use, I think the important question is:

• Will this method help this particular BSP understand and use the feedback I'm giving them?

Once I've decided how I'm going to provide the feedback, I start reviewing. And as I read, there are a handful of questions I continually ask myself.

1. Prioritise — Does This Actually Need a Comment?

This is probably the question I ask myself most often while reviewing: Is this actually important enough for me to point out?

Not every imperfection needs a comment. If I notice a minor typo and I have an editable version of the document, I'll usually just correct it using tracked changes and move on. But if the BSP has accidentally used the wrong participant name or referred to someone using the wrong gender? I'm going to point that out.

Why? Because that's no longer just a tiny editing issue. It could undermine the credibility of the document and, more importantly, affect how the participant or their family feels when they read it.

The same principle applies to clinical feedback. I might notice something that I personally would have written differently, but that doesn't automatically mean the BSP needs to change it. So I try to ask myself:

• Is there actually a problem here?

• Why does it matter?

• Will changing this improve the quality, usefulness or readability of the PBSP?

• Will this feedback help develop something important in the BSP's practice?

If I can't identify a good reason for making the comment, I need to consider whether it needs to be there at all. This is particularly important when you're reviewing someone else's work because it's very easy to accidentally start turning their PBSP into your PBSP. There are often multiple reasonable ways to explain a concept, structure a strategy or approach an aspect of a plan. My role as a reviewer isn't to make another BSP write exactly the way I would. My role is to help them identify the things that genuinely matter.

That distinction becomes even more important as the number of comments starts adding up. Every comment asks something of the person receiving it — their attention, their thinking, their time and sometimes their confidence. So I want to spend those comments on things that are actually worth their attention.

2. Explain — What’s the Best Way I Can Provide This Feedback?

Once I've decided something is important enough to comment on, my next question is: What's the clearest and kindest way I can explain what I'm recommending?

I don't think useful feedback should leave the BSP staring at a comment thinking: “Okay...but what am I actually supposed to do with that?” If I'm recommending a change, wherever possible I want the practitioner to understand what I'm suggesting, why I'm suggesting it, and what that might look like in practice. Sometimes that means providing information. Sometimes I'll link them to a resource that explains the concept in more detail. Sometimes I'll give them an example of how they could approach it. And sometimes I'll acknowledge that they've come across something genuinely difficult.

For example, instead of: “This strategy isn't clear.”

I might write something more like: “I like the idea behind this strategy, but I wonder if we could make the instructions a little more specific for the implementer. If I was a new support worker reading this, I'm not sure I'd know exactly when you want me to use it or what you want me to do. Could we add an example here?”

Or instead of: “You need more evidence for this hypothesis.”

I might say: “I can see how you've reached this hypothesis from the information above. I'm wondering whether we have enough evidence yet to be confident this is the primary function, though. Is there any additional assessment information or data we could use to explore this further?”

Those comments are still feedback. I'm not avoiding the issue or pretending something is great when I don't think it is. I'm just trying to communicate the problem in a way that helps the BSP think about it and do something with it.

I also tend to use fairly conversational language in my comments. If something is a genuinely tricky area, I'll say so. If I've had difficulty with something similar myself, I might mention that too. I don't want the BSP to feel as though I'm sitting somewhere above them marking their PBSP with a red pen. We're both looking at the same participant and asking: How can we make this better?

That matters to me, because the goal isn't simply to get the BSP to accept my correction. I want them to understand the reasoning well enough that they may not need the same feedback next time.

3. Reinforce — What Have They Done Well?

One of my personal rules when reviewing someone's work is that I don't want my feedback to focus only on what needs changing. I want to actively look for what they've done well too.

As BSPs, we spend so much of our practice thinking about strengths, skills, goals and building on what's already working. I think we should extend some of that thinking to the practitioners we're developing. So if they've explained a strategy particularly clearly, I'll tell them. If they've created a fantastic behavioural frequency graph, I'll point out what I like about it. If they've made a really thoughtful connection between their assessment information and their hypothesis, I want them to know.

And if I finish reading a PBSP genuinely thinking: “This is a really good plan. I think this could work well for this participant.” I'll tell them that too. But there's an important distinction here; try not to stop at: “Good job!” or “Nice work!”. Those comments are lovely to receive, but they don't necessarily tell the practitioner very much.

Instead, tell them what they did well. For example:

“This is a really clear description of the strategy. I particularly like that you've explained when staff should use it, exactly what they should do, and given an example. I think an implementer could pick this up and know what you're asking them to do.”

Now the practitioner knows why it's good. And that means they're more likely to recognise and repeat that quality in their future work. Positive feedback isn't something I add just to soften the negative comments. It's feedback too. It tells the BSP which parts of their practice are working and what I want them to keep doing.

And there's another reason I think this matters. If someone opens a reviewed PBSP and sees 25 comments — and every single one identifies something they've done wrong — it's very easy for them to conclude: “Wow. This must be terrible.” But that may not be remotely what I thought when I reviewed it.

Perhaps 90% of the PBSP was excellent and I simply commented on the 10% where I could see opportunities to strengthen it. If I don't communicate the first part, how are they supposed to know? So I try to make sure my comments reflect the whole piece of work, not just the parts that caught my attention because they needed changing.

4. Develop — Can This Feedback Help Their Future Practice?

One of my favourite things about reviewing PBSPs is that I get to explore the participant's situation alongside the BSP. I'm not only looking at what's already been written. I'm also thinking: Where could this go next?

For example, I might notice that there seem to be a lot of possible sensory factors throughout the assessment information, but these haven't been explored in much depth yet. I might suggest this as something the BSP could investigate further. I might read through a skills-building strategy and see an opportunity for where that skill could be developed next. Or I might read a fantastic strategy and immediately start thinking about how we could get it off the page and successfully implemented in the person's everyday life.

None of those things necessarily mean there's something wrong with the PBSP; they're opportunities to extend the practitioner's thinking. And this is where I think reviewing someone's work can become a really useful form of practitioner development. Instead of the review being entirely about: “What's wrong with this document?” it becomes “How can we make this better, and where could we take this next?”

A PBSP isn't the end point of our work with a participant. We still need to implement it, evaluate whether it's working, continue learning about the person and adjust our approach as things change. So when I'm reviewing, I want to help the BSP think beyond simply getting the document finished. Sometimes I'll ask a question rather than give them the answer.

• “How could we find out a little more about this?”

• “Who do you think is going to need support to implement this successfully?”

• “How are you planning to introduce this strategy to the participant?”

Those questions give the BSP an opportunity to do the clinical reasoning themselves. Of course, there are also times when I'll simply give them a recommendation, particularly if it's something they haven't encountered before or I think some direct guidance would be more useful. The goal isn't to turn every comment into a test. It's to think about what will help this particular practitioner develop at this particular point in their practice.

This is also one of my favourite ways to sneak training into someone's day without them even realising they're being trained. Because if reviewing one PBSP helps someone approach their next participant with a slightly broader perspective, ask a better question, plan further ahead or recognise something they might previously have missed, then the review has achieved much more than improving one document.

5. Review the Review — What Will It Feel Like to Receive This?

Once I've finished reviewing the document, I don't usually send it straight back (unless it's 5pm on a Friday and I've been staring at the same PBSP for three hours). Usually, though, I go back through my own comments one more time. At this point, I'm no longer reviewing the BSP's work. I'm reviewing my own feedback.

There are three things I'm particularly looking for.

• Have I Got the Balance Right?

I look at the overall mix of comments I've made. Have I identified the important areas for improvement? Have I pointed out what they've done well? Have I given them something useful to think about for their future development?

I don't try to manufacture positive comments just so I can achieve some perfect positive-to-negative ratio. But I do want to make sure my feedback reflects my genuine impression of the document. If I thought it was a good PBSP, will the BSP actually know that after reading my comments?

• Have I Written Too Much?

Look, I'm quite chatty and sometimes that comes across in my reviewing. So I always check whether I've gotten a little carried away with the number or length of my comments. I ask myself: Is the BSP going to open this document and think, “Oh my god, this is too much”?

If the answer might be yes, I go back through. Can I make this comment shorter? Have I explained the same concept three different times? Can I address something once and ask them to apply it throughout the document? Does every comment actually need to be there?

I almost always end up editing or removing a few.

• Have I Focused on the Priorities?

This is probably the most important final check. There might be 20 different things I could help this BSP improve. That doesn't mean we're going to tackle all 20 today. I need to think about what's most important right now. What needs to change for this to be a good-quality PBSP for the participant? What represents an important gap in the BSP's practice? What can wait? What might be better explored in Supervision rather than through another comment in the document?

Trying to address every possible area for development at once can very quickly become overwhelming — particularly if the BSP is already feeling demotivated or working against a deadline.

My priority is always twofold: Get a good-quality PBSP out to the participant and keep developing the BSP who wrote it. We can work on the rest bit by bit.

Conclusion

Giving good feedback is a skill. And just like writing PBSPs, conducting assessments or delivering training, I think it's something we get better at through practice, reflection and paying attention to what seems to work for the people we're supporting.

The PBS Capability Framework itself recognises feedback as part of PBS practice. Within the Implementation domain, feedback appears in capabilities relating to supporting implementers, and at Proficient level and above practitioners are expected to understand different methods of giving feedback.

Reviewing another BSP's PBSP isn't exactly the same context, but I think many of the same skills apply. We need to think about what we're trying to achieve, who we're giving feedback to, how we're communicating it and whether what we're saying is actually helping the other person improve their practice.

For me, the process I've developed comes down to five things:

1. Prioritise — Does this actually need a comment?

2. Explain — How can I communicate this clearly and kindly?

3. Reinforce — What has this BSP done well?

4. Develop — Can this feedback help their future practice as well as this PBSP?

5. Review the Review — Is my feedback balanced, manageable and focused on what matters?

I'm sure my approach will continue to change as I keep supervising practitioners, reviewing documents and receiving feedback myself. But there's one question I keep coming back to: How would I feel if someone gave this feedback to me? That doesn't mean avoiding difficult feedback. Sometimes we absolutely need to tell someone that something isn't good enough, that an important area has been missed, or that something needs to change before a PBSP is ready to be implemented.

Kind feedback isn't the same as meaningless feedback. We can be clear about a problem while still being thoughtful about the person receiving that information. And ultimately, that's what I'm trying to achieve whenever I review someone's work: A better PBSP for the participant, and a BSP who feels better equipped to write the next one.

Want Support With PBSP Review?

PBSP review can be useful for much more than checking whether a document is ready to go. Done well, it can help you strengthen your clinical reasoning, identify areas for development and understand not only what you might change in your work, but why. PBSP review is something I regularly incorporate into my PBS Supervision, alongside reflection, professional development and support with the challenges that come with everyday practice.

If you're looking for a Supervisor who can provide practical feedback on your work as you develop, you're welcome to book a free, no-obligation chat with Rebecca to see whether we might work well together.