Posts Tagged ‘equipment 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 »

What is a Structured Document?

Monday, March 22nd, 2010 - Posted By: John Crews

This is a question commonly asked by our customers when we begin working with them on a single-source solution.  There is a short answer:

A structured document organizes paragraphs (elements) in a logical hierarchy, provides a means to attach tags (attributes) to individual paragraphs (elements), and gives you the ability to view the document in multiple ways.  FrameMaker ® (and other editors) also gives you the ability to manipulate the content of structured documents so that you can supply different outputs from the same document.

For this discussion, I will be using Adobe® FrameMaker® as my editor.  FrameMaker’s what-you-see-is-what-you-get view of structured documents is called the Document View.  If you have worked in unstructured Frame, this should look very familiar:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Note, that all text is enclosed in brackets.  These brackets indicate element boundaries on the WYSIWYG view (Document View).  This correlates to the Structure View hierarchy described later.

The second way to view the document is called Structure View in FrameMaker.  The Structure View shows all elements (paragraphs) arranged in a hierarchy.  Each box represents an element.  An excerpt of the element text is displayed to the right of the element.  Below each element are Attributes assigned to the element.

The example highlighted below shows that the first element Bullet1 is assigned a value of 1 for the attribute Output.  The second element Bullet1 is assigned a value of 2 for the attribute Output.

In addition to managing the attributes and hierarchy of elements, you can also perform some edits in the Structure view.  If you right-click on an element, a context menu appears that describes several possible actions.  Typical shortcut buttons (ctrl+C for copy, ctrl+v for paste) function normally.  You can also drag-and-drop elements to move their location or to change their place within the hierarchy.

Most users who are accustomed to unstructured FrameMaker are used to working with the formatting toolbar.  Structured Frame does have this functionality; however, it also introduces an Element Catalog in place of the paragraph catalog.  The Element Catalog lists elements that may be selected to insert into the document and provides a tool-set for managing elements as you create them.  Using this catalog, you can insert an element into an existing element, wrap an existing element inside of a new element, and change the type of an existing element.  This tool set helps to minimize the complexity of managing the content from the Structure View.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Once you have an element in place, you can assign attributes using the Attribute Editor.  The editor displays potential attributes for a selected element and lists the predefined values that may be assigned.  Select the desired attribute, assign an attribute value, and then select the Set Value button.  This assigned value is then visible in the Structure View.

 

 

 

 

 

 

 

 

 

 

Using the Structured FrameMaker tool set helps to make management of complex single-sourced documents easier.  Creating a functional hierarchy allows you to manage content at all levels.  Attributes allow you control several output levels and types while ensuring that you are able to maintain accurate content.

Tags: , , , , , , , , , , , , , , , , , , ,
Posted By: John Crews | Post a Comment! »

Sometimes, you’ve got to call in SWAT

Monday, March 8th, 2010 - Posted By: Scott McDonough

Everyone knows that when a situation gets out of hand and the first responders are in over their heads, sometimes you’ve got call in SWAT. 

Police work? No, something far more adrenaline-fueled and dangerous. Documentation.

Picture this:

A manufacturer is scrambling to finish up and prepare for delivery the latest iteration of one of their most popular pieces of equipment. Three weeks before it is scheduled to ship, someone realizes they forgot to prepare the operator and service documentation that is required to accompany the equipment to their customer overseas.

Internal resources are tapped. Engineers and technicians work day and night preparing the machine for shipment and delivery. In an office adjacent to the assembly floor,  the engineering manager and product line manager furrow their brows with growing concern. Completing the documentation on time is only one-half the problem. The other half is doing so in such a way that corresponds favorably with the quality and innovation of this new piece of equipment. A hastily assembled three-ring binder full of notes and photocopied vendor-supplied spec sheets just weren’t going to cut it this time.

What do they do?

They call in a SWAT team. Well, ok. Maybe not the guys with the bullet proof vests and flash-bang grenades, but a documentation SWAT team. (Which, let’s face it, is almost as cool.) This team shows up in khakis and button-down shirts, armed with notebooks, digital cameras and laptops loaded with high-power publishing software.

And like the real SWAT, this documentation team is equipped with special training.  Armed with the education and real-world experience of mechanical and electrical engineering as well as computer science and communications, a well-rounded team of specialists that is singularly focused on the mission of getting in and getting back out with minimal long-term cost.

When the team shows up on site, they rapidly assess the situation and map out a plan. In short order, a project scope is hammered out, and the team goes to work.

The team descends on the equipment and rapidly determine how it works, what the major components are, and what needs to be included in the documentation. Encounters with engineers and technicians might prove troublesome for some teams, but not this one. They speak the language; fluent in “engineer” and well-versed in the world of equipment manufacturing. At the same time, the teams’ offsite support are already preparing a template to house the content.

The team supplies everything. Need a picture of this component? No problem. Need to facilitate the inclusion of  CE warning labels but can’t find all of them? They’ll find them. Need an engineering drawing converted or modified? They’ve got you covered. Need to facilitate the upload of  large files for inclusion into the documentation? The team will have a secure file transfer site up for you in minutes. Want to design a completely new documentation layout to better represent your company? The team will provide you with samples to choose from, or create a completely new one. Have a requirement for an additional language? They have specialists for that, too.

Digital cameras flash. The rapid firing of keystrokes punctuates the noise of the assembly floor. Notepads are exhausted and pens run dry.

It’s the end of day one, and the team is ready to present a working outline. By the end of week one, the team will have draft content ready for review. By the end of week three, the documentation has been completed and delivered. Along the way, the team has reported daily and weekly progress, organized and facilitated review meetings, and managed the process of seeking out, capturing, and maintaining content edits.

Wouldn’t it be great if such a team existed? A team of specialists that you could call in to respond to your product documentation needs without having to hold their hands? A team that has the skills, know-how and appreciation for your time and resources? A team that could get in, get out and provide you with a quality and on-time deliverable with no long-term investment? Sound too good to be true?

Some questions for equipment manufacturers out there:

Have you ever wished for a documentation “SWAT” team? What would prevent you from utilizing such a team? What questions or concerns might you ask or want to discuss with this team?

I’d love to hear your thoughts. Drop us a note here or feel free to use the comments feature.

 

Tags: , , , , , ,
Posted By: Scott McDonough | Post a Comment! »