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.
-The writer requires access throughout the project to a stable version of
the system that has been set up and configured to look and behave like the
system the typical primary end-user will have.
-The (name) team will provide the writer with documentation of any changes
to the project specification because they may affect the final
documentation.
-The writer requires a reasonable amount of access to SME's.
-For procedure validation, the writer will need access to an appropriate
individual to perform the procedures.
-For procedure validation, the writer and validator will need access to the
test system.
-The writer will be notified any changes that might impact the
documentation.
-The writer will be notified of any changes that might impact the project
schedule.
DEPENDENCIES
examples from more than one respondent:
-Development will work with documentation to integrate help system,
including the Search engine, with application.
1. Development will work with documentation to integrate the help system and
link the help topics with the appropriate screens in the user GUI.
2. Access to subject matter experts.
3. Timely access to interim releases of the product, preferably installed on
the writer?s PC.
RISKS:
examples from more than one respondent:
1. Availability of SME's
2. Availability of (Name) System
3. Timely communication of changes to the application.
4. Timely review and return of review copies.
1) Software (such as Frame, Photoshop..) to develop the documentation is not
available.
2) Writers do not have adequate training/knowledge of the software
3) Writers are not familiar with the product (engineering).
4) Schedules are not met
5) Reviewers lack sufficient knowledge to review the documentation
6) Scope of the doc requirements is not clear.
Risk Management plan should cover the solution for these risks. For example
(4) schedules are not met. The solution can be: Put in place adequate
project tracking mechanism, so that all team members are aware of the
schedule.
-Using new help system, XXX, in a YYY application. Not sure how this will be
integrated and if it will work without problems.
-XXX includes a search engine. If we can?t integrate XXX, we will need to
develop a search engine of our own or ship a help system that does not
includes a search engine as a standard help system entry point.
-We might be required to translate our documentation late in the project
cycle. If this happens, the translation service may require burdensome file
manipulation. We are mitigating this risk by choosing tools that are
industry standards and can create SGML, HTML, and XML files.
* Late input from Product Marketing could result in scope changes, given
that delivery mechanisms and channels and early release customers have not
been defined by this group.
* Product X 1.0 was localized, and we plan not to localize this release. A
late decision to localize the doc would affect schedules.
1. Changes to the GUI late in the development cycle.
2. The writer for X product works half time on this project and half time on
the Y product. Schedules for documentation milestones need to be offset. If
both products are released in close succession, this poses a risk to both
projects.
3. If the Usability group provides input late in the development cycle,
implementing changes could involve substantial reworking of the help topics
and their organization.
4. If the writer for X product is tasked with rebranding the documentation
for the third-party products, this could jeopardize the schedule for the
documentation deliverables planned for Product X.
5. Inclusion of additional requirements would pose a risk to the schedule.
6. The scope of effort for documenting Feature A is unknown.
7. The scope of accommodating XXX compliance is unknown.
8. The scope of documenting integrations is unknown.
9. If a requirement is added to translate the 1.0 release simultaneously
with the English version, translation coordination and iterative drops of
source files could pose a risk to the schedule.
area 1 - lack of any critical resource:
* hardware failure impacting deliveries (To mitigate, have good service
contracts on all mission critical hardware.)
* timely reviews and access to SMEs. (To mitigate, have someone with serious
steel clad boots of authority be the champion for missing or incomplete
reviews.)
* staffing, paper supplies or even local printer availability (If you only
have one writer or one graphics designer or one specialist of any sort who
is mission critical, then staffing is a risk issue. Mitigate through
cross-training and skills set duplication)
* if document is printed and bound exhouse then a risk is delays in
availability. (stay in touch with your printer when publishing time
approaches and book a few tentative dates and runs well ahead of time so
they can plan for it as well.)
area 2 - identifying any possible problem that can impact the successful
delivery of requirements to specification:
* document corruption at the 12th hour (Mitigate through good writing
practices, thorough Word knowledge (or access to any relevant list) and
Version Control (regular backups, many regressions available)).
* accidental deletion, misplaced files. (Expedite by storing all materials
on the server and ensure it has a rigorous backup schedule. Perform regular
system scans for controlled doc types on all writing staff workstations
until you have the confidence in your team to store their materials
correctly.)
* Note: exclude all disaster-type risks, they tend to affect multiple
departments and are covered under a different set of documents with the
loose heading of Contingency Planning.
---- end part 2 of summary posting-------
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Free copy of ARTS PDF Tools when you register for the PDF
Conference by April 30. Leading-Edge Practices for Enterprise
& Government, June 3-5, Bethesda,MD. www.PDFConference.com
Are you using Doc-to-Help or ForeHelp? Switch to RoboHelp for Word for $249
or to RoboHelp Office for only $499. Get the PC Magazine five-star rated
Help authoring tool for less! Go to http://www.ehelp.com/techwr
---
You are currently subscribed to techwr-l as: archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
