A directory of resources inthe field of technical communication.

SMEs

68 found. Page 1 of 3.

About this Site | Advanced Search | Localization | Site Maps
 

1 2 3  NEXT PAGE »

A Subject Matter Expert (SME) is a person who is an expert in a particular area. In technical communication environments, the term is used to describe professionals with expertise in the field of application but without documentation, procedural discourse, or project management knowledge. Technical communicators often collaborate with SMEs both prior to and during the editing of technical writing projects.

 

1.
#33874

Asking Questions is Key

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.

Technically Speaking (2009). Articles>Interviewing>Technical Writing>SMEs

2.
#19687

Avoiding Developer's Anguish  (link broken)   (PDF)

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.

McKelvey, Paul S. Intercom (2003). Careers>Writing>Collaboration>SMEs

3.
#36618

Becoming the Friendly Neighborhood Tech Writer

Since much of technical writers do is gather information from other people, be respectful of their time. Don’t ask for a minute unless you literally want 60 seconds of their time or less. If I have what I think is a brief question requiring a brief answer, I ask, “Hey Dan, do you have a few minutes to answer a question, or should I come back later?” They’ll usually be honest about whether they need to finish something first or if they can give me their full attention right then.

Minson, Benjamin. Gryphon Mountain (2010). Articles>Collaboration>SMEs

4.
#25015

Boilerplate

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.

Hewitt, John. Writer's Resource Center (2005). Articles>Writing>Technical Writing>SMEs

5.
#34021

The Cardinal Rule of Interviewing a Subject Matter Expert (SME) For a Document

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.

Akinci, Ugur. Technical Communication Center (2009). Articles>Interviewing>Technical Writing>SMEs

6.
#36506

Commenting on Writing: Typology and Perceived Helpfulness of Comments from Novice Peer Reviewers and Subject Matter Experts   (PDF)   (peer-reviewed)   (members only)

How do comments on student writing from peers compare to those from subject-matter experts? This study examined the types of comments that reviewers produce as well as their perceived helpfulness. Comments on classmates’ papers were collected from two undergraduate and one graduate-level psychology course. The undergraduate papers in one of the courses were also commented on by an independent psychology instructor experienced in providing feedback to students on similar writing tasks. The comments produced by students at both levels were shorter than the instructor’s. The instructor’s comments were predominantly directive and rarely summative. The undergraduate peers’ comments were more mixed in type; directive and praise comments were the most frequent. Consistently, undergraduate peers found directive and praise comments helpful. The helpfulness of the directive comments was also endorsed by a writing expert.

Cho, Kwangsu, Chris Schunn and Davida Charney. Written Communication (2006). Articles>Editing>Assessment>SMEs

7.
#38683

Conducting Successful Interviews With Project Stakeholders

Looking back over recent months, by far the most common form of research I’ve carried out is that stalwart of qualitative studies—the interview. A simple, semi-structured, one-on-one interview can provide a very rich source of insights. Interviews work very well for gaining insights from both internal and external stakeholders, as well as from actual users of a system under consideration. Though, in this column, I’ll focus on stakeholder interviews rather than user interviews.

Baty, Steve. UXmatters (2007). Articles>Collaboration>Interviewing>SMEs

8.
#19265

Conducting Successful SME Interviews  (link broken)   (PDF)

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.

Lambe, Jennifer L. STC Proceedings (2002). Articles>Interviewing>Writing>SMEs

9.
#34727

Content Templates to the Rescue

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.

Kissane, Erin. List Apart, A (2009). Articles>Content Management>Content Strategy>SMEs

10.
#31810

CSR Communication: A SME-Oriented Approach  (link broken)   (PDF)

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.

Nielsen, Anne Ellerup and Christa Thomsen. Association for Business Communication (2008). Articles>Business Communication>Collaboration>SMEs

11.
#36396

Cures for the Information Exclusion Complex

Some years ago, I used to suffer from developer neglect, or to use a more scientific term, from a kind of information exclusion complex. You know what I’m talking about. Developers make updates to the interface, often at the last minute, and don’t let the tech writer know what changed. As a result, the help is wrong and out of date. It’s a frustrating experience from the writer’s perspective.

Johnson, Tom H. I'd Rather Be Writing (2010). Articles>Collaboration>Technical Writing>SMEs

12.
#14497

Dealing with Difficult Employees in the Technical Communication Workplace

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.

Hart, Geoffrey J.S. TECHWR-L (2002). Careers>Management>Collaboration>SMEs

13.
#37146

The Design Difference: A Survey of Design and Innovation Amongst Ireland’s SMEs   (PDF)

Irish companies that use design are more successful than those that do not. Why are companies that use design more successful than those that do not? We don’t fully know why – yet – but the research tells us that companies using design are less risk averse and more likely to be developing new products and services. It also tells us they’re less likely to be competing on the basis of price. It suggests that they’re growing and succeeding because they’re innovating and moving. They’re not waiting on the challenges of the global economy, they’re using design to meet them head on.

Center for Design Innovation (2007). Presentations>User Experience>SMEs>Ireland

14.
#10350

Documenting Contributory Expertise: The Value Added by Technical Communicators in Collaborative Writing Situations    (peer-reviewed)   (members only)

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

Henry, James M. Technical Communication Online (1998). Articles>Writing>Collaboration>SMEs

15.
#31146

Dokumentenmanagement für den Mittelstand   (Word)

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.

Kampffmeyer, Ulrich. Doculine (2002). (German) Articles>Content Management>SMEs

16.
#14686

Essentials of Successful Cooperation  (link broken)   (PDF)

Brys discusses ways that technical communicators can lay foundations for good working relationships with subject matter experts.

Brys, Catherine M. Intercom (2001). Careers>Workplace>Collaboration>SMEs

17.
#14146

Establishing and Building Mutual Respect with Technical Team Members  (link broken)

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.

Ray, Eric J. TECHWR-L (2002). Careers>Collaboration>Workplace>SMEs

18.
#13487

Feng Shui for the Tech Writer's Workspace

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.

Chroust Ehmann, Lain. TECHWR-L (2002). Careers>Workplace>Ergonomics>SMEs

19.
#35378

A Few Thoughts on Documentation for the Power User

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.

Nesbitt, Scott. DMN Communications (2009). Articles>Documentation>Audience Analysis>SMEs

20.
#19638

A Field Guide to Technical SMEs   (PDF)

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.

Lange, Penny L. Intercom (2003). Careers>Writing>Technical Writing>SMEs

21.
#38118

Getting the Right Stakeholder Feedback at the Right Time

Efficient, effective collaboration between UX designers and stakeholders is an essential ingredient of a successful project. Stakeholders bring their unique perspectives to a project, and their feedback can help a designer understand the design problem space and develop solutions that align with business and technology objectives. But simply asking stakeholders for feedback can lead to misaligned expectations and communication problems. By being thoughtful in how you make your request for feedback and by providing simple questions and instructions, you can ensure that you identify potential risks early in the design process, minimize stress, meet your deadlines, and ultimately design a better solution.

Hawley, Michael. UXmatters (2011). Articles>Collaboration>User Experience>SMEs

22.
#35373

How To Effectively Communicate With Developers

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.

Scherf, Ryan. Smashing (2009). Articles>Collaboration>Programming>SMEs

23.
#32788

How to Get Someone to Answer Your Questions

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).

Lemson, K.C. KC on Exchange and Outlook (2008). Articles>Collaboration>SMEs

24.
#30116

How to Interview Subject Matter Experts  (link broken)   (PDF)

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.

Singer, Warren. Intercom (2007). Articles>Interviewing>SMEs

25.
#28176

Improving Technical Reviews

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.

Idoura, Alexia. Carolina Communique (2004). Articles>TC>Collaboration>SMEs

 
 NEXT PAGE »

 

Follow us on: TwitterFacebookRSSPost about us on: TwitterFacebookDeliciousRSSStumbleUpon