This may be your experience, in my experience in fact there is no IF about it, 
I just put it that way to be gentile.

Our documents pre-sage multi-mullion dollar contracts (at each stage of the 
project) and there is always plenty of fuzzy concepts to
go around at the early stages. No documents, no contracts. 

TWs and in particular the directors, managers are involved at these stages. 
Documentation is a 100% necessary adjunct to business
development from the outset.

From: Technical Writer [] 
Sent: Monday, October 29, 2007 8:29 PM
To: Leslie H Schwartz; framers at
Subject: RE: radical revamping of techpubs

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 do).

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.
Specializing in the Design, Development, and Production of:
Technical Documentation - Online Content - Enterprise Websites


Date: Mon, 29 Oct 2007 08:26:46 -0700
Subject: Re: radical revamping of techpubs
To: tekwrytr at
CC: 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 <lhs_emf at>; framers at
Sent: Monday, October 29, 2007 8:44:16 AM
Subject: 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.
Specializing 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
> 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
> 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
> 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]
> 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
> in most cases, documentation before the last iteration is considered both 
> wasteful and useless. While I have a great deal of
> 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
> more reasonable. 
> I didn't invent the idea of ignoring documentation until the final product is 
> ready (or almost ready) to ship. Far more
> competent, and capable people than me have decided that "involving TWs from 
> the early stages of development" is only useful when
> 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
> 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
> 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
> is built in an iterative process, rather than > being carved in stone, 
> reacting to feedback from the client, documentation >
> 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 
> at
> _________________________________________________________________
> 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 
< at> 
> 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 


Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try 

Reply via email to