Teri Catanio_Action Research Project

Running Head: On-Going Training for Documentation Teams

Integrating On-Going Training for Documentation Teams in

Information Technology Organizations

Submitted by Teri W. Catanio

In partial fulfillment of the requirements for the degree,

Masters of Science in Organizational Leadership

Philadelphia Biblical University

School of Business and Leadership

Langhorne, PA 19047-2990

May 2007

On-Going Training for Documentation Teams 2

Table of Contents

Page

Chapter 1. Introduction and Statement of Problem ........................................................... 3

Chapter 2. Literature Review...............................................................................................9

Chapter 3. Intervention Design ..........................................................................................19

Chapter 4. Intervention Implementation ............................................................................23

Chapter 5. Presentation of Findings and Results ...............................................................32

Chapter 6. Reflections, Conclusions and Recommendations ...........................................47

Bibliography ......................................................................................................................51

Appendix A. Telephone Interview Format ...................................................................... 53

Appendix B. On-site Visits and Personal Interview Questions ........................................54

Appendix C. Surveys .........................................................................................................55

Appendix D. Training Assessment Study ..........................................................................59

Appendix E. Focus Group Discussion Questions ..............................................................61

Appendix F. Consent Form ................................................................................................62


CHAPTER ONE: INTRODUCTION AND STATEMENT OF PROBLEM

Introduction

The technical communication profession covers a broad spectrum of scientific and

electronic technologies. The nature of this type of information is complex, and therefore is

carefully documented for knowledge sharing with subject matter experts and the non-technical

layperson. Although scientists and engineers create this complex information that impacts

society and the world, the scope of their job does not entail communicating the information to

the layperson. Practitioners in the field who specialize in communicating this complex

information are referred to as technical writers or more recently technical communicators,

exemplifying a combination of technical writing and design skills. The focus of this research

study will spotlight those practitioners within technical documentation teams that create and

design end user manuals for information technology (IT) organizations (i.e., computer

electronics, software, and telecommunications).

Overview of Documentation Teams in IT Organizations

IT organizations go to great lengths to staff, equip and train their engineering, product

marketing, and sales teams. In contrast, documentation teams have been overlooked and at times

treated as second-class citizens (Wilson & Ford, 2003). Instead of being embraced in a

collaborative environment with other work teams, technical communicators have agreed that IT

organizations often tend to view documentation as an afterthought (Wilson & Ford, 2003).

Although documentation may be a mere after thought, this researcher would argue that the

practitioner who compiles and records this complex information is an invaluable resource in any

IT organization, particularly in today’s technology-driven information age.


The documentation team compiles and documents fundamental information about each

product, which is then made available for customers, clients, and the overall organization to view

and critique. One of the main functions of a documentation team is to produce a comprehensive

end user manual that describes a product’s functionality and features in a clear and concise

manner. The documentation team must have a general working knowledge of the organization’s

product line and a broad understanding of the IT industry in an effort to translate somewhat

confusing jargon and complex terminology into plain, simple language for the non-technical

user, as well as communicate on a higher level with the subject matter expert. Therefore, it is the

goal of the documentation team to generate material based on their target audience.

The user manual is the end result of work prepared by a technical documentation team.

The once bulky user manual has evolved into a slick, easy to transport compact disk that is

available in a variety of shapes and sizes or online. Frequently it is the selling tool used at client

meetings and industry trade shows to provide specific details about a product or to simply depict

the product via pictorial illustrations. Although documentation teams are not considered subject

matter experts, ironically, the user manual is where the various work teams within the

organization obtain an overall comprehensive picture of the final product.

Internet technology has made it possible for documentation teams to transition from

paper-based publishing to electronic publishing, saving valuable time and cost. Prior to that,

writers factored in as much as three weeks of print time to the production schedule, which cut

deeply into the important communication, writing and design process. Although production of

the user manual today is considerably more cost effective and time efficient, it does require the

documentation team to be technically adept at using various state-of-the-art software tools.


The average technical writer is either liberal arts-trained or has a strong technical

background in electronics. A job posting for a technical writer often desires someone with an

undergraduate discipline in Computer Science, but rarely does a degreed computer scientist find

him or herself in the role of a technical writer, a further testament to the importance of on-going

training for a documentation team.

For the most part, the technical writer simply needs to have a good command of the

English language, good verbal and written skills, solid analytical skills, a broad knowledge of the

IT industry, and expert level proficiency in the personal computing environment using various

office tools (i.e., word processing, graphics, project management, and spreadsheet software),

desktop publishing, and documentation design software. Advanced and sought after technical

writers are more valued if they can use web-based authoring tools, such as HyperText Markup

Language (HTML), Extensible Markup Language (XML), or Standard Generalized Markup

Language (SGML).

The technical writer must be analytical and skillful at interviewing members of other

work teams within the organization to glean specific details about the product, so that he or she

can compile the information into some semblance of how a product functions, how the product

fits into the organization’s overall product line, and how the product relates to or impacts

industry. In addition, the technical writer must be technically adept at working with electronic

equipment, reading engineering schematics, as well as installing and using software, so that he or

she can test a product’s functionality and features to ensure that it works according to client

specifications. Once the information is compiled, the technical writer records how to set-up,

install, and configure the product in a comprehensive, readable format using standard word

processing or desktop publishing software. The document is then converted into a Portable


Document Format (PDF), HTML, XML or SGML file, for public viewing and availability on the

Web or delivery on CD-ROM. To help readers with ease-of-use, the technical writer will also

include online help and hyperlink cross-references throughout the document to guide readers as

they navigate through the manual.

The Problem at Hand

There are many problems documentation teams experience that are both behavioral and

structural in nature. This research study will focus on one structural problem that many

documentation teams encounter. The technical communication profession is driven by

technological advancements in software, presenting technical writers with new tools to create

and design user manuals. The problem is twofold: 1) the documentation team’s inability to keep

pace with new software tools, and 2) insufficient training on new and existing tools that the team

uses to perform their work.

The first component of the problem involves the inability to keep up with new software

technology. Time constraints in an organization’s project-driven development cycle are a major

factor. Constant deadlines often restrict documentation teams from acquiring the necessary

information on the latest software tools that could make their jobs easier and more efficient. In

addition, work schedules compete with the technical writer’s time to gather knowledge about

how the new software tool works, how it might fit into the department’s current way of

electronic publishing, design, and knowledge management, how it is currently being used by

others in the profession, and how the tool’s features set it apart from and put it ahead of the

competition.

The second component of the problem involves inadequate training on existing software

tools. According to Grice and Krull (2001), technical communicators need to quickly learn new


tools and drop existing ones in an effort to renew skills and keep pace with technology. Even

though this may appear to be a simple matter of upgrading software, this can be quite a dilemma

for technical communicators. Advancements in software technology have left many technical

documentation teams in a quandary over what tools should be utilized within the department to

unify the look and feel of the end user manuals, and yet not be so complicated to learn and use

that it impinges upon the writer’s ability to perform his or her job.

Veteran practitioners usually don’t want or like to change from what they are comfortable

with and have been using over a long period of time; often holding steadfast to the cliché, “if it

ain’t broke, don’t fix it.” In contrast, the more computer savvy practitioners feel frustrated and

stifled at not being able to use the slick animation software and design tools for illustrations and

layout or the latest timesaving tools to expedite the project. The technical publications manager

is usually left with the difficult task of trying to determine a reasonable compromise, which can

typically lead to discord among the team.

Statement of the Research Problem

The research problem under consideration is to understand what methodologies of team

dynamics can be utilized to develop and implement on-going training and development to

support technical documentation teams in IT organizations. In this researcher’s career experience

as a technical publication manager, senior technical writer, and contract technical writer-editor

with various IT companies, the technical documentation team is vastly overlooked and

undervalued. Because IT organizations don’t fully understand how to best utilize a

documentation team, the team often finds itself in the role of second-class citizen (Wilson &

Ford, 2003). Documentation teams are usually under such time constraints to produce the end

user manual that there is barely enough time to fully understand the complexity and functionality


of the organization’s new product deliverable, let alone become proficient on the very software

tools that are supposed to make the overall writing and publishing tasks more efficient. Thus, the

dichotomy of keeping abreast of new software tools and insufficient training on existing tools,

has led to frustration and disharmony within documentation teams.

Hypotheses

The researcher hypothesizes that by using various methodologies in team dynamics and

organizational learning, steps can be taken to: 1) motivate documentation teams to incorporate

on-going training in their work schedule; 2) inspire the technical publication manager to be open

to change, and foster an atmosphere of support and encouragement, so that team members can

stay current with the demands of their profession; and, 3) enhance organizational learning by

exposing stakeholders to the unique function and contribution that documentation teams bring to

the organization. The researcher further hypothesizes that the integration of on-going training for

documentation teams in IT organizations will enhance individual competency and improve team

performance, as well as influence new learning in IT organizations.

Purpose and Objective

The purpose of this research study is to determine if the integration of on-going training

in the work schedules of documentation teams would enhance individual competencies and

improve team performance. In this regard, the researcher’s main objective is to devise an

intervention for documentation teams utilizing various mechanisms of team dynamics.


CHAPTER TWO: LITERATURE REVIEW

Introduction

“For just as we have many members in one body and all the members do not have the

same function, so we, who are many, are one body in Christ, and individually members one of

another” (NASB, Romans 12:4&5). Even though the apostle Paul was explaining unity through

diversity to Christians in the early church using the metaphor of the body, these verses capture a

timeless biblical truth that can be applied to work teams in organizations today. Based on this

passage of Scripture, those in organizations can glean from Paul’s message that each individual

has a unique function within a team, and each team has a unique function within an organization.

Thus, not everyone can do it all, but should instead seek to work together as a unified team for

the overall health and effectiveness of the organization.

When a team does not work together, Coghlan (1998) suggests that it is dysfunctional

and limits the team’s effectiveness within the organization. Documentation teams, when

effective, add value to an organization as they help to build and create a public identity both

internally and externally (Wilson & Ford, 2003). This public image is typically displayed on the

organization’s web site, as well as in its user manuals. In contrast, without the right software

tools, documentation teams can tarnish an organization’s image. This can be especially

detrimental for competitive IT organizations, since being on the cutting edge of technology is

crucial to their very survival in the marketplace. Thus, image is vitally important.

As stated earlier, the technical communication profession is driven by technological

advancements in software, presenting technical writers with new tools to create and design user

manuals. The documentation team’s inability to keep pace with new software tools and


insufficient training on existing tools is the context in which the following topics are examined in

this literature review:

The dynamics of documentation teams;

Perceptions, expectations, and misconceptions of documentation teams;

A few words on knowledge management; and

A brief look at the past, present, and future of the technical communication profession.

The Dynamics of Documentation Teams

Advances in software technology have changed the face of documentation teams in IT

organizations. These teams are no longer relegated to the singular task of writing user manuals.

Today, documentation teams have expanded their role in IT organizations to encompass content

writers, visual layout designers, usability testers, and knowledge management specialists (Grice

& Krull, 2001). With the constant changes in software technology, practitioners are feeling the

pressure to stay current in their field. However, in doing so technical writers are experiencing

frustration, exhaustion, and burnout (Wilson & Ford, 2003). In a list serve (i.e., electronic chat)

discussion group conducted by Wilson & Ford (2003), several technical communicators agreed

that the desire to keep up with technological advances in software tools is difficult and leads to

professional burnout sooner rather than later. Burnout or not, practitioners have a real concern

about staying current with software technology because it defines their profession, and has a

direct correlation with the writers’ earning capacity and demand in the job market.

A study of 3,200 U.S. companies, conducted by Zemsky and Shaman, revealed that a 10

percent increase in spending for employee training and development lead to an 8.5 percent

increase in productivity; whereas, a similar increase in capital expenditures lead to a 3.8 percent

increase in productivity (Bennis, 1999). This study greatly emphasizes the importance of training


and development for work teams. However, technical writers have little time or opportunity to

sharpen or develop their skills (Gould, 1968). Grice & Krull (2001) suggest organizations

support technical writers in learning new software tools with time and overhead cost dedicated to

training and education. Technical communicators in the list serve discussion propose technical

publication managers advocate on behalf of their documentation teams to communicate with and

educate their direct managers on professional growth and the need to stay current (Wilson &

Ford, 2003). Gould (1968) suggests that organizations employ in-house training programs, such

as systematic training seminars, are a good approach to the problem.

Another contributing factor to the problem documentation teams experience with

keeping pace with new software tools and insufficient training on existing tools is the ratio of

engineers to writers in the organization. A typical documentation team in an IT organization can

consist of anywhere from three to five individuals. Thus, it is not unusual for a documentation

team to consist of only two individuals, depending on the size and structure of the organization.

A web survey conducted by the Society of Technical Communicators Suncoast Chapter, a

professional organization for technical communicators, found that the average ratio of technical

writers to engineering developers is 1:20 for the IT industry (Johnson, 2006). This disparity in

the ratio of engineers to technical writers can further propagate the feeling of being undervalued

and overlooked amongst the documentation team. Obviously there is no need to have as many

technical writers on a documentation team as engineering developers in an IT organization, but

the workload generated by the engineering team can hinder opportunities for documentation

team members to investigate new tools that might help the team accomplish their work more

efficiently. It is no wonder why many technical writers experience frustration and burnout as

they try to keep pace with the latest advancements in software tools for their trade.


Perceptions, Expectations, and Misconceptions of Documentation Teams

Thus far, the research literature has shown that practitioners in the technical

communication profession identify keeping pace with advancements in software tools and

insufficient training on existing tools as problematic for technical writers. These writers also see

a lack of awareness and value in regard to their roles and contribution to the organization as

disheartening and even debilitating at times (Wilson & Ford, 2003). This researcher would argue

that how a team perceives itself in terms of its purpose and contribution within the framework of

an organization could impact the overall effectiveness of the team going forward. To create an

effective team, Parker (1996) suggests team leaders get to know each team member and share

concerns, define the team’s purpose and openly answer questions regarding the future direction

of the team, clarify roles for each team member, and establish norms or acceptable behavioral

guidelines for the team. In this regard, documentation teams can begin to understand how they fit

into the overall scheme of the organization. Hence, on-going learning and the facilitation thereof

are embedded in the culture of a good organization.

IT organizations struggle to utilize their documentation teams to their full potential

because they lack knowledge and understanding of the team’s function and capability. As a

result, low expectations can place documentation teams in the role of word processors, grammar

checkers or software testers. Documentation teams may fall short of not articulating and

educating other work teams of their function and unique contribution to the organization. In an

effort to increase organizational awareness, technical publication managers must lead the

endeavor to educate engineers, as well as other middle- and upper-level managers about the role

of the documentation team. Technical publication managers must in turn value their team by


demonstrating support via open communication, incentives, recognition, and most importantly

on-going training (Wilson & Ford, 2003; Grice & Krull, 2001; Gould, 1968).

Sundstrom (1999, P. 7) defines a work team as, “interdependent individuals who share

responsibility for specific outcomes for their organization.” Although members of documentation

teams share the responsibility for the outcome of the user documentation, more often than not,

team members work autonomously when tackling their assignments. Deci & Ryan (2000) pose

the self-determination theory, that groups want autonomy, competence, and relatedness.

However, this researcher would argue that it is the lack of competence that sets the stage for

problems within the group environment. It is actually this autonomy that can lead to disharmony

amongst the documentation team, particularly in the final phase of the work process when

assignments are quickly approaching deadline, and not everyone is at the same skill level in the

use of various software publishing and design tools. According to Coghlan (1998), it is at this

juncture when an individual’s inability to properly manage new technology and unrealistic time

frames can affect his or her ability to cope and function effectively for the team. Against this

backdrop, low levels of trust and poor communication can develop within the team if the

problem is ignored. Parker (1996) suggests individuals must have enough confidence in their

relationship with the manager and other team members that they can reveal their strengths and

weaknesses without fear of embarrassment, reprisal, or in such a way that it would have a

negative impact on their future in the organization.

Common misconceptions about documentation teams are that no one reads the user

manuals and anyone can write user manuals. Yet, it is not unusual for critics to come out of the

woodwork to point out discrepancies within a user manual or disunity from one user manual to

another. While most IT organizations use a database program to track such complaints, from an


organizational perspective, any inconsistency within the user manuals gives the appearance of

poor quality and implies incompetence within the documentation team. These misconceptions

only feed the stereotype that engineers and other work team members have of documentation

teams. Wilson & Ford (2003) suggest that this kind of oversimplification of the ability to

interpret and write complex communication leads to a diminished perception of documentation

teams.

These misconceptions can be disheartening for a documentation team that works hard to

prove its value and worth in the organization. To counteract these misconceptions,

documentation teams give legitimacy to the problems of poor quality and disunity with the user

manuals. Instead of addressing the real problem of inadequate training on software tools,

technical publication managers go for the quick fix and establish departmental standards via

policies, procedures, and style guides for team members to follow. The lack of a unified look and

feel to the user manuals is a superficial problem that is easily remedied. However, it is a

temporary solution that only masks the real underlying problem. According to Senge (1990),

failure to grasp the source of the problem leaves teams to “push on” symptoms rather than to

work to eradicate underlying factors. Technical publication managers must dialogue with team

members to find out why there is inconsistency in the user manuals by asking what software

tools are being used to perform what function, whether everyone is comfortable with the current

software tools, whether additional training is required, and if there are other tools on the market

that make more sense to use that will accomplish the team’s goals. These types of questions

should serve to motivate the documentation team, so that everyone can have input on the

software tools that will be used, as well as the future direction of the team.


A Few Words on Knowledge Management

The latest buzzword in IT circles is knowledge management, but according to Hansen,

Nohria & Tierney (2001), sharing knowledge is an age-old business practice. Nevertheless,

leaders are looking to best practices to model knowledge management in their organizations, and

perhaps not fully understanding its significance, have relegated this important task to

documentation teams. In a knowledge economy where information is globally exchanged,

documentation teams have a unique opportunity to function as the central hub of information

sharing within their organization.

Knowledge management has become a practical issue in the 21st century organization,

and knowledge workers, such as documentation teams, contribute to the organization’s success.

According to Hansen, Nohria & Tierney (2001), an organization’s knowledge management

strategy is reflective of its competitive strategy. Bennis (1999) suggests that leaders will have to

do more to manage knowledge or risk the organization’s future. Going forward, effective leaders

will have to re-evaluate how they view knowledge sharing, and the knowledge workers (i.e.,

documentation teams) that actually manage the organization’s knowledge.

Past, Present, and Future of Technical Communication

In its most basic form, interpreting and communicating scientific or technical information

into language that provides clear, descriptive information or instructions for subject matter

experts or the layperson is technical writing. O’Hara (2001) dates the profession back to World

War II, identifying the need of the United States Military to document standardized procedures.

After the war, companies like General Electric, Westinghouse, and General Motors employed

technical writers as transistor technology generated an interest and growth in the marketplace for

commercial and consumer electronic goods (Staples, 1999; O’Hara, 2001).


According to Grice (2002), engineers and programmers who developed products for the

large mainframe computers (circa 1960s) typically wrote the documentation for other technically

skilled individuals in computer operations. However, a shift in the footprint of computers and

their use became evident in the 1970s as computers became smaller and affordable for the

average consumer (Grice, 2002). Consumers were not concerned with the inner-workings and

details of the computer or the software, but rather how the computer and software could make

their work more efficient. Thus, a technical writing job meant working directly with the

engineers and programmers to translate and document installation, setup, and how-to instructions

for a whole new market, the non-technical consumer.

The profession continued to evolve in the 1990s and into the millennium as constant

changes in information technology transformed the singular role of the technical writer into a

multi-skilled technical communicator specializing in document design and knowledge

management. “Many who develop and produce technical information today work as members of

user-centered design teams. The distinction between development roles has blurred somewhat,

and product developers work as collaborators, not friendly adversaries, to get the job done”

(Grice, 2002, P. 128).

As the role of the technical writer evolves from wordsmith to information designer to

knowledge manager, what does the future hold for those in the profession? According to Grice &

Krull (2001), future developments in the field of technical communications will demand

practitioners to have more than the basic core writing skills; they will be challenged to acquire

skills in audience analysis, print and web design, content production, and even more advanced

software tools. Rockley (2001) contends the future role of technical communicators will be a

combination of knowledge management specialists, content management specialists, information


architects, and information technologists. Other authors (Eble, 2003; Ament, 2003; Rockley,

2001) see single sourcing, a method of re-using and structuring information in a modular format

for a wide range of audiences, as the future role for technical communicators. In contrast, Marsh

(1999) argues that recent trends in corporate downsizing and consolidation will force engineers

to become their own technical communicators in the future.

In today’s information-driven society, IT organizations continue to rely on their

documentation teams to perform a variety of information and knowledge management tasks, thus

freeing up engineering teams to create new and emerging technology. As a result, whatever the

future holds for the technical communication practitioner, it is certain that “technical

communication is the indispensable clearing house for information and ideas in an era of rapidly

accumulating knowledge” (Longo, 1998, P. 45).

Summary

Driven by advancements in the use of software tools for their profession, practitioners

find it difficult to keep up with the rapid changes in technology. Many authors identify on-going

training as key to staying current and competitive in the technical communication profession.

While there does not appear to be any let up in this trend, Grice & Krull (2001) warn

practitioners not to become defined by the tools of their trade. However, practitioners must be

ready to shift with technology, drop existing tools, and take on new tools.

Documentation teams play a unique role in IT organizations as they help to build and

create a public identity through the end user manuals and corporate website, as well as maintain

intellectual knowledge through knowledge sharing and management. Technical publication

managers must lead the effort to promote awareness of the documentation team’s multi-level


capabilities and unique contribution to the organization by articulating and educating other work

teams.

As technical publication managers establish best practices for their team going forward,

managers must show support by integrating on-going training into work schedules. This on-

going training and development should alleviate burnout, build trust, and most important,

enhance individual competencies that will improve team performance, and in effect, influence

new learning in the organization. Documentation teams must learn to be open to change and

communicate their professional needs. Technical publication managers must foster an

atmosphere of support and encouragement, so that team members will rely on each other’s

strengths to become a valued and respected high performance team within an IT organization.


CHAPTER THREE: INTERVENTION DESIGN

Keeping pace with new software design tools and insufficient training on existing tools

has led to frustration and disharmony within documentation teams in IT organizations. It is the

intention of this researcher to show how the integration of on-going training for documentation

teams will enhance individual competency and improve team performance, as well as influence

organizational learning.

The researcher will utilize mechanisms of team dynamics and various research

methodologies to collect data from three documentation teams in three different IT

organizations. The planned research approach will be managed in five phases, as outlined in the

following text.

First phase – quantitative interview method

The objective in phase one is to make initial contact with each organization and collect

general demographic data (estimated time: 20 minutes). The researcher will conduct a

quantitative interview via telephone (refer to Appendix A) with each documentation team

manager to obtain demographic information about the teams and their respective organizations.

The researcher also plans to set up site visits with each organization for the second phase of this

project.

During the telephone interview, the researcher will determine each documentation team’s

ability to participate in a two-week training study during the fourth phase of this project, as well

as each documentation team’s availability to participate in a focus group or online interactive

group discussion during the fifth phase of this project.


The specific objective in this phase is to introduce the researcher and documentation team

manager, explain the purpose of the research project, and gather enough data to establish criteria

for the next phase of the intervention design.

Second phase – qualitative interview method

The objective in the second phase is to build relationships with each documentation team

and collect data (estimated time: 1 hour). The researcher will conduct qualitative or face-to-face

interviews (Refer to Appendix B) with each documentation team manager. There are several

goals to accomplish in this phase: 1) visit each work site, 2) clarify the nature of the research

project, 3) clarify the level of the organization’s participation, 4) explain to what end the research

will be used, 5) obtain permission and consent, 6) meet all team members, 7) observe teams in

their environment, 8) observe the interaction with other work teams, and 9) observe the culture

of each organization (i.e., artifacts, espoused values, and organizational climate).

This phase will also give each documentation team manager and the researcher an

opportunity to discover and learn from one another using open-ended questions during the

interview. The researcher hopes to discover where the documentation team fits into the

organizational reporting structure, the number of engineers in comparison to the number of

technical writers, and the physical location of the documentation team in relation to other work

teams.

Third phase – quantitative and qualitative survey method

The objective in this phase is to identify emerging themes (estimated time: 20 minutes).

The researcher will conduct a survey (refer to Appendix C) of approximately 25 questions of

various types, including multiple choice, ratings, and short answers. The survey topics will be

divided into three parts to help the researcher assess the current state of each team, assess


individual skills with industry standard software design tools, and assess individual training

needs. The participants will consist of documentation writers in all three organizations. The

researcher estimates anywhere from 10 to 20 participants will take part in the survey. Again, the

objective in this phase is to identify emerging themes that will be further explored in the fifth and

final phase of the intervention design.

Fourth phase – training assessment study

The objective in this phase is to measure changes in individual competencies and team

performance when documentation teams integrate training into their daily work schedules

(estimated time: Up to one hour per day for two weeks). The researcher will design an integrated

training assessment (refer to Appendix D) and distribute it to each of the three documentation

teams. The training will vary, and for the most part consist of participants determining what tool

or area they need improvement or additional learning in, and spend time reading or practicing to

develop that skill. Participants will be given a set of guidelines and log sheets, in which to record

individual progress on a daily basis. Individuals will work at their own pace as they execute the

training over a two-week or 10-day period. Depending on the outcome of the initial telephone

interview with each documentation team manager from the first phase, the researcher will

determine if all three teams will be administered the same training for this study, or if each team

will be given a variation of the integrated training assessment. The desired goal is to measure

changes in individual competencies and team performance when documentation teams integrate

training into their daily work schedules.

Fifth phase – focus group method

The objective in this phase is to clarify themes (estimated time: one hour). Based on

schedules and proximity of each organization, the researcher will determine if an online


interactive discussion (i.e., chat room) or teleconference discussion is more feasible to administer

than a face-to-face focus group discussion. The researcher intends to create a list of questions

(refer to Appendix E) generated as a result of the data gathered from the survey, integrated

training assessment study, and onsite interviews to stimulate a focus group discussion either

online or via teleconference with members from all three organizations. The main objective of

this phase is to clarify and validate themes stemming from previous phases, as well as identify

new or emerging themes as an outcome of the group discussion.


CHAPTER FOUR: INTERVENTION IMPLEMENTATION

As outlined in the previous chapter, the intervention design component of the research

project was divided into five phases. Different data collection methodologies were laid out for

each phase, including telephone interviews, onsite visits and personal interviews, a three-part

survey, an integrated training assessment study, and a focus group discussion. This chapter

details the researcher’s experiences during each phase of the intervention implementation.

First phase – initial e-mail contact and telephone interviews

With the help of a LaSalle University professor and LaSalle’s Computer Science

Advisory Board, the researcher was able to obtain three IT organizations to participate in the

research study. An e-mail briefly outlining the five phases of the planned intervention design was

sent to each organization. Although the e-mail was meant to be a general overview of the

researcher’s planned activities and participant expectations, the e-mail generated a lot of concern

and hesitation among the participants, specifically with regard to the time commitment of the

training assessment. Each telephone interview was originally slated to gather information;

instead, the researcher answered a number of questions about the project in an effort to alleviate

concerns regarding the time factor, and assured each organization representative that the study

was not designed to interfere with their daily work schedules. In addition, the researcher

explained the training assessment should become an integral part of their work schedules over a

period of 10 working days.

During the telephone interview phase, the researcher was able to schedule onsite visits

with a mid- to upper-level manager from each organization. To save time, a manager from one

organization requested to have the survey (refer to Appendix C) and integrated training

assessment (refer to Appendix D) e-mailed in advance of the onsite visit. Although the


researcher complied, there was some concern about “group think” or over thinking the survey

and integrated training assessment, and thereby viewing it as a huge obligation.

Second phase – onsite visits and interviews

Note: three organizations agreed to participate in the research study. These

organizations will be identified henceforth as Company X, Company Y, and Company Z.

Company X. Headquartered in the northeastern United States (U.S.), Company X is a

Fortune 500 company that provides software and IT services to a client base of over 1,600

colleges and universities. The organization has approximately 2,500 employees located in the

United States and United Kingdom.

Due to a recent corporate reorganization, the researcher met with a principle writer,

formerly the technical documentation manager. In addition to an interview, a tour of the facility

allowed the researcher to get a sense of the corporate culture, as well as observe the physical

location and proximity of the documentation writers.

The interview (refer to Appendix B) took place in the principle writer’s neatly decorated

and well-organized office, where the researcher reiterated the purpose of the research project,

and expectations from the participants. The onsite visit was also an opportunity to obtain a

signed consent from the principle writer, as well as determine if there would be others

participating in the survey and training assessment study.

At the request of the principle writer, the survey and training assessment was e-mailed

three business days in advance of the onsite visit. However, the principle writer had not

distributed the surveys, nor completed the survey. In fact, additional questions regarding the

survey and training assessment were further discussed and clarified during the onsite interview.


There are approximately 500 employees on the development team; 17 of which are

technical writers. The researcher also learned that the organization functions in a collaborative

work team environment, where technical writers are typically co-located with the product team

they are assigned to, but report to a technical documentation manager who is located elsewhere

in the building or offsite. Although there are 17 technical writers, not all are physically located in

the corporate office building visited by the researcher. In fact, the former technical

documentation manager, still considered part of the development team, is now a principal writer

reporting to a technical documentation manager in another state.

According to the principle writer, the technical writers employ the typical industry

standard software tools, such as Adobe FrameMaker desktop publishing, TechSmith SnagIt

screen capture, Microsoft Visio graphics, and Adobe Acrobat tools to accomplish their writing

and publishing tasks. The company does provide training on new tools, but for the most part

there is a team member whose primary role is to stay abreast of new tools, learn new tools, and

train the rest of the documentation team if a new tool is approved for use within the team. This

particular team member is not a technical writer, but someone who is considered a technical

expert, and who manages all of the software installs, updates, troubleshooting, and network

management for the documentation team. The interview concluded with the principle writer

stating that realistically it was not feasible to have on-going training integrated into the daily

work schedules of technical writers.

The last part of the visit included a guided tour of one of the three buildings. The

atmosphere was unusually quiet considering the vast number of employees occupying the

building. Offices located along the perimeter of the facility housed mid- to upper-level


management personnel, while cubicles clustered within the interior of the facility housed various

employee work teams.

One week after the initial onsite visit, the researcher e-mailed the principle writer to learn

how the integrated training assessment was progressing, and if there were other technical writers

interested in participating in the survey and training assessment study. The principle writer

reported the training log was being updated daily; however, none of the other technical writers

were allowed to participate in the study at this time due to major restructuring and project

deadlines. The principle writer had mentioned earlier that the company had gone through many

changes over the past several years, including a recent reorganization.

Company Y. Company Y is a supplier and manufacturer of exclusive automotive

replacement parts, which are sold primarily in the U.S. through automotive aftermarket retailers.

The company is headquartered in the northeastern U.S. with fewer than 1,000 employees.

The researcher met with the business systems manager for an interview and onsite tour of

the facility. The company was housed in a brick warehouse with about one quarter of it

converted into office space for the employees. Although the facility had a warehouse look and

feel, the atmosphere was casual and the employees were hospitable and friendly. It was evident

that the products took precedence over the office space, as the warehouse was packed with a vast

number of shelves holding a variety of parts manufactured by the company. The business

systems manager carefully described the processes and the product lines, and often referred to

employees and partners as contributors. The facility had several single offices located in one

section of the building and a few along the perimeter; however, small cubicles and tight

walkways were centrally located.


The interview took place in the business systems manager’s paper-cluttered office. The

business systems manager is responsible for three different work teams, including project

managers, quality assurance, and business analysts. In this organization, part of the job

requirements of a business analyst is to write user manuals for the internal audience. According

to the manager, business analysts have a background in programming and business; thus, the

documentation is inconsistent and at times, incomplete. However, the user manuals are written

for internal use, and therefore, consistency is not a high priority.

In this organization, each product line has a dedicated, collaborative, co-located work

team. While work teams are collaborative and co-located, business analysts are not integrated

into this work structure. It was also interesting to learn that since software development is not a

core product of the organization, there are only nine development engineers.

According to the manager, his team of business analysts has a working knowledge of

Microsoft Office tools, including Word, Visio, and Excel. The team also uses TechSmith’s

SnagIt software to capture screens. While the company does allow some time for training, the

difficulty is finding the time to incorporate training in light of other more important work

challenges. For example, to help business analysts expedite the documentation requirements of

their job; the business systems manager identified a couple of tracking software tools that would

be a great time saver in accomplishing procedural documentation tasks. However, other work

priorities have prevented the manager from further looking into these potential new software

tools for the team.

Company Z. This Fortune 500 Company provides automotive, travel and financial

services. It has 2,700 employees in more than 80 locations; 100 of which are located in a newly

built technical operations facility. Hardware and software engineers occupy two thirds of the


spacious new bi-level facility; the remainder of the employees is comprised of business analysts,

and support personnel. Instead of cubicles, pods with shear moveable walls allow for individual

privacy. The brief tour revealed a vast number of empty pods on the first floor. The researcher

learned the company anticipated major growth in its IT division this year, so the second floor of

the large office space was vacant.

The researcher met with the director of strategic planning & business in a small

conference room where an in depth discussion ensued. Since the team consisted of several

business analysts who wrote requirements documentation for an internal audience, the researcher

determined that the strategic planning & business relations’ team met the criteria to participate in

the study. The researcher also learned of another team in the organization that wrote and updated

training manuals for both internal and external audiences, called the client group. Since this team

was located at corporate headquarters in Delaware, the researcher decided to conduct a telephone

interview with the director of the client group to obtain information about the team, and

disseminate the survey and training assessment to that team, as well.

Third phase – three-part survey

The three-part survey (refer to Appendix C) was e-mailed to the principle writer

(Company X), and the business systems manager (Company Y), with the understanding that the

surveys would be completed and retrieved during the researcher’s onsite visits. However, the

surveys were not completed at the time of the onsite visits, so the principle writer (Company X)

and business systems manager (Company Y), agreed to complete and return the surveys via U.S.

mail to the researcher’s home address. Both organizations returned the surveys on the date

stipulated by the researcher.


During the onsite visit with Company Z, the researcher distributed and explained the

three-part survey to the director of strategic planning & business relations, who volunteered to

hand deliver the surveys to the client group director at the headquarter location the next day.

After several unsuccessful attempts to contact the strategic planning & business relations’

director and client group director at Company Z, the researcher decided to proceed with the

study, minus further input from Company Z. However, information obtained from the onsite visit

and interviews with company directors will be incorporated in the study to assist with developing

themes.

The researcher was able to secure the cooperation and signed consent from another

organization willing to participate in the study. This organization, designated as Company W, is

a major manufacturer of commercial grade kitchen and catering equipment. It is headquartered in

the United Kingdom (U.K.) with locations throughout Europe, the United States, and Canada.

Company W has 6,000 employees.

The product support specialist is a member of the IT team, and writes end user manuals

for the food service division of the organization located in the northeastern U.S. In addition to

technical writing responsibilities, the product support specialist also writes marketing bulletins

and product brochures, and assists sales with onsite customer training. In an effort to bring

Company W up to speed with the other organizations, so that all of the subjects would be

prepared to participate in the focus group discussion at the same time, the researcher decided to

forego the onsite tour of the local facility, but did manage to conduct a one-on-one interview

with the product support specialist at a mutual location. The product support specialist was given

the three-part survey to complete, and encouraged to participate in the 10-day integrated training

assessment. The researcher also explained the focus group discussion format and established a


time and date for the teleconference based around the product support specialist’s extensive

travel schedule. After the personal interview, the product support specialist took 30 minutes to

complete and return the three-part survey.

Fourth phase – integrated training assessment study

A description and sample of a generic training assessment with log (refer to Appendix D)

was e-mailed to the principle writer (Company X) and the business systems manager (Company

Y) prior to the onsite visits. During the onsite visits with Company X and Company Y, the

researcher explained the training assessment study in greater detail. Each day, for 10 days, the

subjects were required to record the type of training they did, as well as the length of time spent

in training. The subjects were not limited to the type and length of training. The researcher

checked in with each organization after one week of the site visit to verify the progress of the

integrated training and answer any additional questions.

Fifth phase – focus group discussion via teleconference

The researcher hosted a one-hour focus group discussion via teleconference with all of

the participating subjects in the study. After reiterating the purpose of the research project, the

researcher thanked each subject and organization for its participation. The researcher also sought

permission from each of the subjects to record the conversation, so that answers could be

accurately documented.

The researcher chose not to introduce members from each organization in an effort to

protect the privacy of the individual and their respective organizations. However, subjects were

encouraged to respond to and disagree with one another as long as they identified themselves

first by their designated organization name (i.e., Company W, Company X, and Company Y).


The researcher posed four questions (refer to Appendix E) to the group and reminded

them that they would have limited time to respond to each question. The researcher asked

subjects about the lack of participation with the integrated training assessment; what they

thought about emerging themes, such as job postings for business analyst/technical writers, and

cross-functional/co-located work teams; what they thought about industry trends with the newer

web development tools, and the future direction of technical communicators. The discussion

started out slow and polite, but the topic of the changing role of the technical writer to include

business analysis responsibilities, and vice versa, quickly sparked a heated debate between those

with technical writing backgrounds and those with business analysis experience. Similar to a

technical writer, the business analyst is required to have excellent communication skills;

however, it is essential that the business analyst have a thorough knowledge of business and

information technology processes. Where as the technical writer transforms technical

information and translates it into a comprehensible, readable format for the end user, the business

analyst solicits the information directly from the client, and translates it to the technical

development team in the form of product specifications and customer requirements.

At times it was difficult to get a general consensus from the group on various issues, but

all of the subjects agreed that organizations speak rhetoric when it comes to supporting the

software training needs of employees. A detailed summary of the focus group discussion is

provided in Chapter 5.


CHAPTER FIVE: PRESENTATION OF FINDINGS AND RESULTS

This chapter presents the findings and results from the interviews, surveys, 10-day

integrated training assessment study, and focus group discussion. The results and findings are

important for various IT audiences for the following reasons:

IT organizations with documentation teams can use the data to better understand the

need and value of on-going training

Documentation managers and technical writers can use the data to justify on-going

training needs of the team

Documentation managers can use the data to evaluate the feasibility of integrating on-

going training into work schedules

Documentation managers and technical writers can use the data to better understand

which new or existing software tool is more appropriate for use by the team

Documentation managers can use the data to justify the purchase of new software

tools

Documentation managers can use the data to improve their documentation process

Technical communicators can use the data to better understand advances and

technological changes in the market, and determine which tools are pertinent for their

career goals

Technical communicators can use the data to become more aware of emerging roles

in their field, and take initiatives to educate and prepare themselves for those changes

Subject Background Evaluation

To participate in the study, subjects were required to meet the following criteria:

Employed as a member of an information technology work team


Employed as a documentation manager, technical writer or someone who is

responsible for documenting or writing procedural, instructional or informational

content for internal or external audiences

As indicated in the research literature, documentation teams typically consist of one to

three members. There were a total of nine subjects who participated in this study. Job titles and

responsibilities varied among the subjects. One subject was a principle technical writer, one

subject was a product support specialist/technical writer, and seven subjects were business

analyst/technical writers. There was only one subject whose sole responsibility was writing end

user documentation; all other subjects held multiple roles, which also encompassed technical

writing responsibilities. Two subjects were part of a larger cross-functional work team at their

respective organization.

All subjects were required to complete a three-part survey and encouraged to follow a 10-

day training assessment. At the conclusion of the integrated training assessment, subjects

participated in a focus group discussion via teleconference.

The following text summarizes the methods, findings, and results of the study. Individual

responses and identifying information have been withheld to maintain confidentiality.

Methods, Results, and Discussion

A three-part survey was utilized to assess the state of each team (part one), assess

individual software skills (part two), and assess individual training needs (part three).

Survey – Part One

A modified survey adapted from G. M. Parker’s (1996) book, Team Players and

Teamwork, was utilized to evaluate the effectiveness of each team. In addition, the survey was

intended to get a general sense of how those individuals who write technical documentation for a


living, felt about his or her respective work team, even though much of the work is done in

solitude.

Subjects were asked to respond to twelve statements with regard to their respective work

team or organization, as well as provide detailed comments on each statement. Some comments

were further clarified during the focus group discussion. Each statement was rated on a scale

from 1 to 2 (seldom); 3 to 4 (sometimes); 5 to 6 (often); and 7 to 8 (very frequently). Refer to

Appendix C for a full description of the statements. Eight out of nine subjects responded to the

survey, as shown in Table 1.

Table 1

Clear Purpose. This category addressed the team’s vision, mission, and goals. The

average score was 4.4. More than half of the subjects believed that their team had a clear

purpose, as well as clear goals. One subject stated that she ranked her work team on the lower

end of the scale because the organization was in a state of transition, and therefore the work


team’s vision was in a state of fluctuation. Another subject that also gave his work team a lower

score in this category stated that because the organization is driven by sales and marketing,

documentation tasks were not given much consideration or priority within his cross-functional

team.

Informality. This category dealt specifically with the team’s culture, not that of the

organization. The average score was 6.8. All of the subjects felt their team exhibited a relaxed,

informal culture.

Participation. This category looked at how well the team dialogued and encouraged

participation in discussions. The average score was 5.6. More than half of the subjects believed

that their team fostered an open forum for discussion. One subject stated that he did not like

participating in team discussions because it led to conflict. Two subjects stated that they did not

participate in team discussions for fear of job loss or being perceived as non team players.

Listening. This category addressed the team’s ability to effectively listen to one another,

using various listening techniques. The average score was 5.0. Half of the subjects scored their

work team on the higher side of the scale, and half on the lower side. One subject who gave her

team a low score in this category believed documentation writers practice listening techniques

more so than their non-writer counterparts on cross-functional project teams.

Civilized Disagreement. This category dealt with the team’s ability to handle conflict.

The average score was 5.9. While the majority of the subjects believed their work team was

comfortable with disagreements, one subject commented this was a problem for his team.

Consensus Decisions. This category looked at how the team reached important decisions.

The average score was 4.9. Half of the subjects believed decisions were made at the top level of


management and trickled down to them as directives, while the other half believed they had a say

in the decision making process of the team.

Open Communication. This category looked at team members’ freedom of expression.

The average score was 6.8. All of the subjects believed they were frequently given the

opportunity to provide feedback on tasks and the team’s operation.

Clear Roles & Work Assignments. This category addressed individual expectations, roles,

and work assignments within the team. The average score was 5.9. The majority of the subjects

gave their team high marks in this category, especially those with dedicated writing

responsibilities. One subject, however, believed that roles and work assignments were not always

clear, and therefore scored his team at the lower end of the scale.

Shared Leadership. This category looked at leadership functions within teams. The

average score was 4.9. Half of the subjects believed their team shared leadership responsibilities

in some capacity via sub teams. Other subjects believed leadership responsibilities needed to be

better distributed and delegated within their respective team.

External Relations. This category looked at the team’s ability to cultivate relationships

with other work teams in the organization, as well as develop key outside relationships. The

average score was 4.9. Subjects who scored their teams at the lower end believed they could and

should do a better job. Subjects who gave their team high marks in this category believed their

work team depended upon good relations with others, both inside and outside of the

organization.

Style Diversity. This category dealt with the different work/relational styles of team

members. The average score was 5.4. Six out of eight subjects believed their work team

members possessed a diverse style. One subject, who scored his team at the lower end of the


scale, attributed a lack of available resources in the area as the reason for a deficiency in style

diversity among work team members.

Self-Assessment. This category examined how often the team did a self-inventory to

evaluate its effectiveness. The average score was 5.4. More than half of the subjects stated their

work team practiced some form of self-evaluation, but scored their team low if they believed the

team did not evaluate itself on a consistent basis. One subject commented that this was a new

process for the team and gave the team high marks in this area. One subject commented that

team assessments were done on a weekly basis, and even though he gave the team a high score in

this category, felt that the weekly assessments were excessive.

Survey – Part Two

Part two of the survey was used to ascertain individual strengths and weaknesses with a

variety of standard and newer technology software tools that technical communicators use to

perform various tasks to complete work assignments. Subjects were asked to rate themselves

based on their level of mastery against a selection of industry standard software tools on a scale

of expert (3), intermediate (2), novice (1), and none (0). Subjects were given a key describing

each level of mastery (refer to key in Appendix C), but were not told the numeric weight of each

level. They were instructed to simply place a check mark next to their current skill level with

each software tool (refer to the legend in Table 2).


Table 2

As shown in Table 2, all nine subjects responded to the individual skills assessment with

software tools survey. The results of the survey are in accordance with the research literature

discussion from Chapter 2. Subjects displayed a wide range of experience with a variety of

software tools, but have not shown a significant mastery level of any one tool. The line chart in

Figure 1 is a crude illustration of just how technical communicators are scattered in their skill

levels with industry standard software tools. In fact, the latest industry trends for technical

communicators is to have some degree of competency with tools for desktop publishing (Adobe

FrameMaker), content editing (Abortext Epic Editor), website creation and management

(Microsoft Frontpage), and web development (Macromedia DreamWeaver; HTML, XML,

SGML), but as shown in Table 2, subjects had the least amount of experience with these tools.


Figure 1

Survey – Part Three

Subjects were asked to respond to three questions with regard to their specific training

needs and desires. All nine subjects completed this part of survey.

The first question, ‘which software tools do you find are the most and least useful in

meeting the needs and requirements of your current job’, was intended to determine the

significance and appropriateness of tools required by the documentation team or organization.

Again, subjects were scattered in their answers, but the most common tools utilized by these

technical communicators were Microsoft’s Word and Excel programs. Although subjects noted

Word and Excel as the most useful tools for their work assignments, Table 2 showed on average,

the subjects’ level of expertise with each program at 2.3 and 1.9 respectively. In other words,

based on the legend at the bottom of Table 2, subjects were comfortable with Microsoft’s Word

program, but were not comfortable with Microsoft’s Excel program. The tool subjects felt was

least useful in completing their work tasks was Microsoft’s PowerPoint program. Ironically,

subjects felt comfortable with this tool, but had little use for it in their jobs.


The second question, ‘do you feel you could use additional training on one or more of the

software programs to enhance your current skills’, was intended to gain insight about the

subjects’ awareness of his or her strengths and weaknesses with certain tools, and determine if

subjects believed they required additional training on the tools listed in Tables 2. Interestingly,

answers to this question ranged from no additional training is required to more training is

required on all of the tools to improve skills and enhance job marketability. One subject was

currently going through training on FrameMaker and Adobe Acrobat to enhance skills. One

subject desired more training on all Microsoft tools to enhance job performance and improve

user documentation. One subject desired more training on formatting and templates, while two

other subjects preferred more training with web development tools and SQL, a structured query

language for obtaining information from and updating a database.

The last question of the survey sought out information about the subjects’ membership

and participation in a professional organization for technical communicators. This question was

intended to learn information about the subjects’ long-term commitment to the profession, as

well as desire to keep up with industry trends and new software tools. Two of the nine subjects

were active members of professional organizations, namely the Society for Technical

Communicators (STC) and the Project Management Institute (PMI). One subject has on occasion

attended meetings for professional communicators, but has not made a commitment to join

because of the expense. During the focus group discussion, the two subjects that are members of

professional organizations clarified that they pay annual fees of over $150 out of pocket. Two

other subjects stated they did not have any interest in joining a professional organization for

communicators because documentation was only a small part of their job. One subject remarked

that professional organizations have no value, and is therefore not interested in them.


Integrated Training Assessment Study

All nine subjects were asked to incorporate training into their daily work schedule for ten

days. Since subjects were at different software skill levels (refer to Table 3), and had diverse

needs and requirements for their jobs, they were given the liberty to select a software tool or

subject area to learn more about over a ten-day period. Subjects were also encouraged to spend a

minimum of 30 minutes per day on their individual training assessment. Results of the integrated

training assessment study are shown in Table 3, and also depicted in Figure 2.

Table 3

Figure 2


Figure 2 displays a bar chart to show that only three out of nine subjects participated in

the integrated training assessment. During the focus group discussion, subjects voiced their

frustration with the integrated training assessment, citing a lack of support from management.

Initially, all nine subjects expressed concern with the integrated training assessment because of

the time commitment, but agreed to participate as long as their managers were supportive of this

effort. Although managers from each organization gave their approval and consent to the short-

term integrated training assessment, subjects conveyed their inability to start or continue with the

integrated training assessment was due to interruptions, work priorities, and imminent deadlines.

One subject stated that she was only able to complete the integrated training assessment because

it happened to coincide with previously scheduled software training at work. All subjects agreed

that on-going integrated training is nice in theory, but does not work in practice.

Focus Group Discussion

Subjects participated in a one-hour focus group discussion via telephone conference. The

researcher presented various topics for clarification and general discussion (refer to Appendix E

for a complete outline of the questions presented to the focus group). These topics included some

of the issues from the three-part survey, problems encountered with implementing the integrated

training assessment, and emerging themes such as, the changing role and responsibilities of

technical communicators, and technical communicators on cross-functional/co-located work

teams.

After a brief icebreaker, the researcher opened with the first theme that emerged from the

data. The two subjects who were active members of a professional organization (i.e., STC and

PMI) seemed to be more aware of industry trends with software tools and changing roles of

technical writers than those subjects who did not belong to a professional organization. One of


the subjects admitted that although she was aware of this trend, her organization (Company X)

continues to utilize its writing team to document end user manuals. The other subject stated that

his job at Company Y encompassed multiple roles and responsibilities, including technical

writing, business analysis and programming. The subject felt that his job is difficult enough

without the added responsibility of writing user manuals.

A few of the subjects from Company Y commented that their job titles were somewhat

misleading in that their background was in business analysis and programming, not technical

writing; therefore, they did not put much effort into the user documentation. The team manager

from Company Y stated that the documentation that comes out of the team is usually inconsistent

because most of the team members have a background in business analysis and programming,

not technical writing or publishing, and those that do are just out of college. A subject from

Company Y expressed concern about the qualifications of technical writers to gather client

information, write business requirements, test scripts, and use cases. Subjects from Company X

and W, both with strong technical writing backgrounds, fired back with what makes a business

analyst capable of technical writing, electronic publishing, and website design and development.

Although the discussion was heated, it was obvious that the business analysts and

technical writers believed their skill sets were clearly defined and completely different. The

researcher interrupted the discussion at this point to inform the focus group that numerous jobs

are posted for the combined skills and talents of business analyst/technical writers. Therefore,

what steps, if any, do they intend to take to improve their skills and enhance their marketability?

While all of the subjects acknowledged this trend, most of the subjects had no plans to seek

additional training at this time. One subject from Company W admitted to feeling overwhelmed

with multiple job responsibilities that included writing, website development, marketing, and


customer training, but would continue to learn and juggle those responsibilities as long as the

organization provided the training for those skills and good compensation. Six subjects

expressed no interest in joining a professional organization to help them keep abreast of industry

trends, while one was still unsure about making the commitment.

The next topic presented to the focus group was how they felt about being part of a cross-

functional/co-located work team. Subjects from Company Y were not part of a cross-functional

work team, but stated that their entire organization was set up with various project and cross-

functional work teams. The manager for this team explained that the business analyst/technical

writers were kept in tact for the time being because of the added technical writing

responsibilities. The manager further explained that the company had a difficult time attracting

technical writers, and therefore placed this task on its business analysts since they already knew

the product line and wrote business requirements and functional specifications for the

organization.

Subjects from Company X and W were each part of larger cross-functional work team,

consisting of 12 and 26 members, respectively. The subject from Company X explained that the

technical writing team consists of 17 members, but each writer is dispersed into other project

teams, consisting of employees with varied job functions and expertise. The subject from

Company W stated that his position on the 26-member cross-functional work team has enabled

him to learn the business more thoroughly, as well as understand it from the perspective of sales,

marketing, quality assurance, engineering, and customer service. The subject from Company X

prefers the camaraderie and cooperative learning experience of a single work team environment

instead of her organization’s recently imposed cross-functional/co-located work team

environment.


One topic the focus group did agree on without debate is the vast number of emerging

software tools and the disparity of skill levels among industry professionals. One subject from

Company Y stated that he was not interested in additional software training on the application

tools listed in part two of the survey because his job requires him to write test scripts, using

programming tools, not application tools. Although technical writing is a part of his job, the

subject reiterated several times that it was only a small part of the job. A number of other

subjects felt software training on specific tools was necessary in order to improve job

performance and work quality, but those skills would have to be picked up on the job or on their

own time.

When asked about the newer web development tools, three subjects from Company Y

remarked that although they have some experience with the newer web development tools, they

would only pursue additional training if their organization mandated it. One subject from

Company W commented that his organization spent thousands of dollars training him on

Microsoft’s FrontPage, a website creation and management tool, only to change their mind and

hire a website development team to oversee all company websites.

At the end of the discussion, the researcher recapped the topics and discussion to

establish overall group consensus on issues and clarify emerging themes, as follows:

The focus group agreed that there are defensive routines between business

analysts/technical writers and the upper management team at Company Y, which

needs to be acknowledged and addressed before the team can write and design more

effective user manuals

The focus group pointed out that the lack of software training can, and has, led to

frustration and poor quality documentation, and agreed that more thorough training


on software tools, up front, would better prepare documentation writers for electronic

writing and publishing tasks

The focus group acknowledged that emerging trends in the IT industry has placed

multiple responsibilities on technical communicators; therefore, to better understand

and prepare themselves for those changes in their profession requires additional

training and education, if they intend to stay competitive and marketable.

The focus group agreed that joining a professional organization is not altogether

necessary to keep up with industry trends, but that technical communicators must

make the effort to connect with others in the profession, especially as IT

organizations move towards cross-functional/co-located work teams

In summary, the combined results and findings of the interviews, surveys, integrated

training assessment study, and focus group discussion provided valuable information about the

training needs of documentation writers in an IT organization. Themes emerging from the data

further attest to the fact that as roles change, and responsibilities increase, professionals must

equip themselves for those added responsibilities via on-going training, if they are to stay

competitive.


CHAPTER SIX: REFLECTIONS, CONCLUSIONS, AND RECOMMENDATIONS

The purpose of this research study was to determine if the integration of on-going

training in the work schedules of documentation teams would enhance individual competency

and improve team performance. The researcher utilized various methods and techniques to

gather data in an effort to verify this hypothesis. While the research focused on the problems of

technical communicators keeping abreast of new software tools and insufficient training on

existing tools, the researcher discovered two emerging themes that impact those currently in the

technical communication field, as well as those embarking on a career in the field.

Reflections

During the process of soliciting organizations and subjects to participate in the study, the

researcher learned that technical communicators in IT organizations who only write end user

manuals are becoming a rarity. The data revealed a marked trend towards technical writers with

multiple roles and varied responsibilities that include web design and development, and business

systems analysis functions. Although these added roles and responsibilities require training on

some of the newer software tools and more complex programming tools, technical

communicators are experiencing difficulty keeping pace with these tools.

A quick look at several college curriculums showed colleges and universities in the U.S.

and Canada offer undergraduate degree programs in technical communication. The curriculums

varied in their offering, but for the most part each institution offered courses that prepared

students to write, edit, and design pages for user manuals, training materials, press releases, and

marketing brochures. In addition, some institutions offered courses that would equip students

with the ability to prepare video scripts, online help files, computer-based training modules, and

design web pages. Future research in this area should take into account what colleges and


universities are doing to prepare students to incorporate this new trend towards adding business

systems analysis and programming responsibilities with the technical communication discipline.

The pace of technical communication is changing so rapidly that many technical

communicators are only beginning to get up to speed with some of the complex web

development and design tools (refer to Table 2 in Chapter 5). The added responsibility of

business systems analysis, which requires the use of even more complex programming tools,

only exacerbates the problem of insufficient training for technical communicators.

Another theme that emerged from the data was that of cross-functional/co-located work

teams. The focus group agreed that these teams are viable and do work. On the upside, as noted

by one subject in the focus group, these teams allow members to learn the organization’s

business from a variety of business perspectives. On the downside, technical communicators can

easily isolate themselves and get so caught up in work that they fail to notice changes in their

field, especially if they are not connected with another writer or a professional organization.

Conclusions

The purpose of technical documentation is to impart instructional information or

knowledge to different audiences. The information in its original form must be translated, so that

different audiences can understand and make use of its intrinsic value. As stated earlier, the

technical communication profession is driven by technological advancements in software,

presenting technical communicators with new tools to create and design user manuals. However,

like anything else, experiencing something for the first time is a learning process. Thus, decision

makers must be cognizant of their responsibility to those they lead, and provide them with the

necessary time and training to enhance their skills with new and existing software tools. Leaders

must also be mindful that new software tools may be designed to make the work process more


efficient, but if those using the tools have insufficient training, then the tool’s effectiveness is

diminished.

In conclusion, the intent of this research study was to determine if the integration of on-

going training in the work schedules of documentation teams enhance individual competency

and improve team performance. Although the research literature indicated that training and

development could lead to an increase in work productivity, the results of this study were

inconclusive. It is the opinion of this researcher that the design and development of the integrated

training assessment should be a collaborative effort with IT organization leaders in order to

solicit buy-in, better cooperation, and stronger participation. The results from the integrated

training assessment were a key component to the overall study; without it, it is difficult to prove

one way or the other if integrated on-going training could enhance individual competency and

thereby improve the overall performance of a documentation team.

Recommendations

The researcher recommends the design and development of an in depth pedagogical

training assessment that would accurately test and measure the software skill level of technical

communicators. In addition, a research team should solicit a larger sample size of technical

communicators (i.e., 30 - 40) to participate in a pre-test study that would measure initial software

skill levels. After a carefully monitored 30-day integrated training assessment of one-hour per

day in a lab environment, researchers should do a post-test study to compare and contrast

software skill levels. This type of study would bore out significant data and more conclusive

results.

To solicit participation in the study, the researcher would recommend teaming up with a

professional organization for technical communicators, such as STC, to accomplish this type of


undertaking in the future. A comprehensive study of this magnitude would be beneficial for all

IT managers, as well as technical communicators seeking support from their organizations for

on-going training and development with new and existing software tools.


BIBLIOGRAPHY

Ament, K. (2003). Single sourcing: Building modular documentation. Norwich: William

Andrew Publishing.

Bennis, W. (1999). The leadership advantage. Leader to Leader, Vol. 12:18-23.

Coghlan, D. (1998). The interlevel dynamics of information technology. Journal of Information

Technology. Vol. 13:139-149.

Deci, E. L., and Ryan, R. M. (2000). The "what" and "why" of goal pursuits: Human needs and

the self-determination of behavior. Psychological Inquiry, Vol. 11, No. 4:227-268.

Eble, M. F. (2003). The effects of single sourcing on the teaching of technical communication.

Technical Communication. Vol. 50, No. 3:344-349.

Gould, J. R. (1968). Barriers to effective communication. Paper, P. 53-58. Rensselaer

Polytechnic Institute, Troy, NY.

Grice, R. A. (2002). Some reflections on the emergence of a profession. ACM Journal of

Computer Documentation. Vol. 26, No. 3:126-129.

Grice, R. and Krull, R. (2001). 2001, a professional odyssey: An introduction to this special

issue. Technical Communication. Vol. 48, No. 2:135-138.

Hansen, M.T, Nohria, N., & Tierney, T. (2001). Harvard business review on organizational

learning. Boston: HBS Publishing Corp.

Holy Bible: New American Standard Bible (1999). Grand Rapids: The Zondervan Corporation.

Johnson, T. (2006). Average Ratio of Writers to Developers. Retrieved March 25, 2007, from

http://stc-suncoast.org/2006/03/21/avg-ratio-of-writers-to-developers-is-142

Longo, B. (1998). Philosophy meets politics in the debate over technical writing’s role. Journal

of Computer Documentation. Vol. 22, No. 4:45-53.

http://stc-suncoast.org/2006/03/21/avg-ratio-of-writers-to-developers-is-142


Marsh, C. H. (1999). The engineer as technical writer and document designer: The new

paradigm. Journal of Computer Documentation. Vol. 23, No. 2:57-61.

O’Hara, F. M. (2001) A brief history of technical communication. Paper, P. 500-504. STC 48th

Annual Conference Proceedings, Arlington, VA.

http://www.stc.org/confproceed/2001/pdf/stc48-000052

Parker, G. M. (1996). Team players and teamwork. San Francisco: Jossey-Bass.

Rockley, A. (2001). The impact of single sourcing and technology. Technical Communication.

Vol. 48, No 2:189-193.

Senge, P. (1990). The leaders’ new work: Building learning organizations. Sloan Management

Review. Fall, Vol. 32:7-23.

Staples, K. (1999). Technical communication from 1950-1998: Where are we now? Technical

Communication Quarterly. Spring, Vol. 8, No. 2:153-164.

Sundstrom, E. (1999). Supporting work team effectiveness. San Francisco: Jossey-Bass.

Wilson, G. and Ford, J. D. (2003). The Big Chill: Seven technical communicators talk ten years

after their master’s program. Technical Communication. Vol. 50, No. 2:145-159.

http://www.stc.org/confproceed/2001/pdf/stc48-000052


APPENDIX A: Phase 1 - Telephone Interviews

1. Initial introduction of researcher

2. Briefly explain the research project and what it entails

The purpose of this research project is to determine if the integration of on-going

training in the work schedules of documentation teams would enhance individual

competencies and improve team performance. Utilizing various mechanisms of

team dynamics, the researcher proposes to implement an intervention in four

phases, as follows …

3. Give a general overview of each phase

Phase 2 – an onsite visit to interview the documentation team manager, meet

team members, tour work place, and obtain signed consent forms

Phase 3 – explain and distribute a 20-minute survey during the onsite visit, which

are to be collected at the conclusion of the onsite visit

Phase 4 – explain the 10-day integrated training assessment and distribute logs,

which are to be returned via postal service

Phase 5 – host a one-hour focus group discussion at the conclusion of phase 4.

4. Schedule onsite visit

Organization: _______________________________________________

Location: _______________________________________________

Participant: _______________________________________________

Date of visit: _______________________________________________

Meeting time: _______________________________________________


APPENDIX B: Phase 2 - Onsite Visits and Interview Questions

Name of organization

City, State

Name of participant & title

Telephone/E-mail

Scheduled date of visit

Scheduled time of visit

Interview Questions:

1. What is the total number of employees in the organization?

2. What is the total number of hardware and software engineers in the organization?

3. What is the total number of technical writers?

4. What are the specific roles of the technical writers on the documentation team?

5. What software tools does the documentation team use to accomplish writing, design and

publishing tasks?

6. Did the company provide training for each of the software tools you mentioned in the

previous question?

7. What is the average amount of time for training on new software tools?

8. If you had your choice, what software tools would you prefer to use in an effort to

accomplish writing, design and publishing tasks?

9. What trade publications do you read to keep abreast of what’s going on in the technical

communication profession?

10. How would schedules be impacted if training were integrated?


APPENDIX C: Phase 3 – Surveys

Part 1. Documentation Team Assessment Survey*

The following survey assesses the current state of the team. Please rate the statements on a scale

of 1 to 8, and provide a brief comment in the space provided.

How Often Is This Statement True?

(Circle one number)

Statements Seldom

Sometimes

Often

Very Frequently

Clear Purpose: The vision, mission, goal, or task of the documentation team has been defined and is accepted by everyone.

1 2 3 4 5 6 7 8

Comments:

Informality: The climate tends to be informal, comfortable, and relaxed.

1 2 3 4 5 6 7 8

Comments:

Participation: There is a lot of discussion, and everyone is encouraged to participate.

1 2 3 4 5 6 7 8

Comments:

Listening: The members use effective listening techniques such as questioning, paraphrasing, and summarizing to get across ideas.

1 2 3 4 5 6 7 8

Comments:

Civilized Disagreements: There is disagreement, but the team is comfortable with this and shows no signs of avoiding, smoothing over, and suppressing conflict.

1 2 3 4 5 6 7 8

Comments:

Consensus Decisions: Important decisions are reached via unanimous agreement through open discussion of everyone’s ideas, formal voting or compromise.

1 2 3 4 5 6 7 8

Comments:


Documentation team assessment (cont.) Open Communication: Team members feel free to express their feelings on the task as well as on the group’s operation.

1 2 3 4 5 6 7 8

Comments:

Clear Roles and Work Assignments: There are clear expectations about team roles and work assignments.

1 2 3 4 5 6 7 8

Comments:

Shared Leadership: While the team has a formal leader, leadership functions shift from time to time depending upon the circumstances, the needs of the group, and the skills of the members.

1 2 3 4 5 6 7 8

Comments:

External Relations: The team spends time developing key outside relationships, mobilizing resources, and building credibility with other work teams in the organization.

1 2 3 4 5 6 7 8

Comments:

Style Diversity: The team has a broad spectrum of team-player types, including members who emphasize attention to tasks, goal setting, a focus on process, and regularly questions how the team is functioning.

1 2 3 4 5 6 7 8

Comments:

Self-Assessment: Periodically, the team stops to examine how well it is functioning, what may be interfering with its effectiveness, and then implements the necessary changes.

1 2 3 4 5 6 7 8

Comments:

*This survey is adapted from G. M. Parker (1996), Team Players and Teamwork.


Part 2. Individual Skills-related Software Tools Assessment

This part of the survey assesses the software skill levels of each individual if tested on the

program tomorrow. Please place a check next to your current level of expertise on each software

tool (all versions) listed below.

Software Mastery level (Check one)

Software Mastery level (Check one)

Microsoft Word

A word processor

__ Expert __ Intermediate __ Novice __ None

Macromedia DreamWeaver

A web development tool


Microsoft Outlook

Electronic mail and scheduler


Adobe FrameMaker

A desktop publishing program


Microsoft FrontPage

Website creation and management


Adobe Acrobat

Creates PDF files


Microsoft Excel

A spreadsheet program


HTML/XML/SGML

Web development tools


Microsoft PowerPoint

Presentation software


Abortext Epic Editor

XML, SGML content editor


Key: Expert = experienced, extremely comfortable; Intermediate = experienced, comfortable; Novice = little experience, not comfortable; None = no experience.


Part 3. Individual Task-Related Training Needs Assessment

The last part of the survey assesses the task-related training needs of each individual. Please

answer each question, and use the back of this paper if necessary.

1. Which software tools do you find are the most and least useful in meeting the needs and

requirements of your current job? Please explain.

2. Based on your personal level of expertise with the software tools listed in part two of this

survey, do you feel you could use additional training on one or more of the programs to

enhance your current skills? Please explain.

3. Are you an active member of a professional organization for technical communicators? If

not, why? If so, please list organization, length of membership, and level of participation.


APPENDIX D: Phase 4 - Training Assessment Study

Please adhere to the following guidelines over the next ten working days. Remember, up

to one hour per day is all the time that is required for the integrated training assessment. It is

important to keep a daily log of your progress, even when a day of training activity is missed.

Please record your time on the log that has been provided.

Training Activity 1

Read a current issue of a technical writing trade publication (e.g., Technical

Communication, a periodical published by the Society for Technical Communications) to

learn what’s going on in the technical writing field with software publishing and design

tools. Try to identify any new tools that could enhance your work performance.

Training Activity 2

Select a software program or design tool, either new or one that you are currently using,

and incorporate up to one hour of training per day using that tool or learning about an

industry concept (e.g. conducting a webinar). You can use any training method, including

a tutorial, peer coaching from an advanced user, or a combination of training methods.

Sample Log Day Date Training Activity Training Method Length of time

1 01/22/2007 Intercom Magazine – Writing and Web 2.0

Read 1 article 20 minutes

2 01/23/2007 Epic Editor text editor tool

Online tutorial 45 minutes


Individual Training Log

Day Date Training Activity Training Method Length of time

1

2

3

4

5

1

2

3

4

5


APPENDIX E: Phase 5 - Teleconference Group Discussion Questions

The researcher posed the following questions for discussion, and reminded the group that

they would have a limited amount of time to respond to each question.

Integrated training Assessment:

1. Although the training period was brief, did anyone feel that they actually benefited

from incorporating training into their daily work schedule? And if so, how?

2. If training is not incorporated into your daily work schedule, how will you keep up with

newer software tools?

Themes/trends

Multifunctional roles:

A review of scholarly literature revealed that technical communicators are moving into

multifunctional roles, including knowledge management specialists, content management

specialists, information architects, and information technologists. During this study, I noticed a

trend in the field towards business analysts/technical writers (i.e., business analysts with

technical writing responsibilities).

3. Do you think you, as business analysts, have been adequately trained or prepared to

function in the added role of technical writer? And for those of you who are currently

operating solely as technical writers, how do you intend to upgrade your skill set to

meet the job requirements of a business analyst?

Cross-functional/co-located work teams:

4. Have you benefited from being part of a cross-functional/co-located work team or do

you feel you are missing out on the camaraderie and mutual learning experience from

being part of a technical documentation team?


APPENDIX F

INFORMED CONSENT FOR PARTICIPATION IN RESEARCH PROJECT

Philadelphia Biblical University

The Graduate School of Business and Leadership

MOL 991 - Action Research Project

I agree to participate in a research study of organizational learning as described by the

researcher. I understand the purpose of this study and am participating voluntarily. I grant

permission for the data to be used in the process of completing an MS degree at Philadelphia

Biblical University, Langhorne, PA, including a dissertation and any other future publication. I

understand that my name, the name of the organization and other demographic information that

might identify me or the organization will not be used.

I agree to meet for a personal interview of approximately one hour and to participate in a

group interview. I also grant permission for the recording of the interviews, and understand that

these recordings will be accessible to and used only by the researcher for the purpose of

clarification, and recall of important information, and to document and illustrate pertinent points

in the writing about this research.

I understand that:

1. The time required for my participation in this study is approximately 2 to 3 hours.

2. The nature of my participation includes one personal interview and one group interview

that will be recorded, describing my experiences within my organization.

3. My participation is entirely voluntary. I may terminate my involvement at any time

without penalty.

4. I fully understand that if I decide not to participate in this study, neither my job nor

relationship with the university will be in jeopardy.

5. All information is confidential and anonymity is guaranteed.

6. If I have questions about the research or need to talk to the researcher, I can contact the

researcher by calling 609-234-7805 or e-mailing Teri Catanio, [email protected].

Research Participant: _________________________________ Date: _____________________

Researcher: _______________________________________ Date: _____________________

mailto:[email protected]

Documents

Teri Catanio_Action Research Project