I wish we could grow some _ _ _ _ _!
I have this recurrring nightmare that I’m on a team where everyone else defers to the dominant individual in the group rather than offering forth their own opinions, but then again I also have this dream that I’m escorted into a room with two men from HR dressed in clown outfits who then cheerfully let me know that I’ve been laid off.
However, I work in the training field in a large engineering-based corporation. Both dreams at some point are bound to become reality. I’ve observed this rather unsettling tendency of training organizations within our company to agree completely with the needs of the customer and give them exactly what they want or feel comfortable with in terms of training interventions. In our case, this often takes the form of printable hand-outs, job aids, powerpoint slides, linear simulations (when the process being trained is not linear).
In my experience here, proposals to use training solutions that are slightly new and out of the ordinary are usually rejected, especially if they require a little more resources and more time, thinking and involvement from the organizations and trainees. Their expectation often is that “Training will teach them exactly how to do something,” and not how to work with the tool or process or effectively make decisions on how to troubleshoot. The are more interested in having tangible items like a job aid or desktop manual rather than being taught “how to fish on their own.”
More, good training requires detailed information and interviews of subject matter experts on the process. This requires time that SAP developers, and project members often are not willing to give. Time is always an issue. If they even decide that they can afford the luxury of even having training, training usually gets the table scraps of time and resources.
And I can only think that they (THEY = the project team, the application developers, the business analysts, the content experts, the stakeholders) believe the following about training:
- Training is so simple to develop, anyone who can draft up a step action table can develop training
- Training is an afterthought that happens after we crank out the design, so the time needed to give to training is expendable when it comes to dealing with problems in the design*
- Training isn’t that important, it’s the application
- Yet at the same time…. training can be used to mitigate the flaws in the design (!@%$!)
*Which in my opinion is why they should heed the suggestions of the HFE (Human Factors Engineer)
But in all honestly, I feel that we here within haven’t truly put forward a good case for what these folks are missing when it comes to understanding the importance of good training. We tend to bend over backwards to give them what they want because we don’t want to be perceived as difficult, uslessless and therefore targets for downsizing by clowns.
Part of me believes that this is a vicious cycle, and we’re (Training) acting out a self-fulfilling prophesy around our lack of perception around our true value. Maybe it’s me, but instinctively it seems wrong to let others outside of yourself define your value, because that’s the first step to them assessing that you have none.
Earlier this year at a conference, I heard a very brave individual speak up and suggest that perhaps training groups need to take a stand and show their customers what happens when they don’t intervene…sort of like going on strike… but it’s kind of hard to refuse the demands of your patrons when they hold the pursestrings of your existence wound tightly around their hands.
I’m going to start with coming up with a presentation that illustrates what happens if you skimp on training and point out some historical examples. It’s a start at least.