I haven’t posted much about my Rapid e-Learning Challenge in awhile. That’s because the project suffered a few roadblocks and set-backs. All of them were related to things like poorly defined project goals, lack of agreed-on specs, and non-responsive SME/sponsor. It wasn’t my fault, the sponsor’s fault, or the janitor’s fault. It was a process issue. My learning team had not defined and agreed on a process for initiating this type of project. Starting an e-learning project without such a process is a bit like reading the flight manual after the plane is mid-air.

AT ANY RATE….after a bit of floundering and false starts, the storyboarding is complete. I’m back in the saddle and the project’s moving forward. Yay!  The other good news is that now I have a graphic artist to help with the look and feel and original illustrations where needed. We do have a good process for actual course development. With the planning obstacles out of the way, I’m looking forward to the really fun part of development. We go full-tilt with this tomorrow, and plan to be finished with a beta release in a few short weeks.

All that said, I still want to “test out” just how “rapid” rapid e-learning tools are (in my case, Articulate). As the project plows ahead, I will jot down things I like, things I don’t like, new discoveries (tools, ideas, etc), and lessons learned. I’ll also post any challenges and requests for help here. Blogging is a great way to reach out and get feedback or help from the larger community “out there.”

Rapid Lesson Learned: Don’t move forward with a project if you don’t have clearly defined and agreed upon goals, as well as SME and sponsor buy-in. 

In “The Leader’s Handbook,” Peter Scholtes suggests asking internal and external customers two questions:

What are you getting that you don’t need?

What do you need that you aren’t getting?

Several years ago, I asked similar questions of team members on an e-learning project that I managed. One of the things that the team clearly did not want was a detailed work breakdown report. Instead, they wanted an individualized report that indicated how much time each team member was allowed for each task in the upcoming week. As a result, I quit wasting time on reports that were not being read, and instead focused on a more useful tool that helped the team budget time spent on their tasks.

Try it yourself. Pick any ID or other process you are working on this week or, better yet, today! Now figure out who the customer is. Customers can be the team member that you hand your part of the process off to (such as when you hand a storyboard off to a programmer) or the final users of the product. They might be your manager, or your direct report. Whoever it is, ask them Sholtes’ two questions.

If you ask sincerely, you may be surprised at just how readily an answer comes. The hard part is to actually do something about it.