Planning, budgeting and all that

[Kevin McLauchlan <kmclauchlan -at- safenet-inc -dot- com>]

Hey all,

After reading and participating (shame on me) in the latest churn of the
Certification 
saga, I noticed some statements by some people that got me thinking on a 
separate (but possibly still related) issue.

Do we know if the majority of us participate in real planning of customer
documentation?

By that I mean the following.

When companies and organizations reach a certain level of maturity, they
have people 
or groups who are in charge of planning for the next thing they're going to
make and 
sell. Sometimes there are actual Project Managers, those being actual
separate 
persons, not just hats worn by people whose real titles are perhaps Product
Manager, 
Development manager, etc.

So, they make skeleton plans and then ask the stakeholders to submit each
their 
own sub-plan to flesh out the skeleton. Presumably, lone writers or writing
departments 
then size up the proposed task, calculate their resources and submit a
multi-week 
timeframe (with a little padding) during which they could reasonably
research, write, 
review, fix and publish the desired documentation set. Some negotiation
occurs, and 
the end-date (the General Availability release date) is set, according to
what all those 
reasonable people submitted.  At least, that's the mythology. What I want to
know is 
if it's reality anywhere.

Here's what I mean...  in my experience, a project might _start_ with no set
finish 
date in mind, and some of the process from the preceding paragraph will
probably 
happen... but at some point, Biz Dev or Product Management will go out and
find 
a sponsor customer for the new product. The sponsor/driving customer will
nod 
their heads and say: Why yes, we could use that. In fact, we'll revise our
current/next 
project to take your wonderful new product into account.... and here's the
date we 
require it.
Boom.
Suddenly your company's new project does have a hard finish date. Suddenly 
all processes and plans are re-worked, working back from that hard finish. 
QA is the last, and they have a lot of clout, both about the amount of time 
they'll need (you want us to do the full suite, or you want to start
trimming 
configurations and supported platforms?), and about the condition the
product 
must be in when they receive it. So, the people who will hand off to QA,
namely 
Engineering Test (or whatever you call it in your company) work their
schedule 
backward from where they'll hand over to QA, and they set their start-point 
accordingly. Eng-Test, being part of Engineering, doesn't have quite so much

clout, so there's a gray area regarding their start time and the condition
of 
deliverables.  Given that Development must have at least a little time to
actually... 
well... develop the thing, they and Eng-Test agree to some overlap. Dev will

deliver a mostly-kinda-working version on Eng-Test's nominal start date, but

will actually trickle in some fixes and updates throughout the Eng-Test
cycle, 
trying to avoid any changes to firmware ('cuz that's the biggy when it comes

to restarting testing cycles).

Meanwhile, the backward pressure has had quite an effect on the Development 
effort, which means it's had quite an effect on the original dream product.
There 
simply isn't time for all those lovely features - maybe we can put them back

in at rev 2.  But some of them absolutely have to be developed, even though 
the new driving customer doesn't want them, because their underpinnings are 
also the underpinnings of features the customer does want. Kinda. In other 
words, the original product definition fluctuates. The original description
on which 
the writer or techpubs department made their plan is now a funny historical 
document that nobody really has time to update. Really, it will continue to 
fluctuate strongly until the end of the Dev cycle and fluctuate weakly right

into the Eng-Test cycle.

So, the writer can't do much up-front prep, because it's just as hard to
take 
stuff out and re-write around it as it is to wait for a bit more firmness
and 
write frantically around what looks to be the real product. Besides, there 
are other things going on in addition to this project.  The timeframe 
has shrunk from some 'planned' number of weeks to roughly the same 
time-frame as the Eng-Test cycle... which co-incidentally is when both 
the writer and Eng-Test will have prototypes to explore and learn. 
Well, actually, the writer should finish before the end of Eng-Test, because

the Eng-Testers (or a designee) must review the docs against whatever 
form the product finally takes, before the whole lot goes to QA.
And by the way, if there are any issues that delay receipt of early 
hardware.... well, Eng-Test has more clout than the writer, and will
therefore 
get dibs on prototypes.

The writer is welcome to remotely connect to Eng-Test machines in the lab, 
but mustn't actually DO anything, because that would disturb the
benchmarking 
or the multi-unit fail-over testing or.... or...

Can't the writer at least take the interface details from the Engineering
Statement 
of Work (or whatever it's called in your company), and write up the basic 
menu items and syntax and some basic procedures?  Well, s/he could 
if that SoW had actually been written or re-written to reflect the way the 
product will really look. It seems that document will be re-visited when the
Dev manager has some time, immediately after this rush, ok?

Meanwhile, the developers, who sprinted to the deadline, continue to sprint 
as they fix the issues discovered by Eng-Test. Which is fine, except that
they 
don't have a lot of time to answer questions. Eng-Test (which is populated
by 
saints, by the way) _does_ make time to answer questions, because they're 
nice people and because they've known the writer to point out problems that 
they missed, in the past, but since they partially restart their cycle every

time a new fix comes out of Dev, they're so busy they're bleeding from the 
eyes, and one hesitates to ...   you get the idea.  Actually, if I'm right,
at 
least half of you _live_ the idea, as your normal working circmstance.

Now what was that about orderly planning and building in buffer days/weeks 
and other notions of that sort?
Is there, out there, another half who live that other way?  Do you get to
wear 
golden robes and halos, too?

Oh, did I mention that more than one project is going on at the same time, 
with sliding/overlapping timeframes, and there are many developers, 
several Eng-testers, but only one writer?

Hey Kev, sorry to interrupt, but can you pretty this up? I wrote it, but you
need 
to make it look official. We're meeting with the customer tomorrow. 
Maybe edit a bit, too?   Huh? Oh, well it's from that project we did two 
years ago... don't you keep that stuff on your desktop?
Kev?  Kev, are you crying? Laughing?  What's that noise?

Kevin

The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList

Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/techwhirl/ for more resources and info.