Many slides had a link to an external page for "References", which lead to a whole new page with about three lines indicating the section numbers in their reference manual.

There wasn't much space to show the different elements on the page because the company logo and abstract graphic took up 1/3 of the viewing area "above the fold."

THE PROBLEM(S) 
Can you see where the problem(s) started? Not with the WBT project, there were preexisting problems.

Lack of understanding their learners.
We firmly believe that learners learn from people they respect. The training department and its trainers were not respected by the engineers, even in the classroom presentation. Why? Because training hadn't earned the respect of the engineers. They never asked "What information do you need?" They never asked "How to you reference information? They never asked them anything, and they never asked themselves "How would these learners prefer to learn?" "What is the problem we need to resolve.?  "Is this training necessary?" Our impression is that the engineers would have found a searchable reference document more appropriate to their needs. Great ROI for the training department because they could have "saved" most of the cost of this project.

Lack of understanding the environment.
We were the only resource that actually used the web as a learning and information tool, but we were buried under 3 contact layers. That was ineffective so we called a meeting, pointed out the significant problem areas that could be controlled at that point, and received permission to make some changes.
  
   Page - Since the top 1/3 of the page was taken up with the logo and abstract graphic, there was very little room for actually displaying the content which creating the perception that their focus wasn't really on helping their learners learn.

  Menu - The initial menu listed the most important information - the core content - on a submenu that some could see, some couldn't see. Some modules had up to 19 sub modules that weren't listed at all, not even on the "Introduction" page to a module. Many of the pages had the same title so it was difficult to know which module you where within when you were on a particular page.

   Audio/Video - WARNING: Video people usually use Macintosh computers because of their native sound and graphical abilities. 95% of the rest of the world does NOT use Macintosh computers. Apple Computers created the Quick Time format and Macintosh computers so most Macintosh users used Quick Time for their video/audio needs. Quick Time is an excellent format but it was not a standard at this company, nor for most users. For each "learner" to use this CD, they would have to have gone to an internet connection, and download/install the Quick Time plug-in. However, the company did not allow their employees to install software and Quick Time was not on the "approved" list.

  Reference Link - Opening up a new window each time the link was pressed meant that we have to create a new page or a new anchor on a reference page for each reference. Plus, opening up multiple new windows would be annoying to the user and use memory resources.


WHAT WE DID  


  Page - We made the logo and abstract image smaller and placed it in the upper left. We figured the engineers knew which company they worked for and the graphic didn't add any context. We also removed "Learning Objectives" because this was to be use for learning and as a reference tool.

  Menu - We couldn't convince the company to put the module names as primary links on the menu. However we were able to convince them to add a "Site Map" that would show the organization of the modules and sub modules. We also located a very inexpensive search tool and added searching capabilities to the CD. Another navigational tool that we added was a "breadcrumb" script (like the one in the upper right of this page) that showed what folder/module and page they were on. Each displayed link is clickable and can serve as a quick link way to move back through a path. We also wanted to put "Course Requirements" under "About this Course" but they already had a video referencing those as separate links.

   Audio/Video - WARNING: The company hadn't standardized on a choice between Real Player or Windows Media. Their standard browser was Netscape so Real Player was considered. But, most of their software standards are Microsoft applications so we chose Window Media Player. We also made sure that the controls were visible to turn off any annoying audio. We couldn't control the quality of the video, which was poorly compressed.

  Reference Link - Instead of linking a new browser window for the reference information, we used a pop up layer approach. This way we didn't have to worry about managing many separate link to files.

WHAT COULD HAVE BEEN
Dynamic Approach
Since each page used a template and the same amount of elements, it would have been easy to develop an underlying database to present the elements based on a search or choice of links. That would have removed the need to hand code 200 pages for the Reference link layer, attach the appropriate graphic/video/audio elements, and the "Next" "Back" buttons. This would have saved tremendously in the development stage in time and expense. The static, linear approach meant that at least 7 pages had to be changed each time an element changed. Audio & Video elements would have been offered as a drill down option. Or, there would have been no video because it was less effective than a static picture that was properly lit or a drawing. Plus, the engineers were using laptops which make it more difficult to view images.

Performance Approach
We would have investigated what was problem/need this was supposed to resolve. If our impression about the true need being easier to find reference material was correct, we would have removed all linear navigation, embedded the graphs, video, and audio into a transformed reference manual and added advanced searching tools. ROI would have been greatly increased and usability would have been enhanced.

THE BEGINNING
We were asked to help a training company that had a contract with an eCommerce company create and deliver technical training to their new developers. The training company didn't have the technical expertise to understand the eCommerce services, using XML, and the mess had grown to the point where the training manuals wouldn't even print. The training development had slide to 2 versions behind and the eCommerce company wasn't very happy. Since the training was highly technical and the eCommerce company did have the technical staff to deliver the training, a very select group of external technical trainers were hired from several areas and countries.

The eCommerce company had about 26 different applications and about 1/4 of those applications were upgraded every quarter. They had some very large, international partner/resellers and their clients were also very large international companies. This meant that many training sessions had to happen in other countries and documentation had to be shipped to those locations. Logistics were a nightmare, plus different clients were using different versions at different locations.

THEIR APPROACH
The training company had created different teams for different applications with one project manager to oversee the training development process. Team A was working on training about the customer interface so it wasn't highly technical, however Team B and Team C had highly technical applications and each had a different external technical developer/trainer. Team B's external developer/trainer was located in Minnesota and developed great reference manuals but lacked presentation skills. Team C's external developer/trainer was located in Georgia and was a very charismatic trainer who detested writing.

THE PROBLEMS
Lack of Technical Expertise
Since the training company didn't have any internal technical people, there was a lot of turnover in project managers. They tried using traditional ISD to transform the 300 printed pages "Developer Guide" and the 300 page "User Guide" into 300+ page training binders, but then the question was "why bother with the training?" Also, the Documentation Group didn't have any technical people on staff and the Application Design developers wouldn't talk to them, so the they were a bit behind and a bit fuzzy on what they were documenting.

Cost of Materials
For each course, a 300 page "Guide" was supplied, plus a 250 page "Training Guide". Classes in other countries were being scheduled w/o much lead time so printed and shipping the appropriate materials was a large challenge. We were able to get enough ahead of the curve to keep an inventory of printed materials, but every quarter most of those materials became obsolete.

Learners were Not Homogenous
The eCommerce company was hiring about 15 new developers every 2-3 weeks. These developers came from a wide variety of experiences, some had just graduated, some had been developing applications for over 5 years.

Development Time
The training company was waiting for the Documentation department to furnish the "Guides" so they could develop the "Training Guides", the Documentation department didn't finish their Guides until 1-2 months after the new version was issued, the Training Company then needed 1-2 months to complete their transformation.

No Reusability
Each new version required starting from the beginning. There was no reuse of information from previous versions. No reuse of information from beginners to advanced modules.

Linear Only
Developers had to take the class when it was scheduled and attend each session, and received all "Guides" no matter what their background or function was to be.

WHAT WE DID
After we got the current printed materials reformatted so they at least printed, we started over using web tools and incremental, iterative methods (R.A.D.) We started with a blended learning approach using the web pages to replace the printed training materials and "Guides"

Lack of Technical Expertise
We located and hired local technical gurus - the kind that can make data dance. The Project Manager that we used had a technical, web and training background. Since our tech people could "talk tech", the Application Design developers became very open, allowed us access to the source code and let us know what was in the works and what was planned for the future. This helped us project from quarter to quarter the impact on the training versions. In many cases we helped debug and correct the applications before they went "live".

Cost of Materials
We scrapped the printed training materials and used a 28 page handout that the learner could use to take notes on, and made a PDF copy available for remote learning sessions. The User and Technical Guides were created in FrameMaker so we could take each version of that documentation and "Save as HTML". FrameMaker embedded anchors by Chapter and Module header so it was very easy to create links to that documentation in the appropriate places of the online training and to offer drill down capabilities to the learners who needed more detail about a particular concept or topic area. Since the learning presentation and support materials were on an intranet, there was no longer any need to ship materials. That savings alone paid for the online development process.

Learners were Not Homogenous
Since there was a wide variety of experience levels, we created extra learning modules so that a Facilitator could either begin on a more elementary level or expand to a more advanced level, depending on the group needs. If only 1-2 learners needed the elementary information, it was available for their use before/after the next session so they could "catch" up. The same opportunity was offered for the more Advanced developers who wanted/needed a higher level of information. We also encouraged peer-to-peer training when the experience levels of the group were too varied. Advanced peers would use the materials to facilitate the beginners. This helped to keep the group progressing together while reducing confusion and boredom.

Development Time
Since we had a tighter relationship with the Application Design developers, we were able to create documentation and send it to Documentation department for inclusion in their materials. That also helped integrate the two types of presentations and avoid unnecessary repetition.

During each meeting with the Application Design developers, we were able to show them what we'd developed and ask for a quick "Is this right, if not where is it wrong?" determination. This made our use of their time very effective, we could quickly discuss a tangible presentation and polish it. Also, for the first few iterations, we presented the materials to groups composed of learners from all areas of the company, not just developers. The Project Manager attended each presentation and was able to make any necessary changes to the presentation materials as the session progressed. This way, we could check and make sure the changes matched the suggestions of that group.

No Reusability
In addition to offering materials that could be used/reused from Beginning to Advanced levels of developers, we added an experiment that was very successful.

We developed the modules so that they could be used for internal developers, client developers and partner developers which greatly enhanced ROI.

Did we stop there? Heck no, we also created the web materials to also support other functional areas such as client services/support, client development teams, marketing and partner marketing. Now the positive ROI became almost limitless. Not only were we "creating once and using many" but we were also supporting product marketing and client service. With that approach, we increased the company's overall strategic value to their clients and partners.

How do we know we did that? Remember the focus groups from different functions that we used during development? During those focus groups we heard from Client Support "I'll just send a link to this "module" to our client to help me explain how that works", from Marketing "I never knew we did that", from Team Development "I'll use "module" to explain to the client why we need to do it this way", from Marketing "I didn't know we could do that, that's neat." We also started hearing about links to certain pages being sent internally, and to Partners, for reference use, instead of the 300 page "Guides". What's the ROI of forwarding a link instead looking through a 300 page book, mailing the book to the person who needs more info and typing a cover letter to tell them where to find the information?

AND, since some of the applications were very similar to other applications, we simply created new "shells" for what was different. There was a lot of basic, core information that was deemed reusable.

Linear Only
Since people were forwarding links to the materials around the world, it was obvious that our navigation made it easy to reference and learn only the topic/concept needed at that time by that audience. There wasn't a "Next" or "Back" button in the whole project.

SUCCESS!
We achieved all of the above, and a few more things, under the budget that was just for the developer training and we were on time!

EPILOGUE
Unfortunately, in the midst of the project, the Commerce company decided to hire some "TRAINERS" that we could train and then we could progress to other projects. Why unfortunately? Because the trainers they hired didn't even know how to use email, much less understand web based development and information flows. They were so confused when the Application Design developers wouldn't return their phone calls.

The TRAINERS were a bit upset that people were learning without going to regularly scheduled classes. When last seen, the "TRAINERS" were busily reformatting the old paper training documents, inserting incorrect information, and trying to find the cheapest printers and international shippers. We heard a rumor that the employees had copied our web site to their local computers and were still using it, but that's a secret.

That eCommerce company became a dot.com bust.


WHAT COULD HAVE BEEN
The next logical step would have been to break out the individual objects and create some communities of interest that would have allowed the learners to comment and upgrade the materials, or at the minimum, use some Knowledge Management tools to determine who knew what and to support the distribution of their expertise.

All right, we admit that this hasn't really happened - yet. It's a fantasy combining the best parts of past eLearning & KM projects.

It begins with an email or a phone call, "We've got a mess.  Our customer support center is drowning in unhappy clients.  Our employees spend most of their time trying to find "lost" information.  Our sales people don't understand what they're selling.  Our training department is telling us it'll be 6 months before they have the next product training class ready for presentation."

Our response? "When and where? We'll be there."

Once we arrive we'll ...
     Talk to employees in different functional areas and ask "What do you do, how do you do it, what information do you use, what information do you need that you don't have?"    

   Talk to management and ask "What do you do, how do you do it, what information do you use, what information do you need that you don't have?"

     Talk to clients and ask "What do you do, how do you do it, what information do you use, what information do you need that you don't have?"

     Talk to partners and/or suppliers and ask "What do you do, how do you do it, what information do you use, what information do you need that you don't have?"

From this information, we can begin to map out priorities and project definitions.  We'll identify what content is cross functional to determine levels of reusability and where there are existing resources that are already available. We would also learn about organizational, functional and individual priorities and determine where they are aligned or disconnected.

Culture
We would also be evaluating the overall culture of your organization and it's ability to adapt and share. Since this is a fantasy, we'll assume that the organization, and it's inter-organizations are able and willing to progress to an adaptive learning environment. We admit, most of this information will be collected from walking the corridors, sitting in the break rooms and eavesdropping on what the employee's are complaining about. It's the best easiest way to pick up culture clues, plus how the organization is physically arranged and what type of performance reward system(s) is used.

Infrastructure
Next we'll look at your current infrastructure and evaluate boring things like types of applications, data sharing systems already in place, and other technology stuff to determine what type of approach isn't too small or too big, one that's "just right."

Needs Assessment
From all this (can be done in a week) we'll be able to make solid recommendation on how to get from where you are to where you need to be. Notice we didn't say "where you want to be". It's been our sad experience that if someone tells us where they think they need to be, it's rarely real. After puzzling over that for many years, we've determined, that because we have a wide background in different industries and with different processes, we can see options that aren't apparent in an internally completed needs assessment. It's difficult to know you need something if you haven't see it or heard of it. What's Hannibal Lector say "We covet what we see every day." If you haven't seen it, it's difficult to know you need it.