http://tc.eserver.org/dir/SMEs A listing of the most recently indexed works about SMEs in the field of technical communication. en-us Copyright (c) 2005-08 by the EServer. All rights reserved. tclib-editorial@eserver.org (TC Library Editorial Board) webmaster@eserver.org (Geoffrey Sauer) http://tc.eserver.org/images/newlogo.gif http://tc.eserver.org/dir/SMEs http://tc.eserver.org/35601.html http://tc.eserver.org/35601.html An SME is someone who has been trained and has worked in the area that is being targeted for the new application. At Autodesk, we have found that pairing SMEs with Interaction Designers is the most efficient and successful way of meeting user centered design goals. http://tc.eserver.org/35378.html http://tc.eserver.org/35378.html Power user. It’s a term that I don’t like. But there definitely are people out there who are working with the software and hardware that we document who want more than just basic information. Getting them that information can be tricky. http://tc.eserver.org/35373.html http://tc.eserver.org/35373.html If you have ever worked with a developer or a development team, this article will probably strike close to home. As designers, we work with dozens of developers across the globe each year. Some of us are fortunate enough to find a gem; a developer that just gets it. A developer that you feel is on your same wavelength in terms of what needs to be accomplished with the user interface, and what it needs to happen. Most often, however, we find developers that we generally don’t see eye to eye with. http://tc.eserver.org/34910.html http://tc.eserver.org/34910.html I have a theory about why we continually see subject matter expertise for review applied to the task of copy-editing, and why that practice is so hard to change. The theory is built around how we: learn to write, learn to review, and ask for review. http://tc.eserver.org/34727.html http://tc.eserver.org/34727.html Getting even semi-publishable writing from experts is notoriously difficult; they may be immersed in their “real jobs” and too busy to write even a first draft of content, they may not understand why web content matters at all, they may not be fluent in the language(s) in which you publish your website, or they may just be terrible writers. Define a content workflow as early as possible, preferably as part of a unified content strategy that includes a content audit (a detailed analysis of what content you have, what content you need, and how to bridge that gap), voice and tone guidelines, and a schedule for collecting and generating content. http://tc.eserver.org/34687.html http://tc.eserver.org/34687.html At times, though, a writer is a bit overwhelmed at the start-of-work meeting. He becomes passive and takes in everything the client lays out without asking for more. That can result in some information that’s very important to the writer being missed. http://tc.eserver.org/34021.html http://tc.eserver.org/34021.html A technical writer will periodically need to interview Subject Matter Experts (SME) to gather information about a technical document. More often that not, and especially within the context of software development, most SMEs are engineers and software developers. But they can also be mechanical, electrical and other types of engineers, hardware installers, network engineers, testers, site foremen, call center engineers, field technicians, sales or marketing people, local dealers, etc. One cardinal rule of interviewing an SME is to do your homework well, in advance. http://tc.eserver.org/33874.html http://tc.eserver.org/33874.html I think one of the hardest things in technical writing, especially for new hires, is to be assigned to document a product or feature that you know nothing about. http://tc.eserver.org/33857.html http://tc.eserver.org/33857.html Who should you contract to update an outdated policies and procedures manual–subject matter expert or a policy and procedure writer? http://tc.eserver.org/32788.html http://tc.eserver.org/32788.html Send the mail to the person or group of people, but rather than asking the question, state what you know is the wrong answer. “I think the way it works is Foo, right Bob?” You'll be amazed at how quickly someone will take the time to correct you, particularly if the question was aimed at more than one person, since it's an opportunity for that person to prove their knowledge in front of others (which is just human nature). http://tc.eserver.org/32689.html http://tc.eserver.org/32689.html Technical editor or writer needs to close the gap between the subject matter expert and the novice. A close collaboration between the technical editor and the expert results in better manuals. http://tc.eserver.org/32694.html http://tc.eserver.org/32694.html This paper discusses tools and techniques for editors and writers who need to work with subject matter experts (i.e., engineers, programmers, accountants, etc.) to create plain language manuals. http://tc.eserver.org/32228.html http://tc.eserver.org/32228.html To obtain good reviews, you must make the process as painless as possible for reviewers. http://tc.eserver.org/32190.html http://tc.eserver.org/32190.html Focusing on your professionalism could be the key to successfully managing your working relationships with SMEs. http://tc.eserver.org/32193.html http://tc.eserver.org/32193.html Just the thought of dealing with Subject Matter Experts (SMEs) can create stress in the life of any documentation manager. Some SMEs can be self consumed, preoccupied, distant, and even rude. But why do these behaviors exist? This article briefly describes how to interact with people who might be difficult to motivate and how to work with people who have priorities different from yours. http://tc.eserver.org/31938.html http://tc.eserver.org/31938.html Outside of the formal SME interview, a writer's relationship with engineers and experts is built on trust, respect, and a little bit of bribery. http://tc.eserver.org/31889.html http://tc.eserver.org/31889.html A joke about what technical writers' heaven might be like. http://tc.eserver.org/31810.html http://tc.eserver.org/31810.html A case study of Danish SME managers’ understanding of CSR and CSR communication conducted in the beginning of 2007 concluded that CSR communication in SMEs is a practice rather than a corporate strategy. http://tc.eserver.org/31719.html http://tc.eserver.org/31719.html Just the thought of dealing with Subject Matter Experts (SMEs) can create stress in the life of any documentation manager. Philip Rastocny provides in-depth insight on how best to deal with SMEs. http://tc.eserver.org/31720.html http://tc.eserver.org/31720.html Part 2 switches the focus to members of your management team and what you can do to sell your team’s professionalism. Also included are hints on how your writers can individually sell themselves to gain cooperation from SMEs. http://tc.eserver.org/31146.html http://tc.eserver.org/31146.html Dokumentenmanagement schien immer eine teuere, aufwendige Angelegenheit der Großunternehmen. Die Einführung einer Document-Related-Technologies-Lösung gleich welcher Ausprägung erfordert Anpassungen an Infrastruktur, Abläufe und Arbeitsorganisation. Dies wollten sich bislang viele Mittelständler nicht leisten. Ihr Credo lautete: "Durch so ein elektronisches Dokumentenmanagement-System bekomme ich doch keinen einzigen Kunden mehr". Diese Situation hat sich geändert. Auch der Mittelstand wird zunehmend in elektronische Geschäftsprozesse eingebunden. Die Abhängigkeit von Software in Verwaltung, Logistik, Kundenbetreuung und Produktentwicklung wird immer größer. http://tc.eserver.org/31039.html http://tc.eserver.org/31039.html At nearly every conference I attend someone is talking about the need for Subject Matter Expertise for Business Analysts. The rationale is that someone versed in the language, ideas, and systems of a given organization or product will ask better questions and elicit better requirements from stakeholders. http://tc.eserver.org/30612.html http://tc.eserver.org/30612.html The purpose of this workshop is to introduce attendees to Total Quality Management (TQM) techniques and practices. TQM offers common-sense guidance in the quest for quality. Using the example of an out-of-control technical review cycle, the workshop shows attendees how to better manage the technical review process, resulting in accurate, high-quality documents. http://tc.eserver.org/30597.html http://tc.eserver.org/30597.html Double agents on writing teams provide benefits to both product developers and technical writers with their unique skills and perspectives. You'll be more likely to get the information you need when you need it because your double agent has already set the stage for success. Learn the benefits of having a double agent working with technical writers as a part of the product development team. Discover valuable secrets never before divulged to the public that you can use to work with your product developers. Take out your magnifying glass and look for the clues. http://tc.eserver.org/30587.html http://tc.eserver.org/30587.html Most companies want to be recognized for producing usable products, for the quality of products must be high if they are to be accepted into today's competitive market. However, usability planning relies on interaction with other departments and their members. In other words, the most successful way to ensure product usability is to set up a test team consisting of representatives from various departments. This paper details the members of that test team and discusses their overall responsibilities in the testing process. http://tc.eserver.org/30326.html http://tc.eserver.org/30326.html If listening isn't in the mix when developing documentation, then the project may not cook. http://tc.eserver.org/30255.html http://tc.eserver.org/30255.html In this podcast, I interview Brenda Huettner about strategies for overcoming the top 10 Worst Things Subject Matter Experts Say or Do. http://tc.eserver.org/30116.html http://tc.eserver.org/30116.html While technical writers may interview subject matter experts on a daily basis to gather information for a project, very few training courses address how to conduct these interviews. Singer's article provides suggestions. http://tc.eserver.org/30005.html http://tc.eserver.org/30005.html A 20 minute monologue about the best way to get information from SMEs--sit by them, permanently if possible. Many IT organizations station the writer remotely from the developers, programmers, and other SMEs, but nothing could be more damaging to getting the information you need. Increasing your proximity also increases the communication you receive. http://tc.eserver.org/29896.html http://tc.eserver.org/29896.html All of us have suffered the consequences of expensive, unasked questions both in our professional lives and our personal lives. As technical communicators, we need to ask good questions to elicit information, but many of us lack adequate training in this skill. Add to that the natural reticence of some technical communicators, and it's no wonder that we walk away from SME interviews or department meetings wishing we'd remembered to ask X, Y, or Z. This paper offers information as to why questions are so important, who needs to improve discovery skills, what process you should use to develop your questions, what types of questions are useful, how to strategize your questions, how to ask good questions, how to handle people answering the questions you ask them, and how to answer questions that are asked of you. http://tc.eserver.org/28850.html http://tc.eserver.org/28850.html As a programmer or developer, the Subject Matter Expert is concerned about developing code that is bug free and serves the client's purpose. They need to have task wise in-depth technical orientation, which often results in having a limited perspective of the user requirement. But those who wish to swap into the technical writing arena are required to have an in-depth overview and analytical outlook of the user perspective and the project in its entirety. As a Technical Writer, the Subject Matter Expert has to understand the user's mindset. Identifying the target audience, producing a document that will answer their questions readily and meeting their expectations is no easy job. http://tc.eserver.org/28176.html http://tc.eserver.org/28176.html Improving technical reviews, when subject matter experts, or SMEs, review content for technical accuracy, is a challenge every technical communicator faces sometime during their career. Every year, journal articles are published, presentations are made, and discussions are initiated on this very topic. Most of them conclude that SMEs are difficult. It's your job to bribe, cajole, or coerce a better review out of your SME. I don't agree. http://tc.eserver.org/25015.html http://tc.eserver.org/25015.html The SMEs had a choice between two sets of tables they could use to input key product data. If their part of the project used items from the A list, they were supposed to use table A. If their part of the product used items from the B list, they were supposed to use table B. In almost every case, the SMEs used the wrong table, leaving gaps where their information did not conform to the columns of the tables. http://tc.eserver.org/24358.html http://tc.eserver.org/24358.html The development of a modern software product is a complex process involving a variety of disciplines, including that of the technical writer. It is essential that the writers establish close relationships with all other groups in the process and that they build effective and efficient systems of communication between them. The job of the writing manager is to ensure that the writing team obtains the information it needs in a timely manner and that the group interacts effectively with other groups in the process. This can be achieved by a blend of intergroup communication, background research, documentation and schedule planning and a well organized documentation review process. http://tc.eserver.org/23573.html http://tc.eserver.org/23573.html The time-compressed training development methodology involves putting together a team of subject matter experts (SMEs), a designer/facilitator, and one or two scribes, then giving them the time and space required for focused effort in a three-phase approach. The three phases are: prework; development sessions; and, postwork. During the prework phase, a preliminary course outline and formats for the materials are developed. In the development sessions, the outline is refined, objectives are defined, and the content is developed. And, in the postwork phase, the materials are reviewed, refined, published, and distributed. http://tc.eserver.org/21407.html http://tc.eserver.org/21407.html I admit that I don't know everything about subject-matter experts or SMEs (rhymes with please). But I do know that there are some things that you should avoid asking SMEs, the main ones being 'Does the user know this already?' and 'Do I need to explain this to the user?' The problem with these questions is that the SME is likely to reply 'No!' to both of them when in fact the answer is most definitely 'Yes.' SMEs tend to believe that everyone knows as much about technology as they do. Never, never, never let the SMEs tell you how to write the documentation. A SME is the subject matter expert, not the documentation expert (that's you). http://tc.eserver.org/19687.html http://tc.eserver.org/19687.html Technical writers live in a state of anxiety. They are charged with creating a work within a specific time period, but they depend on the cooperation of subject-matter experts (SMEs) over whom they have no control. http://tc.eserver.org/19638.html http://tc.eserver.org/19638.html Although not rare birds in urban high-tech environments, technical subject matter experts (SMEs) are a fascinating species to observe—and a challenging breed for corporate communicators to manage. This tongue-in-cheek field guide identifies four common sub-species, and explains how to spot each by its distinctive markings and how to cope with its behaviors for companionable nesting. http://tc.eserver.org/19265.html http://tc.eserver.org/19265.html Interviewing subject matter experts (SMEs) is one of the most common and useful methods for obtaining the information needed to create quality documents. Successful SME interviews require careful research and preparation in advance. During the interview, good listening skills, critical analysis, and the ability to maintain control of the range and depth of the interview with appropriate tact are crucial to successful outcomes. After the interview, give prompt attention to notes and any required follow-through. When working with hostile SMEs or those with poor communication skills, emphasize the strengths of the relationship and develop strategies to work around any weaknesses. http://tc.eserver.org/18786.html http://tc.eserver.org/18786.html Working well with SMEs is essential to our success as technical communicators. This article recommends strategies to employ to improve your relationships with SMEs – seeking buy-in, increasing transparency and cross-functional teams, expressing expectations clearly, setting common goals and objectives, and making success a shared accountability. http://tc.eserver.org/14910.html http://tc.eserver.org/14910.html To meet the challenge of addressing the needs of subject matter experts (SME) and non-experts, alleviating fears, and keeping the public informed requires knowledge of communication theory, subject-matter expertise, and adherence to a code of ethics. A model illustrating the professional technical communicator's knowledge base and relationship with the SME and non-expert is presented. http://tc.eserver.org/14686.html http://tc.eserver.org/14686.html Brys discusses ways that technical communicators can lay foundations for good working relationships with subject matter experts. http://tc.eserver.org/14631.html http://tc.eserver.org/14631.html Lambe offers tips for gathering information from SMEs. http://tc.eserver.org/14497.html http://tc.eserver.org/14497.html Some of the more intractable problems we face on the job are the human ones. But cranky though Microsoft Word often seems, most of its blowups are at least predictable; humans are anything but. The worst problems can arise when you find yourself in a situation where power relationships come into play, which is often the case when you're managing another employee and responsible for their work and their on-the-job behavior. For a variety of reasons, technical communicators are often seen as 'difficult' or 'problem' employees--this means that co-workers tend to complain about us and insist that our managers correct our behavior. Unfortunately, we often work in high-stress environments that make it difficult for us to work calmly and difficult for colleagues to work with us peacefully. Many communicators complain that developers and other subject matter experts (SMEs) don't bother to understand what we do and thus, don't respect our work. As a result, they often consider meeting their own deadlines far more important than helping us do our work, and when we must ask them to provide the information we need to complete our documentation or to review draft documents, we don't get what we need. The result? We're forced to nag, and that can get us labeled as problems, not colleagues. http://tc.eserver.org/14146.html http://tc.eserver.org/14146.html As a technical writer, are you finding yourself wishing for just a bit of respect from the engineers, SMEs (Subject Matter Experts), or other technical people you work with? Are you finding that these folks seem to stonewall you on every question you have or every goal you're trying to achieve? Are they obstreperous? Difficult? Or just plain unhelpful? When I hear technical writers complaining about--er, describing--such troubles when working in a team environment, my first reaction is to want to sit and observe how they actually interact with those seemingly impossible team members. In my experience, I've found that the problem isn't always with a surly SME or with an engineer who lacks communication skills. Certainly, there are cases where other team members just don't value any contribution other than their own; however, most often, I have found the problem is with the technical writer's approach to the team environment--and have found that the problem began from the very start of that writer's involvement with the team. http://tc.eserver.org/13602.html http://tc.eserver.org/13602.html This article first reviews the current literature that addresses the value of the technical communicator. Whereas those discussions focus on what is delivered to the user (reader), this article examines the value the technical communicator adds by creating organization (internal) knowledge. The article then examines the philosophical underpinnings that support any discussion of knowledge and defines the role of technical communicators as creators of knowledge. Finally, it offers an expanded value proposition for technical communicators and examines its practical implications. http://tc.eserver.org/13487.html http://tc.eserver.org/13487.html It sounds like something from a late-night infomercial: Enhance your productivity by cranking out online help files in half the time! Increase your prosperity by being promoted to head of the documentation department! Improve your interpersonal relations so that Subject Matter Experts (SMEs) are just waiting to review your documents. Ensure a long and healthy life, despite the stress of vaporware product launches! If an advertisement lurking in your emailbox claimed to have an ancient secret to give you all the above, you'd likely press Delete faster than you can say 'looming deadlines.' But what if millions of people--some as well-known and successful as Donald Trump--and major corporations, such as Virgin Airlines, The Wall Street Journal, and Citibank, attested to this 'magic' secret's power? In that case, you just might sit back in your office chair and listen. http://tc.eserver.org/10415.html http://tc.eserver.org/10415.html Almost a decade ago, Walkowski's (1991) study of the interaction between subject-matter experts (SMEs) and technical writers focused on the perceptions of software engineers toward technical writers. Her findings gave technical writers insights on how to improve critical relationships with these organizational colleagues. This study partially replicates Walkowski's (1991) study of technical writer-SME interactions, but instead of collecting data from SMEs, we surveyed technical writers themselves. We report perceptions collected from 31 technical writers and contrast them with Walkowski's original findings, offering interpersonal and organizational recommendations for addressing tensions between these groups. By examining both the SMEs' and the technical writers' perceptions of their relationship, we are able to provide a two-sided view of a dynamic and complex interaction. We also argue that participants in the SME-technical writer interaction cannot fully alter their relationship without the strategic supp http://tc.eserver.org/10350.html http://tc.eserver.org/10350.html Technical communicators frequently collaborate in workplace projects and bring a host of different kinds of expertise to this collaboration. Yet the understanding of communicators’ expertise among managers and subject matter experts is grounded in a view of writing as a finished product and authorship as singular. This article documents many different kinds of 'contributory expertise' employed by writers collaborating to produce articles for publication. Expertise in research, textual composition, visual composition, as well as other kinds of expertise garnered on previous projects is often brought to collaborative projects. Often emerging and developing as a function of collaborative work is expertise in framing the project, conducting review processes, and assessing outcomes. These categories are discussed in some detail to provide practicing communicators with ideas for documenting expertise in their specific workplaces, to provide students with ideas for developing expertise in various areas, and to prov