I’m just back from the Learning 2007 conference in Orlando, and I must admit I’m feeling overwhelmed by all of the change coming our way. The next generation is using technology to learn, work, play, socialize and be entertained all at the same time.
My mind has been reeling with questions about how this next generation, with a very blended lifestyle, is going to impact the world of work as we know it. How will companies change? How will people be managed and rewarded for the work that they do? How I am going to fit in with these people who approach work and life so differently?
At the conference, many people asked me where I was from and then if I was impacted by the I-35 bridge collapse in my hometown. I explained that I used to drive under the bridge daily, taking the same route and arriving at work at the same time. Now I have unexpected delays and detours because of other bridge inspections and traffic jams on the “back roads”.
As a result, I’ve found that I’m not just commuting anymore. If I’m stuck on a bridge for 40 minutes, I give my Dad a quick call to see how he’s doing. If I drive down a new road, I watch for stores and restaurants that I might want to try. I’ve been listening to new radio stations, smiling and waving ahead other drivers who look frustrated by the traffic, and finally learning how to look at my emails on my phone (don’t worry – only when traffic is completely stopped).
These are all things that I would have never done if the bridge hadn’t collapsed. The bridge collapse forced me to shake up my commute and think about it differently rather than be frustrated by the change.
I’m going to jot down ideas on how I might shake up my work as a result of the changes coming from technology and the next gen. I’d say “stay tuned”, but word on the web is that TV’s passé.
The always impressive Cathy Moore provides a great list of eLearning samples over at the Making Change blog.
This page alone would be a great starting point for anyone interested in eLearning. Actually, if you were an eLearning expert and just got back from a 90-day safari, you’d find things you’d never seen before.
Be careful, though; many of these pieces are dangerously engaging. Especially these paper-based videos from Common Craft. I’ve been telling everybody I know about these.
A colleague commented to me recently that one of my clients needed a “Dinosaur version and a 21st Century version” of a particular ERP software training course. Indeed, the audience for the course was as diverse as I’ve seen in almost every respect: generationally, culturally, politically, and in their level of computer literacy and years of experience with the organization.
This was an instructor led course and the content was primarily conceptual. The client had tried for a balance between traditional lecture and interactive exercises and games with the intent of trying to address a variety of learning styles during the one day course.
So, combine a widely diverse audience with a course presenting content in a variety of ways and, what is the feedback from the participants? Overwhelmingly, about half of the participants wanted more lecture and far fewer exercises and games and the other half wanted less lecture and more exercises and games. Interestingly, (or maybe not) the divide between these two groups was not so much related to individual learning styles as is was to age and years of experience with the organization. So, at least for this organization, the generation gap is the biggest one of all.
Thus the comment about the dinosaurs and the 21st century. But here’s the problem, a big part of the reason for making these people sit through a full day course was the get them to interact, share experiences, and learn from each other. Having two versions of the course would not help to achieve that goal. So what’s the solution? How can we avoid a classroom experience where half the class is bored and disengaged from the lectures, and the other half is annoyed at the forced participation in interactive exercises and games, which they see as a waste of time? How do we get to a level of interaction that is reasonably comfortable for everyone? I don’t have the answer yet. But, I’m working on it.
Bob Sutton, at Work Matters, outlines a strategy for encouraging innovation. The most notable aspect: awarding kill fees for bad projects.
Sutton cites evidence showing that creative geniuses are notorious for leaving long strings of failures in their wakes. However, their failure rates (their batting averages, if you will), are no higher than yours or mine.
[There is] little evidence that creative geniuses have a higher success rate than their more ordinary counterparts; they just take more swings at the ball … The most creative people — and companies — don’t have lower failure rates, they fail faster and cheaper, and perhaps learn more from their setbacks, than their competitors.
One barrier to the (ultimately effective practice) of failing quickly, is the “escalating commitment to a failing course of action.” We’ve all seen this: companies become so heavily invested in a project that killing it begins to seem impossible - even if they know that it might be the right thing to do.
Merck pharmaceutical has gone so far as to institute “Kill fees, [which] pay out serious dollars to scientists who pull the plug on failing projects.”
Ultimately, Sutton puts forth my favorite line: “reward success and failure, punish inaction.”
Reminds me of another favorite quote: “I’d rather get fired for something I did, than something I didn’t do.”
It’s doesn’t surprise me any more when “project success” checklists fail to include change management, training, and documentation. So, when they make even the bottom of the list, it feels like cause for celebration. Michael Krigsman at the Project Failure blog puts forth 6 tips to reduce IT project failures. Last, but not least, among them:
6. Change management, documentation, and training are important. To be successful, users must understand the project’s goals, status, and impact on their jobs. Many projects pay too little attention to training and documentation, especially when the project starts to run over-budget. This oversight reduces productivity and can negatively impact the project ROI. In extreme cases, users simply don’t use the new software, bringing the effective ROI to zero.
So, the last few words in the last paragraph tell us about something that can “bring the effective ROI to zero.” If that’s the case, why is it so often at the bottom of the list? Or, as Michael states, ignored once the project starts to run over-budget?
One hypothesis I have: Project success for the software team isn’t measured on user adoption - or ROI of any kind. Instead, they’re measured on functioning screens and transactions. It’s up to the business to actually use the stuff.
Reminds me of a health club membership; just spending a lot of money on it doesn’t make you lose weight — you have to actually use it.