Archive for the ‘Scott McDonough’ Category

« Older Entries

Corporate Self-Help: Outsourcing Skills Training

Monday, April 26th, 2010 - Posted By: Scott McDonough

Everyone needs some help learning how to do something from time to time. Learning how to tie your shoes. Learning how to ride a bike, learning to swim. Or even learning how not to act at the office holiday party. These are the kinds of things we learn from our parents, older siblings, and friends (and in the case of the last example, our bosses). Good lessons, all of them.

Companies learn how to do things by hiring smart people and paying them to figure out how things are done. Sometimes, even after they figure it out for themselves, they hire other companies to do the work for them. In either case, what needs to be figured out gets figured out, and what needs to get done ultimately does.

But what happens when the smart people don’t have the time or knowledge required to figure out how to do what needs to get done? Simple, you hire someone else to do the work, right? Well, what if that too is not an option? Ignore the need and hope it goes away?

No, of course not. If you don’t have the time or knowledge to complete the task yourself and you can’t outsource the work itself, why not consider outsourcing training that will give your smart people, well, even more smarts?

It’s an attractive compromise for a few reasons:

  • Lower overall cost. It’s generally less costly overall to pay for the training required to perform the work than it is to pay for the work itself.
  • Job and requirements-specific training. These might sound like buzzwords or jargon, but there’s a real point here and this can make a huge difference on the true effectiveness of your training. In our world of content development for example, we would much rather offer training on the use of Frame Maker as it applies directly to the performance and within the context of an individual’s day-to-day job, not as an overview to the sum total capabilities of the software. With outsourcing of the training you have the huge advantage of ensuring the training is 100% applicable to your process and your content. The significance of this distinction cannot be overstated.
  • No long-term commitment to outsourcing. When you target the training you need specifically to your unique requirements, it takes less time to train overall since the objectives of the training are very clear and understood up front. No time is wasted covering irrelevant material. It can be everything you want and nothing you don’t, and this means less redundancy and cost. Once the training has been completed and you now have the skills you need to complete what needs to get done, there’s no commitment to further expenditures on outsourcing, unless you decide you want additional training.

Another way to look at it, (and I’ll apologize in advance for the terribly overused cliché), when you have to get something done would you rather pay for a fish, or learn to fish for yourself?

Outsourcing can be both an incredibly cost-effective and efficient way of getting additional work done without adding the cost of new equipment, software, or additional talent. At the same time, outsourcing can be looked upon negatively in that it can sometimes mean that a job that could potentially be done internally is now going to be outsourced. But it doesn’t have to. There is a middle ground through targeted skills training, and its worth looking into.

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

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 »

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! »

Is Your Product Documentation Letting the Side Down?

Tuesday, March 2nd, 2010 - Posted By: Scott McDonough

Look at any trade magazine, industry e-newsletter or website and you’ll continue to find evidence of dollars being spent in the pursuit of the next sale.  Even in economic downturns, (or perhaps exactly because of an economic downturn), it seems manufacturers are still willing to go to just about  any length to get the word about their company and extol the virtues of their products.

In today’s world of user-friendly and largely free social media tools, it’s understandable that this trend continues. In relatively little time, with relatively little cost, manufacturers large and small can stake their claim on the web and create a fresh,  forward-facing identity to engage potential customers with a whole new strategy. Manufacturers across the country and the world are scrambling to become experts in the brave new world of social media. Facebook, Twitter, and YouTube used to be banned during working hours, now they’re almost a requirement.

And let’s not forget the more traditional methods of marketing, including the entirety of various MarComm initiatives, as well as ad buys in the aforementioned trade journals and/or banner space in e-newsletters, trade websites and the like.

However you as a manufacturer define your strategy of getting the word out about your products, it adds up to a significant, concerted series of costs and efforts designed to generate leads, and from leads, sales.

But what happens after the sale? Have you considered that your product documentation is letting the side down? Or even worse, could your product documentation be preventing a sale?

For your consideration:

  • Given all the time and effort that go into creating a brand that properly targets and engages your customers, does your product documentation support the perception of your brand? Is the gleam of your world-class marketing effort being dulled by a ratty binder of photocopied sheets that you affectionately refer to as the “operator’s manual”? At a minimum, stop and consider what kind of impression is left on your customer by your documentation after the sale.
  • Are you using your product documentation to sell after the sale? If your product requires consumables, service parts, or optional upgrades, you should be.  From the correct contact information for service reps to detailed information on the benefits of genuine OEM consumables to instructions on how to get spare parts, it’s always worth your while as a manufacturer to ensure you are taking advantage of this opportunity to make these additional sales. Do you offer product or process-specific training for customers? Why not include this type of information in your product documentation as well?
  • Is your product documentation available online? Many people use the availability and quality of product documentation as a factor in their purchase decisions. Is yours available online, and if it isn’t today, would you have any reservations about making it available online as it stands today? Could be one more reason for your customer to decide to buy from you. Even if you deal strictly in custom equipment, it may be worth creating a “generic” sample and make it available to potential customers of an example of your world-class products and support.
  • Take a look at your competitors’ product documentation. Is yours comparable? What things do you think they do a better job of, and what things do you feel you do a better job of? Next time your boss asks you to sit in on a marketing strategy session, it would be worth your time to have this list or some examples handy.

Product documentation is often overlooked or dismissed as a necessary evil, yet it should have just as an important role as every other play in your marketing strategy playbook. Don’t make the mistake of allowing it to let your side down.

 

 

 

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

Adobe Frame Maker Training: A Results Oriented Approach

Tuesday, February 16th, 2010 - Posted By: Scott McDonough

We were doing some consulting for a manufacturer that had been tasked with launching a more-or-less new technical publications department. I say “more-or-less new” as the company had always tried to produce and keep up with technical documentation to support their products, but the process was ad hoc at best, and completed by any available warm body with access to a desktop computer, Word and/or an ancient version of Corel Ventura . As the company grew this became problematic, as you can imagine. The manufacturer’s decision was to formalize a group that would be responsible for ensuring that product was always accompanied by relevant documentation.

One lucky staff engineer was appointed manager of the new, albeit non-existant, technical documentation group.  Beyond a fresh set of licenses for the still-uninstalled Adobe Technical Communication Suite software, this manager was not working with very much to start. Of particular interest was training on the use Adobe Frame Maker for the newly-minted technical writers.

The manager was well aware of the prevalent training options. Adobe themselves offer training, and there’s an entire cottage industry of third-parties dedicated to offering  training on just about any piece of software imaginable. Costs vary somewhat based on the location, duration or the supplemental training materials provided, and many focus on providing the trainees with a means to getting their feet wet with Frame Maker. A good functional overview , if you will.

This is all fine and good, and certainly of benefit to many people seeking to learn more about Frame Maker and it’s capabilities. However, for this particular customer, we advised a results-oriented approach.

Why? Not because there’s anything inherently wrong with sending a staff of writers to Frame Maker training; but as consultants we have an obligation to consider our customers’ actual requirements. Not to mention that we’re a service organization and it’s what we do afterall, create clear paths to results for our customers.

Given this customer’s requirements, we determined a course of action that best fit the description of a results-oriented approach to Frame Maker training. I’ve sketched out that approach below; maybe you will find it of use within your own organization.

1.  Create a Frame Maker template. One of the most important and useful things you can do is to create a standardized Framemaker template (or templates) for your documentation. Work from an example of your existing documentation; establish the look, feel and approved writing styles to create a consistent set of components for you and your writers to use when working within Frame Maker. Think of this as the common skeleton for all your manuals. A solid template should contain the following:

  • A graphical representation of the way your documents are laid out on the pages, i.e. pre-defined sections and spacing; what goes where (“frames”)
  • All standard boilerplate information such as your front matter, corporate logo, page header and footer definitions (page number, doc part number, contact info etc.)
  • A library of approved styles to be used within your manuals. Again, working from the styles you’ve used in the past (or created as new), you can pre-define the available selections your writers will need to have access to on a day to day basis. For example, for all of your chapter or section headings, you can create the component within Frame Maker as say, “Section Head”, so when selected, you simply type the text and Frame Maker will automatically apply the correct positioning on the page, space around the text, font, size, and other attributes. The same would apply to warnings, cautions, notes, numbered or bulleted lists, body text, etc. This will ensure consistency across all of your documents.
  • Include instructions for use within the template itself. Not only can you create the tools; you should show examples in use within the template and include instructions on how to use written into the template document itself. This way, any writer can open up the template and immediately see how different styles are to be used, and can keep a copy if they wish as a quick reference as needed.

Template creation is an important first step to ensure that your publications retain the same structure from document to document regardless of who does the writing within your group. Good templates also establish the standard of usability for readers, and should represent your brand in a positive manner.

Note that very few, if any Frame Maker training courses will provide a customized template for you to use, yet this is absolutely key to begin using Frame Maker in a meaningful way and should not be overlooked.

2. Think job-specific training, not just software training. Taking a class on Frame Maker may not meet your groups’ requirements in and of itself; especially if one of the requirements is to get productive quickly. Adobe also offers a self-guided instructional manual with Frame Maker of course, but often times users find it about 50% more than they need to get their job done, and it’s hard to know at a glance what is pertinent information and what is not.

 
Consider how your staff will use Frame Maker day in and day out, then focus on training that addresses these real everyday requirements. As part of your company’s Frame Maker training you should incorporate the following:
  • A Quick Reference Guide for your staff. This should be the “SOP” for anyone present or future who has the role of technical writer at your company. Even as people move on, this remains, to serve as the reference on how your company’s documents are created using Frame Maker. Again, this should be completely specific to the production of your documentation, not a generic guide on the use of Frame Maker that leaves it to your staff to figure out how to apply it to your specific application.
  • Instructor-led training that will ensure your staff get hands-on experience working in your specific template producing your manuals under the guidance of  an experienced Frame Maker user. This way, the tasks learned are 100% 1:1 applicable to the actual jobs your staff will be doing day to day.
Combined, these components will absolutely ensure that your group will quite literally hit the ground running. Focus on creating productive, efficient technical writers, not just a  staff that knows a lot more about Frame Maker overall, but are still unsure of how that applies to their jobs.
 
Cost deserves a mention as well. Good, bad or otherwise, one of the biggest factors in selecting a resource for Frame Maker training is cost.
 

Perhaps harder to quantify on paper for comparison’s sake, but how much is it costing every day that your group is not up to speed producing new documents or working through a back log? What tolerance will there be internally for the time and expense of off-the-shelf software training that does not yield practical and immediate results? Based on the wages and benefits of our staff, how much time would have to spent dealing with inefficiencies before that cost is equal to or greater than the cost of our developing a training program as outlined above? Worth your time to take a look at both.

Basic Frame Maker training will yield an overview-level understanding of the entire range of Frame Maker’s capabilities. Yet upon completion of software training, you will not have a template to work from, will not have had the benefit of practical time working on your specific manuals, and if a person moves on, that training is gone.  Equip your group for the long term; don’t risk stop-gapping the issue with insufficient software training.

 

 

 

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

Response to an Outsourcing Question Posted on LinkedIn’s Documentation Managers Group

Tuesday, February 9th, 2010 - Posted By: Scott McDonough

Recently, someone from a language translation services provider posted a good question in LinkedIn’s Documentation Managers group. As a language services provider, this person’s company is considering the addition of technical writing to their service offerings. The questions were “why do companies outsource technical writing, how frequently and to what extent?”

These are great questions, and I thought I’d re-post my thoughts here:

-The reasons why our clients choose to outsource technical writing are as varied as the companies themselves. In better economic times, it was often because thier internal resources simply did not have the capacity to meet the requirements. More recently, as internal staff levels have tapered off, we are seeing requests for assistance because the in-house resources that once were simply do not exist any longer.

Also, as [another commentor] pointed out, “technical writer” is a catch-all job title. All of our staff here would be more appropriately described as “content developers” as they have experience not only developing content for, say, product documentation but training curriculum and content for web applications as well. So there sometimes exists a disparity between what a potential customer thinks they need versus what they should be looking for. This subtle issue is one you should be aware of and one we deal with everyday. You may advertise that you are offering “technical writing” services, but your target customer may not equate their particular content development needs with technical writing necessarily because their subject matter happens to be training currciculum.

Some clients simply need an existing document edited to reflect some recent updates. Sometimes a file format conversion is required. Sometimes a person is needed on site to work with product teams to develop and deliver content. Sometimes clients hand over entire product documentation projects to be managed either on-site or remotely start to finish. Again, the reasons for and extent of outsourcing varies greatly.

-It has been our experience that larger companies having strong internal technical writing departments or resources, are often resistant to outsourcing, which makes sense and is to no one’s surprise. However, even these groups will often be receptive to learning more about how to manage their content more effectively. They may not want any help developing the content, but chances are they are drowning in a sea of it and may even be feeling pressure from the KM/ECM folks in their organization to do something about it. In this case, outsourcing the writing of their content probably isn’t going to be very attractive, but the services of a company or experienced technical writer may in fact be. Technical writers experienced with extensible content structure and delivery can still be a viable outsource option.

-A question that comes up frequently when discussing the outsourcing of technical writing is validation and verification of quality. This is especially relevant since the rise of lost-cost outsourcing across the globe. A low per-piece or per-hour rate can sound incredibly attractive to those considering outsourcing, but it must be evaluated to include the additional expenses of the contracting company’s project management and validation/verification time. The reality is that it is just not that simple as outsourcing to take advantage of a favorable exchange rate, there are real additional costs that have to be considered.

-More and more, and back to [another commentor's] point, it is simply not enough to offer pure content development work. While a valuable skill in and of itself, technical writers have found themselves having to respond to the needs of organizations that are shifting the focus to the management of their content. We have seen, over the last few years, more and more clients looking to us for assistance with the structure and management of their content, not just the development of the content. It seems it’s simply not enough to be able to develop content, it pays to know a thing or two about content management as well.

-Your position as a language services provider is probably a good one. We currently partner with a couple of similar service providers and those relationships have proven to be worthwhile.

For the complete discussion, here’s the link. (Though you may have to register for the group if you have not already.)

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

Developing a Flexible and Sustainable Training Program

Monday, September 14th, 2009 - Posted By: Scott McDonough

We have had the good fortune to develop many training materials for our clients over the years. Regardless of the training topic, there’s always something especially rewarding about developing training content. I think one of the reasons we enjoy it so much is the fact that multimedia is often involved and the delivery platform can vary from print materials to the Web. Compared to technical documentation that only exists on a shelf somewhere (yes, we still work on those projects too!), training programs often represent an opportunity to be creative while flexing our design and programming muscles at the same time.

Recently, we were talking to a client about transitioning their legacy printed training materials into a more robust program that would be both easier to maintain and reach more of their employees and customers.

Their situation was not at all unusual or uncommon by any means. I’m sure many of us are familiar with a scenario like this one:

-The training curriculum is developed in-house using Microsoft Word or a similar word processing application.
-The curriculum is distributed electonically via e-mail and manually via printing and mailing.
-The curriculum is delivered by multiple instructors, who are responsible for not only the delivery of the training, but for the management of the trainee information and testing results as well. Consequently, there are no real standards behind the delivery of the training and no knowledge retention metrics for the trainees.
-The travel requirements for instructors and customers alike were becoming a greater and greater burden.
-No clear path for remediation. If a trainee can’t keep up with the instructor, oh well, at least he or she attended, right?
-Multiple revisions of the training content exist internally; one or two internal experts might know which is current.
-Internal training rarely keeps pace with the needs of the ever changing organization, and external (customer) training can’t keep up with the speed of product release and revision.

The client was unsure of their direction and was pretty overwhlemed by what seemed like a long, difficult, and expensive path to achieve their goals. Our team evaluated their current situation along with their requirements and came up with the following recommendations.

*Starting at the source of the training content, transition out of Microsoft Word and into an XML-capable authoring program, like Adobe Frame Maker. The cost to obtain a couple of licenses for Frame Maker plus the time to learn how to use it in a structured environment is relatively small compared to the inefficiencies and risk of a poorly managed training program. (Incidentally, this client took us up on our offer to teach their training personnel how to use their new software.) There are of course other good quality and robust XML-capable authoring platforms; the point is simply that the first step should be to ensure you can create content that can be easily reused within other applications and locations. This alone opens up a world of opportunity to improve your curriculum management and delivery processes. Now all of the training content that was once shackled within the stuffy confines of Word can be reused almost anywhere.

*Leverage the now XML-rich content into a Web-based delivery platform. Web-based delivery of curriculum has a number of nice advantages. The curriculum content and method of delivery is always the same (standardization), its available to anyone with access to the web and proper log-in credentials (accessibility) and trainee/student management can be automated. Also, the travel once required to deliver the training can be all but eliminated (reduced cost). What we recommended was to convert the legacy print curriculum into smaller computer based training (CBT) modules. Granted, “custom CBT module” and “inexpensive” typically aren’t used together in the same sentence, but because a large portion of the actual training content now existed (and will continue to exist) in an XML format, the overall development costs for the CBT modules were minimized. Using another Adobe product, Captivate, content generated in Frame Maker can be directly reused within the CBT modules.

*Take full advantage of the CBT environment. Using a good CBT development tool like Captivate or similar, we were able to show our client how to take full advantage of this type of platform. What was once simply text and line drawings, can now be enhanced with Flash animation and digital images. The pace of the curriculum delivery is now dictated by the trainee instead of the instructor. Exams to measure subject matter retention can be built in, with direct paths to remediation built in. If a trainee misses a particular question or answers one incorrectly, the CBT can be programmed to immediately redirect the trainee to review the relevant material and try the answering the question again. Once a CBT is completed, results containing the trainee can be directly e-mailed to any address or addresses, or if there is an learning management system in place, the results can be directly integrated into most any database, allowing trends to be identified and reviewed. Internal training and testing can be turned into customer training by simply removing any portions that are not applicable to the customer side of the training.

*Implement revision control and execute revisions. The clients’ training curriculum is dynamic and must be updated from time to time to reflect product revisions and procedural changes. However, not all changes are equally critical. In order to contain what would otherwise be a continuous stream of updates, we helped the client implement a “major” and “minor” revision control structure. While simplistic, this really helped them get a handle on revision control. “Major” revisions are classified as those revisions that have to do with personnel or customer safety, as well as those things that may cause damage to the product. These major revisions are executed immediately. “Minor” revisions are classified as those revisions that describe a non-critical update in the product or procedures, and do not have an immediate impact on safety. These are collected by the training group and pushed out in a new revision on a regular basis, perhaps every two, four, or six months. In either case, revisions are made at the source document level, and then pushed out via XML to the CBT modules. This way, if there are revisions required to the CBT content beyond the shared XML content, (exam questions or anything unique to the CBT), the updates can be planned for and done all at one time making for a much more controlled and efficient process.

Ultimately, we were able to help our client achieve their goals of a training program that is more easily maintained, better controlled, and far more accessible to both their own personnel as well as their customer base. See what I mean? Training is fun.


View Scott McDonough's profile on LinkedIn

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

« Older Entries