Apr 1 2022

Clarifying a Request for Services without Rebuffing the Requestor

The name of your department/function sends a marketing message to your potential prospects. If you call yourself Learning & Development, as one example, that suggests that that’s what you do.

Yesterday Greg Williams posted on LinkedIn about Cath Moore’s Blog Post titled: “Burn your training request form” – and while I liked where it was going – I would take acception to a bit of it. I really liked this:

If you must have a form, call it something like “development request.”
Make clear your job is to improve performance, not create training on demand.

This all took me back to some words of wisdom from the late Joe Harless from back in 1985. He spoke at an NSPI (now ISPI) Conference in ’85 and then had an article published in NSPI’s Journal – here.

I’ve written about this many times, in Blog Posts over the years, and most recently, in a new mini-book that came out this past month, on the topic.

My takeaways from Joe’s 1985 message were – don’t rebuff a request just because the solution has been presumed in the request itself. Say yes. Do some Analysis. And then see.

I also learned to find ways to make sure my client was along for the ride (journey) in some form or fashion. That usually meant that they handpicked my sources – so that would be more likely to believe the data that I brought back post-Analysis.

This Analysis output – modified from some work I did in mid-1980s – as an external consultant…

My client might not like seeing “an indictment” of management in the data – but if it came from, and represented a consensus from the people that the client (or better yet from a Project Steering Team) had handpicked – then there’s no place to run and hide from the data.

Also – as a consultant, I learned that the “Request” wasn’t always clear about who the training (as we called these things back in the day) was for.

Or what the multiple reasons for the request might be.

Perhaps there are some Performance Problems that need to be addressed – plus a need to address the flow of new hires that need something ASAP.

You don’t know until you ask – and maybe probe a little beyond the initial responses. And perhaps the Requestor is simply a messenger, sent by someone else to make the “Request” – and doesn’t know much more about the background – and there’s no need to make them feel bad about not having the answers I would seek.

Don’t Do Something Like This