Time required to write down "wisdom" (Re: "Adult supervision")

[john.loughney at nokia.com]

Thomas,

I think my original mail sounded a bit more cranky than I wanted it,
but I was more responding to Harald's original mail - by the
way is there an archive of this list?

Harald mentioned that the document he was talking about sat around,
the token passed between a number of editors, etc.  It sounded to
me like the process for editing the document, soliciting comments,
producing revisions and so forth, fell apart, resulting in a
much longer than needed process.

I am not advocating pushing documents forward without adequate
review, but much more for having pro-active editors, WG chairs
and sheparding ADs to make sure the documents are getting done
in a timely fashion, especially ones identified as important.
This is more about breakdown in management, in my opinion.

Anyway, this mail is coming close to solutions - which is not
really my intention of posting the original mail.  I think that
one of the problems in getting work done in a timely fashion
is the breakdown of the document management process.

br,
John

> -----Original Message-----
> From: ext Thomas Narten [mailto:narten at us.ibm.com]
> Sent: 12 May, 2003 23:56
> To: Loughney John (NRC/Helsinki)
> Cc: harald at alvestrand.no; problem-statement at alvestrand.no
> Subject: Re: Time required to write down "wisdom" (Re: "Adult
> supervision") 
> 
> 
> > It seems that the 'process' has some how gotten twisted to 
> disable the
> > quick publication of important documents.
> 
> This may true if the assumption is that the *process* is what caused
> the problems.
> 
> From my perspective, the real issue often tends to be:
> 
> 1) Good documents don't pop out in the -00 version.
> 
> 2) Iteration is essential. Iteration means a small number of people
>    (e.g., 1-5) read the document, provide good feedback, and then a
>    new revision is produced.
> 
> 3) process is repeated at least a few more times, with a different set
>    of reviewers providing the review and feedback each time.
> 
> 4) Process terminates, because subsequent reviews don't uncover
>    significant issues and the reviewers think the document is good
>    enough to ship.
> 
> You can't rush a document (if you want it to be good). Indeed, when I
> write documents, I personally find that if I reread something I wrote
> a month earlier, I often find obvious things that need fixing. I often
> don't see these if I review the document a few days after last working
> on it. The point here is that good documents just don't happen on the
> first version and time is needed to properly review and iterate.
> 
> Where the "process" sometimes goes wrong is that the sequence of
> reviews and iterations haven't happened properly/optimally. Either not
> enough iterations, or too long between iterations.
> 
> IMO, there is a problem here that bears further examination. Getting
> good reviews and then subsequent revisions in a timely fashion is
> something I see too much of.
> 
> > I think that we, as an organization, do need to do better.
> 
> Yep. IMO, we should look hard at ways of ensuring that the needed
> iteration on revisions happens in a timely fashion. But not too
> timely, as that leads to documents being pushed forward before they
> are truly ready.
> 
> Thomas
>