It wasn’t an AprilFool’s and yet Jay has a point – it is silly to assume that formal training will be the white knight to rescue the day.
My advice, for whatever it’s worth is this.
Assume clients (internal and external) will want it now and and figure out a way of responding to it. Instructional designers are service providers. Usually our organization expects us to service the requests of other business units, especially the ones that generate revenue.
When I managed a team of internal 12 instructional designers and trainers, we went through an exercise where we mapped our time and figured out how to deal with this situation, because everyone always thinks their issue is the biggest/neediest of all. I can’t say we really solved it, what we did do was “mutli-pronged”:
- Worked out a system where we had more “wiggle room” in our schedule – plotting out our time, accounting for meetings, vacations, business cycles and estimating how much time we had already accounted for with corporate proejcts
- Worked to try and uncover some simmering issues during business planning cycles, rather than waiting for it to jump up at the least opportune time – when business units were putting forward product ideas or system changes, we assumed that training would be required!
- Planned our work so that we had chunks of time to tackle new projects – development time
- Options – we wanted to work with our internal clients that helped them find ways of addressing their need without comprising the integrity of the overall quality of our internal learning. We talked up performance support a lot.
- Educated business unit leaders – we did road shows, we wrote “position papers”, we worked with IT and product development. We got folks thinking about training in broader ways and not as an afterthought. We also involved them extensively in the process so they could see how it all worked.
- Beefed up our consulting skills so that we could work with our internal clients on performance issues, and help educate them on the range of things that could be driving the behaviour.
- Tried to build templates to speed up the development process if we did go down that path
- Developed organizational standards – for example, systems roll-outs had a “standard” approach, with some contextual twists, but we pushed for context sensitive help (either as an addition to the software purchase or the ability to D-I-Y), we also provided business leaders with figures to work with in terms of development time or average costs. Sometimes we even attached resourcing dollars to their requests.
- Used other rapid development options to try to speed things up if it was still needed!
Many times I think we fight a “moral” issues around IF we should do training, but sometimes maybe it would be more helpful to just figure out things from the process end.
What do you think? Am I just rolling over on this one?