Posts Tagged ‘manufacturing’

Transitioning Tribal Knowledge to Training (Part 2)

Thursday, April 8th, 2010 - Posted By: Scott McDonough

A couple of posts ago I was talking about subscription-based e-learning and training services. The gist of that post was simply that “yes those options have their place,  but by their nature they aren’t very good at addressing a need for turning tribal knowledge into effective training.” (More or less…you can find that post here.) 

This is a challenge that presents itself to organizations frequently,  and while not much of a stretch to accept, the question then becomes “how?”.  If you acknowledge that yes, we have a need to capture our tribal knowledge and then make it accessible to and train others on within the organization,  you probably understand all too well that this is not something you are going to be able to purchase off-the-shelf. Therefore the next step is determing how to get it done.

The “how” depends greatly on the organization. A large company equipped with an internal training group may have access to tools, personnel, and budgetary resources that a smaller, mid-market manufacturing company does not. The challenge is the same, but the approach can be vastly different.

I call out this differential in organizational size for a reason. Again, the challenge to capture and make use of tribal knowledge is similar, but the problem can be more difficult for the mid-market company. Their business is manufacturing; most of the organization is dedicated to making product. They often lack the resources of a larger organization, so the requirement to not only solve the problem, but to do so in a way that has a minimum impact on the budget and sans dedicated internal training resources. Which is not to say that any of these suggested tips would not be beneficial for the larger organization as well; I just feel it’s important to acknowledge the often overlooked and unique challenges that the mid-market faces.

Here’s some tips to keep in mind as you develop your own program to capture and train on tribal knowledge:

1. Acknowledge the need. Well, duh. Seems obvious, but you can’t develop a plan to capture the tribal knowledge that exists within your organization until you’ve assessed that there is a need.

2. Make a clear business case that shines a spotlight on the need and will help win support for the initiative.  Is a good percentage of your workforce of retirement age? Are organizational silos preventing the exchange of critical business process information? Make a list and write down the specific reasons why developing a system to capture and train on tribal knowledge will benefit the organization. The process of writing down and working through the “why” will help shape and hone the eventual “how”. This can be a long and drawn out process; be prepared to remind everyone why you’re undertaking this effort, especially in those times where it gets difficult and progress seems slow at best.

3. Implement a workflow process that encourages sharing. Sounds pretty vague, but the basic idea here is that you need to shift away from the old way of communicating. This will no doubt be very difficult, but instead of sending an e-mail to Joe down the hall to ask about a specific process that needs to be documented for training, send him a link to a intranet or web page where he can enter the information. Done the old way, Joe believes he’s told someone how something is done, but that’s part of the problem, he’s told someone. Really take the time to think about how you can facilitate a collaborative method of capturing knowledge. This way, even in-process, the information that will eventually be developed into some type of formal training program can be accessible and useful to others. We’ve seen greater frequency of the use of internal wikis that can be incredibly useful in this regard.

4. Go talk to people, but don’t hassle them. Not everyone in the organization, especially in a manufacturing environment, will have access to the company intranet. Therefore, you’re going to have to go talk to those people that often times, know “the real story” about what makes your company tick. Be smart about it though, you’ll get little cooperation if you just hang around and randomly appear to pick their brains. Instead, make a plan of what information needs to be captured. Identify those individuals that are likely to be the most knowledgeable by talking to the person responsible for maufacturing operations. Schedule time to meet with those people and have a clear agenda of the type of information you need to capture before sitting down with them.

5. Determine how you will present the training information and make it accessible.  As a manufacturer, you may not have the staff resources or know-how to develop an effective training program, but don’t panic. The good news is that there are numerous options available these days to help with the technology side of your training program. Break the technology requirements into pieces that correspond with specific goals rather than trying to find one application that will do everything.  In this way, you can focus on tools that are right for your specific requirement, rather than pay for a single service or suite of tools that are more than what you really need. 

  • Composing the content. Widely reviled by training experts everywhere, there’s a good reason Power Point remains prevalent. Organizations exactly like mid-market manufacturers already have it, and most everyone knows or can figure out how to use it. There is no shame in using PowerPoint, especially now that there are many training development applications that will allow you to directly import .ppt files. Is it the best or most capable application in which to develop training? No, not by a long shot. However, if software selection is the obstacle preventing  you from starting the process of formalizing captured training content, by all means fire up Power Point.
  • Distributing the training. Your company intranet is an obvious, simple way to start. Share Point is particularly well-suited to the delivery of training materials. Or, you could create a simple HTML-based portal to display links to the training content. Microsoft and Adobe also offer applications that allow group collaboration that can be useful for hosting real-time instructor-led training directed to a group of people. Dedicated learning management systems sure offer some great functionality, but don’t let that stop you from finding other ways to distribute your content.
  • Measuring retention. How do you know if someone has actually acquired the knowledge you’ve attempted to pass along? You’ll want to develop quizzes, tests, or practical hands-on skill evaluations. These can be accomplished in many different ways. Be sure to think about not only the format of these retention-measuring devices, but how they will need to be managed as well. What adminstrative requirements will there be?  Most professional training development software, like Adobe Captivate for instance, integrate the ability to add quizzes and tests into the training course, as well as allow for the  delivery of these results. However, get creative and see what low-cost or free services are out there as well. These may not be permanent solutions, but a Google search for “develop online quizzes” should get you started and perhaps thinking outside the software box as well. Again, when cost is a primary concern, try to identify simple services to meet specific requirements for each major function of your training course.

6. Be realistic and patient. Most of us can appreciate really great training when we see it, and most of us always want to create the best we can. However, understand that all the bells and whistles have some cost associated with them. It might be nice to have an interactive, exploded view of equipment for the maintenance technicians, but how realistic is that today? Think of your tribal knowledge capturing and training project as a living one. True that the 3D animation of a process might make it easy for some learners to visualize, but it’s not worth stalling out the development of your training. You may have to settle on a handful of static images or engineering drawings for now, but that’s ok.  As the organization as a whole recognizes the importance of and progress made on capturing and delivering tribal knowledge training, these things will come. It is far more important now, during the first stages of formally developing this training that something gets done as opposed to nothing at all.

Granted, this is not the sum total of the concerns you’ll be dealing with as you take the first steps towards developing your own tribal knowledge training program, but I hope you find these items useful as guidelines.

Good luck, drop us a note here if you’d like further information or need some help.

 

 

Tags: , , , , , , ,
Posted By: Scott McDonough | 1 Comment »

Technically Exhaustive, Literally Unusable

Thursday, April 1st, 2010 - Posted By: Scott McDonough

“Nobody reads these things anyway.”

If you’ve spent any time thinking about, developing or using technical documentation, it is likely you’re familiar with this old chestnut. The reasons behind this dismissive utterance may vary: too much information, not enough information,  problems with accessibility and navigation, language translation issues, etc. but any or all of these reasons are assuredly more than enough to relegate “the manual” to dust-collecting duty on a shelf somewhere.

Those responsible for creating technical documentation bristle at this sentiment, even as a generality. We are very quick to counter and extol at great length ( just ask next time you’ve got a few hours to spare…) the absolute critical necessity of quality technical documentation and the positive business benefits it can bring.  Yet somehow and despite this fact, there is no shortage whatsoever of product support documentation that yet again, will elicit from the user a resounding “huh?” at best.

It’s the “why” of this that remains of great interest to me. If the people who write the documentation know that there are ways to create something that would be more well-received, why aren’t they doing it?

It is because at the end of the day, the organization creates technical documentation through its business processes and policies, not the technical writers. Technical writers learn from day one that “above all else, consider your audience.”  However,  the vast majority of technical documentation we encounter on a daily basis would never lead you to believe that the user was of much concern at all.

By and large we accept this. Poor or unusable documentation perpetuates the notion that most of it is terrible, and therefore it’s not news nor a surprise to anyone. It’s just the way it is. The attitude that “nobody reads these things anyway” persists.

Why does this happen? What’s going on inside the organization which clearly places some measure of value on the importance of technical documentation, yet continues to put out materials that their customers aren’t using?

Well, here are some of the more common symptoms and causes that we’ve observed:

  • TMI (Too Much Information).  Apparently, if it has been written down and has to do with the product, then it must be included. All of it. Not only does this super-level of content make it extremely hard on the user, it makes the documentation development process extremely time consuming. The focus shifts away from usability to making sure there’s enough time to pack everything possible in, regardless if its quality or usefulness. “Better to have it in there than not!” is the default decision on questions of content and all too often this just makes things worse.
  • Writing style “of the engineer, for the engineer”. Often times when dealing with documentation that covers a particularly complex product, the end result can end up looking like a mildly breathed-on series of engineering white papers. However, if the user of the product is not a design engineer, but perhaps a technician or operator, this documentation will be of little use. It is the job of the technical writer, as the advocate for the audience, to make this information as accessible as possible. However, not all documentation is created by professional technical writers, and sometimes there’s just not time to properly re-work the content to a level that is sufficiently palatable for users. If the former is the case, perhaps those responsible for the development of the technical documentation should be trained on how to interview technical subject matter experts.
  • Failure to focus on the audience.  This dovetails in with the above, but much of the technical documentation we see regularly would benefit greatly simply by assessing it through the eyes of the user. If I am told that it is my responsibility to maintain a piece of equipment, then I, as the user of the manual that came with the equipment  want to be instructed on how to troubleshoot and repair. Chapter and verse regarding theory of operation will mean very little to me. Tell what to expect from the moment I open the box through installation, configuration and maintenance. Any information beyond that may be of little concern to me right now, so simply tell me where to find the rest and if I need it I’ll go looking for it. Most often, this lack of focus on the audience happens because it gets squeezed out in favor of trying to get every possible piece of information included as a priority. It is absolutely worth questioning and re-evaluating who the users of your technical documentation really are.
  • Deadlines and Industry Specification Requirements. For those companies that manufacturer many and diverse products, there’s simply not enough time to pay too much attention to usability. It’s hard enough to keep up with getting out any sort of documentation much less pieces that really focus in on and work for the users in a meaningful way. If you manufacturer certain products that are subject to regulation, it’s easy to fall into the routine of just meeting the minimum requirements for the documentation; requirements that do not necessarily account for what might work best for your users.

All of the above are symptomatic of the widely-held opinion that technical documentation is regarded as a “necessary evil” .

The realities of business processes and policies often limit the potential advantages that technical documentation can offer both the manufacturer and their customers. However, this can only be properly addressed when the organization chooses to make a proactive change. Otherwise the cycle of “it’s no good but no one reads these anyway/no one reads these anyway so it’s ok if it’s not that good” will continue to persist.

 

Tags: , , , , , , , ,
Posted By: Scott McDonough | 1 Comment »

Transitioning Tribal Knowledge to Training

Thursday, March 25th, 2010 - Posted By: Scott McDonough

There’s an old joke about the retired engineer who is hired as a consultant to his former employer to fix a particularly daunting problem with a piece of equipment that no one else can seem to figure out. Ultimately, the engineer solves the problem using a single screw. Upon reviewing the invoice for his work, the manager is astounded by the price. “A hundred-thousand dollars!?!  he exclaims. “All you did was install a screw! How can you charge a $100,000 for that?”

“Simple”, the engineer explains. “$1 dollar for the screw, and $99,999 for knowing where to install it.”

While intentionally exaggerated (much to the satisfaction of engineers everywhere), there’s an oh-so-true reality here. The $1 screw was not singularly responsible for fixing the problem. In fact, that $1 part is completely useless without the additional benefit of the engineer’s knowledge. Therein lies the real value.

However, this type of knowledge that is acquired over a long time and through the benefit of great experience is notoriously difficult to capture. Which is precisely why that in the story above, the engineer was able to command a ransom for what he knew. It clearly did not exist anywhere else inside the organization.

This is exactly the situation that many companies find themselves in today. Part of the workforce owns a great deal of the information required to keep the ship afloat and pointed in the right direction, but what happens when the individuals who make up that part of the workforce retire or move on to other jobs?

Some types of knowledge can be passed on to the organization-at-large through the use of off the shelf training. There are services that client companies can subscribe to that will give their employees access to training resources on all sorts of relevant topics. Software training, personal and soft skills training, sales training, safety training, even generalized machine tool operational training. You name it, there’s likely training available and accessible via the web. You can sign up and assign your entire staff to attend and complete the training courses of your choosing. Sign up, sit down, get trained and Bob’s-your-uncle. Done and done. Trained.

Right?

Well, sure. Sometimes. If you needed your accounts receivable staffers to brush up on Excel 2007, probably. If you needed your plant personnel to better understand current OSHA regulations, sure. Off the shelf training programs certainly do have some clear value, no question.

However, if you have the challenge of conveying the type of knowledge that only comes from years of experience and interaction with your operating conditions or processes, it may be hard to bridge that gap with off the shelf training. That type of knowledge, the “oh-no-the-line’s-gone-down-and -Jim’s-on-vacation” mission-critical and specific type of knowlege, has to come from within.

And while that can seem to be a daunting task, to capture that knowledge and then create and deliver training information to the larger organization, the long term benefits in terms of prevention alone will be enormous.

So next time line #6 goes down, it won’t matter that Jim went on on vacation, Steve knows that sometimes all it takes is to check the connection on the back of the optical sensor to get things up and running again.

But how exactly can your company do this? I’ll outline some basic project steps in the next entry.

 

 

 

 

Tags: , , , ,
Posted By: Scott McDonough | 1 Comment »

The Disclaimer You’ll Never Find on Content Management Software

Wednesday, March 17th, 2010 - Posted By: Scott McDonough

“The user shall determine the suitability of the product for his or her intended use and shall assume all risk and liability and connection therewith.”

Product disclaimers are everywhere. Presumably crafted by very smart people wearing suits, who know much better than the rest of us, these little nuggets of wisdom caution us against all sorts of things. Tossing an aerosol can into an open flame for instance, or using hot sauce to rinse out our contact lenses. Essentially, they remind us of what a product isn’t intended for, and what bad things might happen if we don’t pay heed.

However, you’ll find no such disclaimer on a piece of content management software…but there should be, and I’ll explain why.

In our line of work, we talk to mid-market manufacturers on a daily basis. When discussing product support documentation, a remark that we hear all too frequently goes something like this:

“Well, we bought this popular content management system/authoring tool a few years back, but we don’t really like it/use it/are getting away from it.”

Time and time again, we hear the same story. These mid-market manufacturers, by all accounts successful and staffed with intelligent people, decided to move into managed content using a software application, and then at one point, stopped. Why is this?

Was the application faulty or flawed? Did the software company makes dubious claims that simply weren’t true?

In reality, no, neither. Assuming the mid-market manufacturer did a modicum of homework and purchased an application from a reputable software vendor, the application was likely perfectly functional.

The problem is the disclaimer, or more precisely, the lack thereof. It’s what the software can’t do that’s the real issue.

Were I to write a disclaimer for a content management software application, it would have to at a minimum include the following:

“The use of this product implies no remedy nor correction of the following issues, included but not limited to:

  • Continued, excessive use of your engineering team’s time spent developing and reviewing product support documentation may result (Product support content will not research, review, and edit itself)
  • May require considerable and ongoing dedicated training resources to ensure proper implementation and maintain consistent use over time
  • It is the responsibility of the user to both identify and structure legacy content for re-use; the software only allows for the potential of this functionality
  • It is the responsibility of the user to establish and maintain an internal process that supports the flow of information into and out of the software
  • The software vendor makes no claim regarding the quality or usability of the content managed within.

Your individual results may vary.”

Content management software companies have done an excellent job making sure they have exposure; it is their job to exist in the spaces where people that have the challenge of developing and maintaining content live.

However, in doing so the line between content development and content management has been blurred and this especially true in the mid-market. It’s one thing to have the ability to single source and manage content, quite another to improve the way it is developed, integrated into internal workflow processes, and then maintain over time.

So after you’ve read all the website materials, sat through the webinar, and heard everything there is to hear about what the software can do, make sure to stop for a minute and consider how’ll you address what it can’t do, too.

Tags: , , , , ,
Posted By: Scott McDonough | 4 Comments »