I've moved my blog...

And all its contents over to my main website, jmilanes.com which has a whole new re-vamped look and where I decided all my writing and information should now be.

If you care to continue reading my stuff you can grab a cup of coffee and mosey on over there and make yourself comfy.

Blended Learning?

Pretty much all it means is combining different forms of learning (a teaspoon of this a smidgen of that):

• Live Training
• Virtual Live Sessions
• Recorded Training  - what in our team we call "on-demand" training
• User Guided and Manuals

There's been a lot of discussion recently about blended learning.  I'm surprised that its such a big deal now since we've been doing this for so long, just not in a formalized manner.

We have one person that travels and does live Workshops, to attend these workshops there's a list of pre-requisite classes.  This makes everyone at the workshop be more on the same page with knowledge regarding the software, so that less time is spent getting everyone up to speed on the basics.

We have a library of on-demand sessions that are recordings of previous live sessions through Webex, and sessions that were created through Captivate as Flash lessons.  We also have user guides and one page training tips.  This isn't even counting all of the training available through the vendor.

Does this mean we're done with a blended learning approach.  Not really.  In what I've been reading regarding blended learning we're missing a key item.  The "contract" between learner and facilitation team.  This would state, this is the learning that's available to you and spell it all out, and these are the goals that would be accomplished if you take these classes.  You can say we have in informal contract.  Take this training and you'll learn our software.  But it seems we need to get more specific than that. It would mean creating the recipe for the learning cake. 

Goals and Objectives... time to begin!

Evaluating Training

The dilemma I'm going through when it comes to evaluating training is that I primarily train on software.  I also manage the support line for said applications.  The question becomes, if I get more calls after doing training has the training been effective?  Who are the people that call?  Those that have taken the training or those that refuse to?  A hodgepodge of both?

Tomorrow I'm going to evaluate the effectivenes of some bi-monthly (as in every other month) calls I do with the key players in each office for one of our apps.  I noticed we had about 25% of the offices that didn't have a person represented in the last two calls.  Will these offices have fewer or more calls to the support line?  My guess is fewer.  If the key players show no interest in the bi-monthly calls there would be also less interest in the firm as a whole.  But I may be proven wrong -- they may just have no direction as to where to go for training and where to get guidance and call us even more.

There are the other measures of evaluating just run of the mill training through user surveys.  They work OK but they miss a key element in gauging how well people have learned the application.  If only I could record the mouse-clicks on the app of users before and after training and have some software tool analyze the differences.  Some computer nerd out there, do you hear me?

Training Pause and Time to Reflect

Now that I've had a pause in my daily training its given me the ability to now pause and think about the next phase in our training.

In this instance we're looking to move away from "funtional training" to process based training.  Instead of showing our users how to do specific tasks we want to move onto a process - a flow - which will incorporate pieces of the how to training.  By grouping the functional training into a process training we hope to create the a-ha moments for our users.

Thos a-ha! moments are the ones where the users finally gets the light-bulb going off and things just seem to make sense.  Currently, with the functional based training, the A-HA!s seem to be missing.  Many users leave with the feeling that they were just shown something great but how is it relevant to what they do and how can they incorporate this into their day to day.

Now on to create some of those A-Ha!s and lets see how many of those a-has of my own will come about through the process.

They are not the enemy

I've been on both sides of the fence. I started in IT then I crossed over to the dark side in 2006. What's interesting is seeing that "they" never know what they're talking about or what is really necessary.

They being the other ones that are not on your side.

Now that I'm in a support role I get to be the intermediary, not quite IT but not really a real "user". Our users see us as the obstacle to getting what they need and many times we get frustrated on our end trying to understand why they don't understand that we're only trying to help.  IT sees us as the ones that keep adding to a Christmas list of wants without taking into consideration that this is how the application works.

The best way to get around it is to never take it personal. I put myself in their place. There's a level of frustration involved mainly due to having a situation (the software application) that they can't control, for the users, and being overworked with few resources, for IT.

When I was in IT our frustration stemmed from the users not understanding the limitations of the software and wanting it all yesterday. Another part of it stemmed with the the ever changing user requirements.

But, in the land of end-user support it mainly comes from lack of understanding on both parts. Many times the user doesn't know what they want - at least what they want the software to do - and the support person has issues understanding why they need what they're asking for. Why on earth would they want to do that??? This is even more pronounced within IT. Without understanding the business processes, you can have as many bells and whistles in an application, but it doesn't mean anything for users if it doesn't get them what they need.

How then do we deal with this ongoing battle?

I don't know, you tell me?  We're still trying to sort it out. In the meantime, the most important thing is to not take it personal and try and put yourself in the place of the other person, be it IT or end user.

And make sure you have your Nerf gun fully loaded.

The Importance of Recognition.

Besides doing on-line training I manage a support team -- I hate the term "Help Desk" since it doesn't convey what we do.  We have a team of 4.5 people that help users of our applications get what they need.  We also get questions completely unrelated to the applications we support.  The expectation sometimes seems to be that since they received a great answer from us once we'd be able to help in all matters of technology. 

We launched a major upgrade to one of our applications last April.  It might as well have been an initial launch.  Many of our end users didn't even know the prior version existed!  We created new training, new guides, new support docs and hired 3 more bodies for the launch.

Since then we've been steadily work-work-working like happy little worker bees with no time to sit back and look at what we've done.  Last Friday a fellow team member (from a different department) mentioned what he'd seen done in call centers in the past - recognizing call achievement numbers.  For some reason I just think McDonald's ... over 2 million served!  Our achievement since last year isn't that high, but I was surprised to see that we've taken slightly over 10K calls since our launch last April.

10,000 for a team of 5.  About 700 calls per month.  May not seem like a lot for those of you that manage call centers but for our small team that has to assist people from soup to nuts in our application while still learning it themselves its no small feat.

I sent out the email to our team and CC'd our business partners recognizing them for taking on such a large number of calls while reducing calls abandoned or to voice mail.  Its a great way to show our support staff that their hard work hasn't gone unnoticed.

After the email I noticed they were in a better mood with slight smiles on their faces.  In these days where monetary recognition is almost impossible - a simple email can make someone's day and can be empowering.


Kudos to my team!

Making it Relevant...

You know the "What's in it for me?"  otherwise known as WIFM.  This is the hardest part of creating training on software. 

You want to show users all of the neat bells and whistles - how cool is this!  Look, I can post my emails straight onto the record.  It'll let me find people I worked with 20 years ago.  I can change the colors of my activities to Hot Pink!  Woot!  Well, none of it matters if WIFM isn't there.

I've found that adding WIFM is much harder when your trying to get people to learn about the "How-to's" of software.  Especially when you have the reluctant learner who's taking the class because his manager told him to. 

How do we cross the hurdle?  Relate back to something that they currently do manually without the handy dandy tool your about to teach them about.  

I recently had a trainng session with users that were moving from one office to another and had everything in file cabinets.  You know, the type where you get a paper cut whenever you're looking for someone's file from 1995?  The new location had 1/10 of the filing space.  They needed to figure out a process really fast to scan all of their documents electronically and store them in such a way that they'd be easy to find.  We now had WIFM.  But it doesn't always fall in your lap.

One I approach I've been using is ask the end users outright -- why are you looking for training?  It may take some prodding, but eventually the answer comes out.  Even if its "because my manager says I need it."  We must then look at what's in it for the manager that his employees use this piece of software to create WIFM for the end user.

Time and Money are the biggest reasons for us as adults to want to take on something new.  I can't help you make more money, but this is how I can save you some time.

You can follow some simple steps:

• Find out the current business process. 
• How are they currently doing the task that will be replaced by the new software? 
• How will this process be more effecient? 
• Factor in the learning curve -- it'll get worse before it gets better.  Be honest and upfront about that. 
• What can they do now that they couldn't do before? 
• WIFM is different depending on the person's role, find out what roles exist and what drives the different users.
• Finally - never assume you know what they need to know!