TW dept managers or directors in particular do have a place in developmental 
stages. They provide user advocacy in the initial stages, when the development 
is most nebulous, providing direction and focus toward the common goal of the 
team: happy customers who like the product and want to buy more. From the TW 
perspective, the TW mgr/dir gathers info about headcount impact, resource 
allocation dynamics, etc.  

  You simply cannot categorically state that TWs have no place at any point in 
a project, because there are too many successful use cases that prove to the 
contrary, at least 3 of my previous gigs being examples thereof.  It depends on 
the pace of development and the length of the product life cycle, among other 
things. The faster the products develop and the shorter the product life cycle 
is, the more critical it is to have TW integration at the earliest phase.

  Creating user assistance is indeed a necessary task, but it is only one of 
many that TWs perform. User advocacy ? getting the user expectations back up 
the chain into the ears of those who can impact what the users end up getting ? 
is at least as important as the more common task of user assistance. If all the 
user needs is assistance, they'll just ring off the hook with tech support or 
customer service. User advocacy ensures higher quality products that lower call 
volume to tech support and customer service. Writing good, usable Help in terms 
that the user understands is another way to drop the call volume. But, rely on 
either without the other and you don't reap the maximum benefit of TW staff.

  Rene Stephenson

Technical Writer <tekwrytr at> wrote:

That is a very big if. A full partner participant-stakeholder, or more likely 
the department manager? It is more likely that the software developers, 
business analysts, and the project manager are collaborating to get a decent 
set of requirements down. At that stage, TWs have no place, whether department 
managers, full partner participant-stakeholders, or something else.

When the requirements are determined, and possibly after several iterations, 
possibly after a prototype is up and running, TWs might be brought in. Even at 
that stage, it is early, because the GUI crew may not have the interface coded, 
the developers might not have the functionality carved in stone, and everything 
is still uncertain (in regards to exactly what the final product will be and 

TWs complete a very necessary task; creating user assistance. Until the final 
iteration, until all the requirements have been met, until there is little or 
no possibility of changes to the end product, there is little point in 
generating documentation that might become obsolete at the next iteration. in the Design, Development, and 
Production of:Technical Documentation - Online Content - Enterprise Websites

Date: Mon, 29 Oct 2007 08:26:46 -0700From: lhs_emf at pacbell.netSubject: Re: 
radical revamping of techpubsTo: tekwrytr at hotmail.comCC: framers at

Actually, I disagee, if the TW is a full partner participant - stakeholder, or 
more likely the department manager in the scenario you are discussing, they 
should also participate early on to get the sense of the uncertainty and what 
those issues are, at the very least these issues are going to affect their 
scheduling and the expectations they have to deal with.
----- Original Message ----From: Technical Writer To: Leslie Schwartz ; framers 
at lists.frameusers.comSent: Monday, October 29, 2007 8:44:16 AMSubject: RE: 
radical revamping of techpubs

I agree wholeheartedly. That is not the issue. The issue goes back to the BA 
interpretation of (and translation of) the software requirements. If there is a 
high level of certainty on the client side about what the finished product 
should be, TWs should start early. If not, and it is essentially a fishing 
expedition with ambiguous outcome, TWs are only useful at the last. 
Unfortunately, the "agile" methodologies strongly sell the sense of control to 
executives, pushing the idea that they can develop on the fly, adding and 
removing "requirements" as the executives see fit. in the Design, Development, and 
Production of:Technical Documentation - Online Content - Enterprise Websites> 
From: lhs_emf at> To: tekwrytr at; bhechter at; framers at> Subject: RE: radical revamping 
of techpubs> Date: Sun, 28 Oct 2007 19:04:10 -0500> > I belong to several 
message - interest groups and I am used to
 hearing people give their opinions in a bombastic manner. So its no> big deal 
to see that happening here. But if this discussion is to have any real value it 
will be to share our perspectives with> others and learn something about points 
of view's entirely different than our own, which requires some tolerance and 
mutual respect.> > > My view and experience is that it definitely helps to get 
the TW involved early on, but it?s a waste of time for them to sit all the> way 
through each meeting, and for the entire duration of each meeting.> > Marketing 
requirements documents and engineering specification documents, if they are 
adequately written will help the TW formulate> the user documentation at a 
fairly early stage, but the bulk of the documentation effort comes towards the 
end of the development> cycle. And ideally the writer of the user guide if that 
is they type of documentation we are discussing now, should be a> knowledgeable 
user with some fresh insights into the
 learning curve the novice user will face, and some empathy for that new user.> 
> Ignoring the need for documentation, putting it off until the last moment is 
a formula for poor quality documentation.> > - In my humble opinion.> > Have a 
great work week!> > Leslie> > > -----Original Message-----> From: at 
[ at] On> Behalf 
Of Technical Writer> Sent: Sunday, October 28, 2007 5:47 PM> To: bhechter at; framers at> Subject: RE: radical revamping 
of techpubs> > > Well, a difference of opinion is what makes a horse race. 
Iterative software methods do not require iterative documentation methods;> in 
most cases, documentation before the last iteration is considered both wasteful 
and useless. While I have a great deal of respect> for Steve McConnell, 
proposing early draft user guides as a replacement for requirement specs is a 
bit off the
 road. > > If you develop software, and intend to use early draft user guides 
instead of requirements, you are going to be greeting the folks> at Wal-Mart 
rather than trying to pull back a contract or two from Bangalore. The statement 
is at odds with most developers' (and> most business analysts') understanding 
of "requirements." Putting an occasional "agile" into a sentence doesn't make 
the process any> more reasonable. > > I didn't invent the idea of ignoring 
documentation until the final product is ready (or almost ready) to ship. Far 
more intelligent,> competent, and capable people than me have decided that 
"involving TWs from the early stages of development" is only useful when the> 
end product is carved in stone before the first line of code is written. That, 
for better of worse, is rarely the case.> > Lastly, given that about a third of 
all software projects, agile or otherwise, fail so badly they are abandoned, if 
you ignore> documentation completely, you have a one
 in three chance of coming out ahead when the project flops because you have at 
least saved> the cost of documentation.> 
in the Design, Development, and Production of:Technical Documentation - Online 
Content -> Enterprise Websites> > > Date: Sun, 28 Oct 2007 12:21:17 -0700From: 
bhechter at yahoo.comSubject: re: radical revamping of techpubsTo: tekwrytr at 
hotmail.comCC:> framers at lists.frameusers.comSorry, but I find the thread 
both:a) Off-topicb) Misleading. Iterative sofware methods require iterative> 
documentation methods, but by no means do they eliminate the parallel need for 
early draft user manuals. In fact, Steve McConnell> (Code Complete) proposes 
early draft user guides as an agile replacement for requirements specs.Ben> 
Because the application itself> is built in an iterative process, rather than > 
being carved in stone, reacting to feedback from the client, documentation > 
before> the last minute is pointless. The reason should be
 obvious; the > application being documented in the early stages bears little> 
resemblance > to the application delivered. Ben Hechter Vancouver BC bhechter 
_________________________________________________________________> Windows Live 
Hotmail and Microsoft Office Outlook ? together at last. Get it now.>>
 > > You are currently subscribed to Framers as lhs_emf at> > Send 
list messages to framers at> > To unsubscribe send a 
blank email to > framers-unsubscribe at> or visit> > 
Send administrative questions to listadmin at Visit> for more resources and info.> Boo! Scare away worms, 
viruses and so much more! Try Windows Live OneCare! Try now! 
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!

You are currently subscribed to Framers as rinnie1 at

Send list messages to framers at

To unsubscribe send a blank email to
framers-unsubscribe at
or visit

Send administrative questions to listadmin at Visit for more resources and info.

Reply via email to