Organizations often find themselves in a training dilemma when technology must be implemented quickly or when it will affect a large group of employees. As a consultant and trainer, one tool I use in these situations is a knowledge base. Knowledge bases can be implemented quickly, inexpensively, and often with existing technology tools, and they can be very useful for informal and on-the-job training needs.
In this article, I’ll describe how a knowledge base was created on a recent project of mine, and I'll discuss the process involved in determining a content management solution. I’ll also provide insight into how different communication mechanisms can be used to promote knowledge base utilization and share some lessons learned on this project.
Second in a series
This article describes a case study of how one organization used a knowledge base to train users on a new software tool. The first article in this series on knowledge bases focused on knowledge base tools and technologies and implementation issues to consider.
A small team of technical trainers was established to provide a formalized training environment for an innovative and dynamic enterprise software tool. The team members served as both trainers and subject-matter experts for the entire user population. Unfortunately, there were several issues that made it difficult for us to follow a traditional classroom approach:
- The potential training audience numbered 5,000, most of whom were located in the same facility. But this population did not include business partners, who also required access to certain portions of the software. In addition, there were only four technical trainers, each concentrating on a specific aspect of the tool.
- The software changed several times within a month, and this made it difficult to keep training documentation updated, much less distribute the updated documentation to the users.
- There were severe budget restrictions that prevented the hiring of additional trainers.
- In addition, finding trainers with appropriate experience and expertise was very difficult.
Fortunately, we were able to provide a solution that met the most critical needs of the user community with virtually no additional expense. I'll share how the issues were addressed by taking you through the stages of the project.
First stage: Knowledge base creation
First, we created a Lotus Notes database using one of the Lotus Notes standard templates for document libraries. We were able to accomplish this in a few hours because the company had used Lotus Notes as a messaging platform for several years, so the infrastructure was mature and stable for the most part. In addition, the central IS department provided the individuals' and departments' workspace for databases without requiring special permission.
The only files placed in the database at the start were training documents provided to users while they were attending training. The thought behind this was that even if users could not get scheduled for training, they would have access to the detailed, step-by-step documentation.
Even though success factors were not considered before implementation, locating the documents in the database proved valuable to the project’s eventual success. As the information in the documents could not be found anywhere else and were vital to productivity, there was not a need to sell users on the knowledge base, and it became popular on its own.
Second stage: Content management
After creating the database, the team reviewed how best to use the database without increasing the workload of the team members dramatically. During this meeting, members decided on the following critical factors:
- What content would generally be included in the knowledge base
- Who would control or own which content
- How frequently and in what manner content would be updated.
Since the resources were limited, the team had to make sure that any solution met certain criteria: ease of implementation, manageable ongoing maintenance, and no additional cost.
The team decided to include database management in the responsibilities of the technical trainers. The technical trainers were responsible for documenting system features for the purposes of education, so any information they produced would be placed in the knowledge base.
An additional benefit was that the technical trainers were attuned to the needs of the users because they provided the training classes as well as on-site tutoring. The trainers also attended critical enterprise meetings that involved a cross-section of the user community. This meant the team would receive feedback on current critical needs but also on needs to be met in the future.
Other important factors were that the technical trainers were subject-matter experts for specific features, so it was decided that they would own all content related to those features. Also, the trainers generally updated existing training documentation immediately after software updates were released, so it was decided that document updates and new document submission for the knowledge base would occur simultaneously unless something critical occurred.
This approach worked well because instead of changing the existing system and workflow in place, the team was able to augment it.
Third stage: Communication
The one problem that existed after the content management issues were worked out was how to get the word out about the knowledge base to a larger audience.
The existing communication method was to introduce the knowledge base during training, which only allowed a few people each week to become acquainted with the knowledge base.
Again, in keeping with the principle of using the existing system and workflow, the team first identified common communication vehicles with the user community, and they found two key mechanisms. The first mechanism was cross-team enterprise meetings. So the team began to demonstrate the knowledge base at several key meetings so that managers would become aware of the knowledge base. In addition to providing information on accessing the database, we offered to send out instructions if managers provided us with their unit distribution lists.
This was a boon for the managers because it relieved them of the duty of passing along the information. It was also beneficial for the team because we obtained user e-mail addresses that allowed us to continue communication with them.
The second communication mechanism was an alert that was sent out each time new software updates occurred. This e-mail contained release notes for the update. We requested that these alerts also include an announcement about the knowledge base. While this effort didn’t reduce user tech support dramatically at first, the software update notification effort, combined with the knowledge base information, did cut support requests by about 32 percent.
A key reason for the success of this project was due to the fact that some team members had prior experience implementing similar “quick fixes” with other projects. The principles followed for virtually all rapid-implementation projects include:
- There must be a critical or urgent need for the documentation (or some high value placed on the content).
- Use the existing infrastructure no matter what tools are available.
- Augment existing systems and workflow. Do not work to change the system at this time.
- Implement and communicate about the knowledge base within two to three weeks of creation.
- Don't incur any new costs (or no more than a few hundred dollars for tools, if necessary).
What's been your knowledge base experience?
How would you have approached a similar situation? Write and share your insight and experience with TechRepublic members.