Wednesday, November 25, 2009

One Way to Move from Training to Performance

We keep hearing about how corporate educators need to transition themselves into performance consultants. Rather than agonizing over "how", maybe we should just keep our eyes peeled for opportunities.

Right now, I am working on a project where we are supposed to implement another module of a project management application that we are using.

One problem - there is no process, there is no policy, there is little configuration and there is no clear way to perform the tasks required.

Oh yeah, and no one wants to do the decision-making.

(We are going to ignore the conversation about whether we have the right tool to solve the actual problem. Or what the real requirements are. This is another instance where we are trying to fit the problem to the tool. This retrofitting scenario is more common than the "get the right tool for the job" one.)

First approach - freak out and ask the subject matter expert exactly what they are supposed to train. Continue asking same question until
a) the project dies
b) process, policy, configuration and concrete steps are established and the trainer can "do his/her thing" or
c) the SMEs and other project team members get disgusted and whine to upper management about your bad attitude.

Second approach - since the folks were kind enough to invite the trainers early in the process (which doesn't always happen), take advantage of the opportunity and start facilitating actual process improvement.

Heck, they expect the trainers to ask stupid questions and get it all wrong anyway. Let's embrace the process!

Ask stupid questions

So what is this new tool supposed to do for us?

How do we know if this process is working? (Please refrain from snickering when the SME looks you square in the eye and says "When the number of people consistently using the tool increases).

Get it all wrong

Rapid prototyping is where it is at.

When I have no idea what I am doing - I go to the cryptic vendor documentation.
I then place myself in the end-user's shoes.

If all I had was this documentation and was told to do X, how would I approach it.

I then write it down, along with any questions that came up in the process and pass it to the team. Often, the questions are related to the process, not the actual technical button-pushing steps.
- Who is responsible for this piece?
- Is there a reason we need to do Y?
- Is there a way to make this process less unwieldy? Easier to explain?

The team then tells me where I am wrong.

Conversation is good.

If the conversation goes well, you wind up involved in a very rich process and performance improvement discussion. "Training" may or may not result. And that is OK.

If the conversation goes poorly, you have the documentation that it's not "Training's fault".

Thankfully, in my current job, the conversations go well.


It is these small opportunities on awkward projects that will prove to the rest of the organization that we are capable of increasing value and allow us to make the transition from Training to Performance.

No comments: