Deciding to invest in a knowledge base and writing the check are the easy parts. At Mentor Graphics, we were also committed to delivering “the only five-star support in Electronic Design Automation (EDA)” which means continually investing in new tools, and implementing new ways to service customers.

With the easy part done, the hard part was getting the knowledge into the knowledge base. As we progressed, it became painfully obvious that we were NOT simply populating a database of technical solutions, we were fundamentally changing the support culture: individual product specialists had to learn to share knowledge with the entire technical team.

With that in mind, our plan called for each of our 15 support teams, including more than 100 support engineers, to come up to speed on the new knowledge base system within a year. My team, supporting our PCB board-design tools, includes two managers supervising three remote locations in the U.S. with a total of 22 support engineers. We support more than 50 products in three different technical business areas.

Our team agreed that we would be a leader in the transition. Since we were implementing a complex new worldwide service request tracking system, we decided that we would familiarize ourselves with the knowledge creation process before adding the complexity of learning a new call tracking system.

It was paramount to have management’s support and we needed measurable proof of our progress in streamlining the workflow. The primary strength of the knowledge base was simple -- reuse. Each new record was a reusable solution that could free a technical resource from having to reinvent an answer. The success metric most watched by management was the ratio of the number of new service requests to the number of knowledge base records created and reused.

Finally, we needed a roadmap that provided the tools to successfully transition all our technical engineers to the new streamlined workflow. This roadmap centered around three areas: training, adoption and standards.

Training
With regard to training, we had one simple objective: to take away any technical barriers to using the knowledge base. Looking back at the project, the project was successful because we:

Identified those who needed training -- Every person was required to take one to two days of training over the course of a quarter. This not only allowed the engineers time to learn about the new tool, but also proved to be a key to developing peer coaching groups. Engineers where held accountable for what they knew. The training also eliminated excuses for not using the knowledge base.

Rewarded the early adopters -- Because we were changing the support culture, those who took the risk of being pioneers were provided both tangible and intangible rewards. Some rewards were simple (special treats at a catered project meeting) while others were more substantial (a choice assignment or bonus). To foster teamwork, rewards were generally based on the attainment of team goals. Eventually rewards were no longer needed because the team understood the benefits of the methodology shift regardless of special incentives.

Implemented performance plan criteria -- As engineering support professionals who are used to meeting high-level goals, it was imperative that each engineer had criteria in their performance plan that measured their participation. This provided a two-way safety valve for both the engineer and the manager, in case the adoption effort showed a decrease in performance or customer satisfaction.

Scheduled our one-on-one coaching – We set aside time to coach each team member and not leave that coaching to chance. This allowed us to regularly adjust our strategy and project goals.

Developed peer-to-peer coaching groups -- By matching early adopters and late adopters, the entire team was involved and could share training / coaching tasks according to individual strengths and weaknesses.

Adoption
We had to continually assure that solution records could be easily found because once the knowledge is in the knowledge base, its value is leveraged only if it’s used. During initial training sessions, we learned that the most effective searches resulted from solution records built during the call handling process. We needed to integrate live call handling with live knowledge capture. This was a change from the usual method of developing technical reference information, which was done after the fact and as time allowed. The new process worked for a few primary reasons:

Coaches had to use the new workflow -- Most of the project leaders were also the experts on the products they supported and any incentive for changing their workflow was minimal. On top of that, moving the capturing of knowledge up front meant the possibility of introducing inefficiencies, making simple tasks awkward, and having support reps feel as though quality time spent with customers was decreasing.

However, throughout all phases of training and adoption, we worked with live data. Though the knowledge wasn’t immediately available to customers, support engineers used records internally to solve customer issues. Once we started to hear “There’s a record on that problem," or “Did you write that up?” or even better, “Hey, I found it in the knowledge base,” peer pressure became a driving force. The expectation became that everyone (including the experts) used the knowledge base.

We set specific goals for workflow integration and tracked participation – We tracked participation by team members against goals the entire group created on a weekly basis. Our target was that 30% of new open issues were resolved by the knowledge base.

Standards
Although many groups wanted standards established in early stages of the project, our team chose to establish standards later. Instinctively we knew that the standards would evolve from repeated use and mass adoption. We also knew that whatever we did would have to align with the overall division standards. It didn’t make sense for us to develop standards early on, while the engineers were still learning and adjusting to new processes. Instead we leveraged work being done by the corporate coaching group. Their findings required that we:

Ensured everyone understood the publishing standards -- We defined Gold-, Silver-, and Bronze-level standards for the knowledge base records. Our general records were written to meet bronze-level standards. If the target was to define a large number of gold- or silver-level records, we would have spent so much time and attention to get it exactly right that the overall process would have been negatively impacted.

Identified and developed sample solution records – Users wanted to know what a good solution looked like so we created and circulated good examples to the team. This increased participation and made the coaching and review processes more efficient and productive.

Set technical review standards – Resident specialists review solutions to ensure that the information is technically accurate.

Provided a solution-promotion process – Solution reviews are necessary but they can also create a bottleneck. We didn’t want to implement a gatekeeper role, so we put a peer-to-peer promotion process in place to allow continual team interaction, faster record promotion, and to sharpen engineers' skills. The record review process coalesced around seven steps:

1. Check for duplicates and searchablity: Combine any duplicate statements.
2. Check spelling: Use the spell check.
3. Check HTML links (if applicable).
4. Check the format of base information; e.g. platform type, product version, etc
5. Check statements; e.g. statement order, title of record, solution format, no customer pathnames or specific examples.
6. Check the properties for correct types, e.g. status, solution class, or product class.
7. Check readability; e.g. Use active voice, check grammar and technical accuracy.

Today, we have a culture that encourages knowledge sharing. The SupportNet KnowledgeBase^SM is rapidly becoming the first line of support for both customers and internal support engineers. We're trying to solve the problem once worldwide, and let customers access that knowledge anytime, anywhere.

About the author
Rick Reid is a Corporate Applications Engineer supporting a complex suite of Printed Circuit Board Design tools for Mentor Graphics. In his spare time, when he's not helping to implement a worldwide knowledgebase, he works on his organic farm and plays Cricket with his kids. Mentor Graphics Corporation is a leader in electronic hardware and software design solutions, providing products, consulting services and award-winning support for the world's most successful electronics and semiconductor companies.