TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> This is why a standard interview approach is to ask
> the applicant to explain in detail what exactly they
> did to produce the sample they are showing: was it all
> their work? a team effort? what challenges did they
> overcome? how did they get their information? what was
> different in this project from other projects listed
> on their resume? and so on.
That is the type of interview approach that has apparently failed the State
of California and other large employers. So the current trend, at least for
the State, is to have applicants provide a detailed skill summary based on
requirements that the state agency defines. The panel interview process
does not consider the resume very much and focuses on the statement of work
and the skill summary. The skill summary that I completed and that got me
the interview contained the six requirements that follow.
1. At least three (3) years experience in developing requirements
2. Knowledge of methodology used for business process design and
re-design
3. Experience in or knowledge of developing, documenting and leading
testing
4. Experience in or knowledge of researching and documenting best
practices
5. Experience in or knowledge of the System Development Lifecycle
(SDLC)
6. Experience in or knowledge of Rational Unified Process (RUP)
The statement of work included a number of other requirements such as
knowledge or use of JAD, requirements analysis, functional specifications
(or Use Cases), PMO and SDLC methodologies, and Change Management.
Typical interview questions would not get this kind of information. There
also appears to be a trend towards requiring that contractors perform both
the analysis and the writing tasks. One contract presented to me by a
recruiter already had a Business Analyst, but they needed a Technical Writer
to document the Business Analyst's work and I was approached as the
Technical Writer for the contract. That bid was not approved.
I think that the role of the Technical Writer has had a bit of growth and
has reached outside of the areas of software and process documentation and
into areas of business and systems analysis. There may now be a trend to
phase out analysts that cannot document their own work and, at the same
time, phase out writers that cannot analyze the environment that they
document.
What it looks like to me, is that employers are re-organization the market
and consolidating resources within the market. Of course, the client drives
the market, so this is a logical progression. I think that this is a growth
phase that will result in a better and stronger resource pool for technical
communication, although the role of technical writer seems to be getting
smaller.
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include support for Windows Vista & 2007
Microsoft Office, team authoring, plus more. http://www.DocToHelp.com/TechwrlList
True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
