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.
Subject:RE: writer needs a pep talk From:Rose -dot- Wilcox -at- pinnaclewest -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Fri, 6 Jun 2003 11:10:07 -0700
Kevin in Ottawa:
<<
I've been writing docs for 8 years, and I've never been in this situation
before!>>
That's the fun part about technical writing, eh? I thought at about 15 years in that I had seen everything, then new problems, ah, er, I mean challenges, popped up... keeps ya on yer toes, don't it? <grin>
<<
Basically,
- the project still has major feature changes/additions well after the
proposed UI freeze date
- there never was (n'or was there any hope of ever having) a plan for the
project.
- the deadline is in two weeks
- my SMEs are so busy making all these changes that I've been told there
really is no time for a review of my big User Guide>>
I've seen all those before and together too. One thing you could do is consider delivering the doc x amount of days after the code. If that is not acceptable, do an addendum or a readme or send updated pages (depending on the amount of change after the fact.) And since you care about quality, you might need to do some nice things for yourself... like talk nice to yourself... you know, don't take it personally. Realize you are doing your best in the situation, and it is much better for your reader that you are on the case than if someone who didn't give a hoot was there
<<
Management seem to know my situation, I've been quite vocal about the whole
thing. ie, you guys are gonna get a crappy user guide because you keep
changing everything and can't review my work to make sure I understand what
you're doing...
>>
Yes, the truth is, they have bigger fish to fry and are willing to accept lower quality doc as a price for whatever other problems they are trying to solve. So you need to continue to be solution-oriented. Think about your readers, but also think about the business. Management, whether out of incompetence or business pressures or both, rushed to production without a good process. What is the best you can deliver within the timeframe?
<<
I've always produced good stuff, well-written, well-indexed, completely
reviewed manuals. This time, however, it's gonna be a bit of a washout.
>>
Wow, that is a great track record and enjoy it. This will also be part of your track record, but it doesn't have to be a bad thing. Figure out the best solution and make the manual the best it can be within the limitations. It is still good stuff. You have to use a different yardstick for this one as far as *your job* goes. You and I know the quality is undoubtedly less than it would've been with a different process, but in this case your job is to make the best quality manual you can *within the imposed limitations*.
<<Anyone have any ideas of how I should approach my next two weeks? And then,
how should I try to get this to work better next time?
>>
Take a deep breath. Whenever you get overwhelmed take a little break, and break the tasks down into handable chunks. Keep a sense of humor. Prioritize. Don't forget to eat healthy and rest sometimes. When it all seems too crazy, post to Techwr-l or email or call a technical writing friend who has been through it all before (or your friends and family who know your good qualities and will remind you of them).
For the next time? If this is a repeated thing in your company, you will grow more calluses over your quality-spot, so you will need to remind yourself about quality from time to time, just in case you end up in a company or situation that actually cares in the future. When planning the unplannable project, realize that you will probably need to punt in the end. If there are actually halts, changes of direction, or pauses in the project, use the time to organize to be lean and mean the next time the fan gets hit wit' the ummm... schtuff... Don't blame yourself, although honestly if you secretly know there are a few weaknesses in *your* process, go ahead and fix 'em. One thing to fix is the expectation that the process will always be perfect, but it looks like life is taking care of that for you, so hang in there and remember, you are a credit to the profession.
Rose A. Wilcox
CHQ, 17th Floor
Tranz1 QA/Documentation
602-250-2435
Rose -dot- Wilcox -at- PinnacleWest -dot- com
I am a writer because writing is the thing I do best. ~ Flannery O'Connor
---
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.