Conference 7.286::digital

See 3233.6 for a lucid description of how Tech Writing ought to
be managed to be valuable.

On the other hand, if Tech Writers are treated as interchangeable
cogs, which seems to be the DEC way, then writing might as well
be outsourced.   In neither case are you likely to get quality
documentation as a matter of course (the better writers that
I've worked with manage to do a good job in spite of the 
system, not because of it).

    From my experience it is *much* more effective to have writers who are
    part of the team, who participate from concept through implementation,
    rather than hired hands/fingers who work only on documenting.
    
    By having writers on the team we have observed the following:
    
    	- by participating from the start they understand the work in
    	  much more detail, and therefore can explain it more clearly
    
    	- often they identify alternative communications vehicles, or can
    	  help fine-tune our initial ideas. For example they can determine
    	  how to most effectively provide 'help' functions, or they have
    	  proposed new ways of communicating (e.g. multimedia demos).
    
    	- they can help write many of the project's documents, beyond the
    	  typical deliverables. Because our writer(s) have been involved
    	  early on they often see opportunities to help the design team
    	  by maintaining the design document, or by managing the minutes.
    
    	- there is less overhead for the rest of the team as the writer
    	  should be familiar with the product, how it works and who knows
    	  what. Without this we need to spend time teaching them, managing
    	  who they talk to, etc. 
    
    	- our writers are viewed as a team, i.e. they manage their time
    	  and their deliverables to the other parts of the project. They
    	  can propose schedule changes based on new or changed needs within
    	  the project, because they are a key part of the overall team.
    
    	- a writer who understands the product and its purpose can be
    	 very helpful in selling, or in discussing the product with other
    	  groups. Our writer meets with other groups to explain what we
    	  are doing, see how we might work together, etc.
    
    Perhaps it's related to *how* we manage people. Because we include our
    writers as a part of the larger team, and treat them as such, they feel
    they can propose alternatives, or that they can go beyond what we have
    asked us for. Quite frequently they have gone off and done some very
    creative things without being asked (most recently an online help
    module). They are invested in the success of the larger team, and are
    very involved in constantly thinking of better ways to do their jobs
    and communicate to our customers. If we had a more client-customer
    relationship I expect they would do what the contract explicitly called
    for, and we would all lose a little.
    
    Tim

you asked for comments from engineers, but I don't see why writers
shouldn't be allowed to plead their own case... so I will.

Regarding the previous reply, I am a little disheartened that there
is scant recognition of a good writer's ability to contribute beyond
documentation matters. A good writer understands product
goals and can/should be an important part of product design processes
right from the earliest stages. 

Employing "commodity writers" simply to document what engineers produce is
missing the point. Good writers can help good engineers to reach a better 
understanding of what a product should do and how it should do it, 
not simply how it should look, or what messages it should return, or
how the help module should work. Good writers ask questions that don't seem
to occur to good engineers. Also good writers can provide a high level
understanding of products and product sets that seems to evade many
otherwise excellent engineers. 

Personally, I find the idea that the corporation doesn't expect writers to
play this kind of role rather depressing.

I've worked on several projects with Document writers, and some the best results
were in part, due to the writers being an integral part of our team.  Thier
suggestions on user interface issues were invaluable, but they also became part
of our first line of testing.  They tested every switch, every possible mistake
a user could make, to make sure that what they said would happen, would happen.
Our seasoned doc writers help in local user training.

Sorry, I don't think Doc Writers are a commodity, they are an necessary part
of a successful team.

my 2cents worth.

Alice

In my 16+n years with engineering here, I've watched the paradigm shift from
writers who were part of the team for the long haul (multiple releases over
several years) to writers who are managed as if they were interchangeable
parts, sometimes leaving in the middle of a point release to have their
duties assumed by a new writer.

I haven't even been able to adjust to _this_ shift yet.

-Jack

My experence as a design engineer dealing with DEC writers is somewhat
limited (and dated) but can be outlined:

  * The quality of the work is good.

  * The amount of time it takes is longer than expected.

  * The price is absurd.

I've seen projects canceled because of the documentation charges.

    Re: .0:
    
    (FYI, I'm project leader for DECmigrate for OSF/1 - a software
    product, so that's my perspective)
    
    >Some people feel that one technical writer is pretty much
    >like another, a commodity skill. Others feel that writers
    >have varying levels of expertise and that a good writer is
    >valuable to a project.
    
    Technical writers are a commodity to the same extent that software
    engineers are.  Some are great and some are bozos; good ones are
    valuable to a project, and critical to the success of a product.
    Bad ones can be worse than non-existant - they can detract from the
    effort at hand.  Just like good or bad software engineers.
    I'm fortunate to be working with two really good writers.
    
    >I'd like to ask engineers (especially project leaders)
    >if they care whether the manuals for their projects are
    >written in-house or outside?
    
    No I don't.  What I care about is the quality of work.  There is
    no substitute for excellence.  If I'm working with a writer whom
    does excellent work, I don't care if that writer happens to be
    a contractor or not.  But I _do_ want to have that writer in on
    the project/product from start to finish.
    
    .2 describes all sorts of positive reasons to have writers
    involved from the start - I happen to agree with every single
    point made.
    
    If this question is specifically targetted at what do I think about
    the way IDC proposes to do business, then the answer is I believe
    that it is a good thing in the long run - and here is why:
    
    IDC lays off writers.  Major suck-o for people going through trauma
    of getting laid off.  IDC now sells itself basically as a headhunter
    agency with one customer: Digital.
    
    I have a project coming up which requires a writer.  I find a suitable
    candidate - bypassing IDC totally.  That's win #1.  I get to select
    my candidate, and not have it handed to me.  Less bureaucracy, less
    paperwork, and I get the writer I want.  I find a suitable contractor.
    Said consultant gets to set their price.  As consultants have to
    provide their own insurance, and the uncertainty of continued employment,
    they charge hefty rates.  But LESS than the cost of paying for the
    baggage of IDC management plus the former cost of the writer.  That's
    win #2 - cheaper to me.  The writer gets to take home more $$$ than
    they would otherwise, as their efforts don't have to subsidize IDC.
    That's win #3 - a happy (and presumably more motivated) writer.  IDC
    fails due to a lack of willingness of engineering groups to pay for
    zero added value.  Corporation gets rid of 'new' IDC.  That's
    win #4 - less baggage/overhead for the corporation.
    
            

    All the remarks about writers needing to part of a team etc.
    are valid.
    
    Some people however seem to be making the connection between 
    writing outsourcing and the hiring in of "commodity" writers
    (whatever that means).
    
    Here in Holland (as I assume in most non-English speaking
    countries) there has been a long tradition of hiring in
    (English speaking or rather English writing :-)) writers.
    
    With some 10 years of experience with this my findings are:
    
    - the quality of the writing is not dependent on whether the
      writer is internally or externally employed
    
    - the ability to form into a team is not dependent on whether
      the writer is internally or externally employed
    
    The quality of both of the above is 100% dependent on the quality of
    the writer and not who their actual employer is. 
    
    If outsourcing means that writers are being hired in and brought
    onto the team my experience is that this can work out without
    a problem. If outsourcing means however that the writing is to
    take place offsite then that sounds like mucho problemos. Not
    quite sure which one is meant....
    
    re roelof

    
.0>              I'd like to ask engineers (especially project leaders)
.0>              if they care whether the manuals for their projects are
.0>              written in-house or outside?
    
    In light of the current proposal by IDC management to dismiss all
    writers and contract out the writing work, I interpret this question
    as, "Do you care whether the manuals are written by DEC employees or
    by contractors?" My answer: No, I don't care whether manuals are
    written by DEC employees or contractors. If the process is working and
    all other parameters remain constant, the employment status of the
    people who do the writing should have little effect on the outcome.
    (I assume that others hold the same opinion of my job, engineer and
    sometimes project leader, though I prefer my employee status.)
    
    The interesting question is whether the process of producing product
    documentation at DEC is indeed working. My answer: No -- it is
    seriously broken, and has been for some time.
    
    As .2 points out, it is important for writers to be part of the larger
    development team if they are to contribute effectively. This means that
    writers should have a long-term asociation with a product; they should
    know the product at least to the level of a proficient user; they should
    be expected to contribute at all phases of a project. Every engineer
    with whom I have ever conversed on this topic is in general agreement.
    
    The documentation process is broken because IDC management does not
    agree with this viewpoint. IDC management is the chief proponent of the
    writer as a commodity item, a pin-compatible organic word processing
    machine. Writers are not encouraged to learn products; in fact,
    evidence has indicated that they are actually discouraged from doing
    so. Long term product associations are not established; I have seen
    writers work for a few weeks on one project, switched off to something
    totally different, and then switched back in response to an end-game
    crunch. Every engineer with whom I have ever conversed on this topic
    has expressed varying levels of frustration as a result of this
    commodity mindset on the part of IDC management.
    
    For a number of years on a number or products in a number of locations
    I have been frustrated by the IDC model. I have taken every opportunity
    as an individual contributor in the engineering organization to change
    it, to no avail. When I first heard of IDC's plan to "outsource" the
    actual writing, I was convinced that a bad situation could only get
    worse -- but I am beginning to see it as possibly the solution.
    
    The current broken model is maintained by an entrenched IDC management.
    They own the resources I need, and I am powerless to control how thay
    apply those resources to my problem. If they cut their ties to those
    resources, the game changes completely. Why would I continue to give a
    large chunk of money to IDC management in return for resources I can't
    control? Why not just contract with the writers themselves. At very
    least, that has to be less expensive for me, because the IDC management
    overhead is eliminated. Furthermore, if I hire or contract a writer
    directly, I control how long that writer will be associated with my
    group how well that writer should know my product, what contributions
    that writer should make to various stages of my project. I can choose
    to treat that writer as a valued member of my team, or as just another
    commodity item.
    
    The logic here is so blindingly obvious that I can't imagine it being
    lost on many engineering managers. IDC's proposal will cause short term
    and possibly grievous pain for writers as they are cut loose; but in the
    long term, it will provide the best chance for writers to become valued
    members of engineering teams and for the company to fix a problem that
    has far too long plagued product development. Every engineer should
    take advantage of this opportunity by tracking valued writers as they
    are freed by IDC management, and by discussing with engineering
    managers the benefits of establishing direct and long-term associations
    with these writers.
    
    And we should all extend a large "Thank You!" to IDC management for
    making it possible.

    re: .9
    
    The presentations about the IDC outsourcing seemed to be talking about
    the use of what are essentially book-production companies.  Less use of
    regular contractors was mentioned.  (I noticed, being on contract
    myself.)
    
    re: several mentions of ICD costs -- that's the truth.   I could
    undercut the current IDC charges by a full $10 an hour and still be
    making considerably more than I'm making now. 
    
    re: the topic in general
    
    I've been a technical writer (with stints in editing and customer
    support) for most of the last 15 years, most of that at DEC in one form
    or another.  I've worked in a lot of projects under a lot of different
    conditions.  The ones where you get to be on the project from day one,
    get to participate as part of the team at all stages, and get to share
    in the rewards are unquestionably the most fun.  They produce the best
    team experience, and I think they may produce better overall products. 
    But looking back, I can't tell which manuals were written by the
    dedicated devoted team that put a couple of years of their lives into
    it and which manuals in the same set were written by the hired gun who
    came on for the last six months.  
    
    I contract now.  I figure if I'm going to be a commodity, I may as well
    be the one who gets the benefits.
    
    --bonnie

    RE: .8
    
    We were told that engineering groups will not be "allowed" to
    circumvent SES (IDC will not exist).  How this will be enforced is
    anybody's guess.
    
    RE: .9
    
    The plan is for the writing to take place off-site, with planned
    interaction (via telephone and visits) with engineering.  This is
    because one of the goals is to allow Digital to further consolidate
    buildings and eliminate equipment (overhead costs).
    
    The preliminary plan is supposed to be ready a week from Friday.  We'll
    see what happens next!

    
.12>    The plan is for the writing to take place off-site, with planned
.12>    interaction (via telephone and visits) with engineering.
    
    This will flat-out not work. It will fail. It is a horrid plan.
    It stinks like week-old road kill. It will die aborning.
    
    (Have I missed any ways to say this?)
    
    In the current, badly flawed model, one of the few things writers have
    going for them is that, for however beief a time, they are in direct
    and daily contact with the developers. I once saw this "bnefit" erode
    enormously when writers were moved from the floor with the engineers to
    the floor below.
    
    -----------
    
    I do hope that "the preliminary plan" will circulate outside IDC.
    

>    We were told that engineering groups will not be "allowed" to
>    circumvent SES (IDC will not exist).  How this will be enforced is
>    anybody's guess.

If this is true, what is the justification on the part of IDC management
that writers are "interchangeable", but "book production" or whatever
services are conceptually being provided is somehow a Digital "core
competency" that we should be doing instead of outsourcing the whole
thing on a per-project or per-organization basis (with coordination
in purchasing where appropriate)?

This seems like part of a pattern of "management preservation"
on the premise that management is a somehow Digital core competency
or "Digital added value".  (And if it is, why are we in the state
we are today?)

It seems like this is a good example of "empire building" (or maybe
"empire maintenance".)  I wonder what the people in the "supply chain"
using the "IDC services" will see...?  Will the corporation wind up
paying more over time for these services rather than less due to
the disruption (particularly if writers are no longer co-located?)

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

==============================================================================

At least a couple of people have posted replies saying that they think 
that it would be advantageous for an engineering group to contract 
directly with writers or with a contracting agency, rather than having 
to go through SES/IDC to get writers. 

If I were you, I would immediately try to find out if this will be 
possible after all writers are TFSOd. Believe me, SES/IDC management is, 
at this very moment, trying to devise a system that will *force* you to 
go through them. They will give you all kinds of reasons: "quality control," 
"requirements analysis services," "vendor management services," "account 
management services," "project management", etc., etc., etc.

Make your views known now that you do not want to go through an SES/IDC 
management layer. 

RE: .8:

    Technical writers are a commodity to the same extent that software
    engineers are.  Some are great and some are bozos; good ones are
    valuable to a project, and critical to the success of a product.
    Bad ones can be worse than non-existant - they can detract from the
    effort at hand.  Just like good or bad software engineers.
    I'm fortunate to be working with two really good writers.

I agree with just about everything said in the previous replies.  What
counts is the quality of the work, and you can only get the required
quality by employing good people, and by actively including them in the
team for a long period of time (one release isn't enough, especially for
complex software products).

But the exact same comments can be made regarding software engineers, or I
guess any individual contributor position, especially technical ones.  So
be careful what you say, it may come true!

I also agree that the idea of SES/IDC requiring the rest of the corporation
to go through them for writing contracts is ridiculous.  The management
structure was what was responsible for the deterioration over the years; 
why would you want to contract with them?  Downsizing was supposed to be
accompanied by having leaner, more focussed organizations, but we seem to
be keeping all the fat instead...

Bryan

> possible after all writers are TFSOd. Believe me, SES/IDC management is, 
> at this very moment, trying to devise a system that will *force* you to 
> go through them.

  The next question is, can SES/IDC force a group to go thru them (which I as-
sume means thru them AND thru the out-source company) for tech writing if that 
group has been set up as a separate division, as have been proposed for some or
all of the mega-groups in Digital?
  I agree with several replies that having to work with off-site tech writers
would be a disaster. A short distance is workable; our tech writers are three
miles away and it seems to work OK. But the idea of tech writers having to
travel 20 miles to see us in person (and that travel cost is ultimately borne
by Digital) scares me. Also, these outside off-site tech writers would probably
not be on the Easynet, which means they would not have access to our project
notesfiles. It is feasible to set up an Easynet-like communication system for
Email between Digital and outsiders; this was done a few years ago for suppliers
(node SEETRA). But I have never heard of outsiders having read/write access to
our notesfiles, and I think corporate security rules prohibit it. 
  There is no substitute for having our tech writers with us electronically and
in person on a regular basis. Videoconferencing? I doubt any tech writing out-
source company can afford video conferencing equipment, and even if they could,
it's not like being there. 

re: .17, Bob

> But I have never heard of outsiders having read/write access to
> our notesfiles, and I think corporate security rules prohibit it. 

Could it be handled in the same way as the ISV conferences?

-Jack

A few thoughts, but first my perspective.

I have worked for Digital as a technical writer for about six months. Before
that, I worked for a French computer company, one of the Japanese mainframe
houses, and an Australian documentation company. I have worked on products
ranging from telecommunications to statistical packages, and on documents from
systems programmer's guides to telephone exchange installation manuals to sales
glossies.

This discussion so far has been conducted from a perspective that was regarded
as dated ten years ago, namely, that documentation is in some way a function
ancillary to engineering.

The computer companies that I worked for previously considered that they were
in the business of developing software products - where a software product is a
bundle of tested code, documentation, packaging and support services, sold as a
unit.

High-level design of such software products is carried out by marketing
departments, and detailed design is carried out by development management.

At a lower level, writers in a marketing driven company do not usually report
to engineering groups - they report to development management from the same
level as engineers.

This is not the way we do things here! Digital is not noted for its marketing
strengths; indeed, an engineering ethos dominates the company, and there is a
pervasive sense that writers, marketers, managers and so on exist merely to
serve the engineering function. We all thought like that in 1980, but times
have changed.

Only in a company with an engineering mindset could a phrase like "commodity
writers" be taken seriously. Many engineers believe that writers must have the
depth of knowledge and perspectives of an engineer, but it is my experience
that an engineering perspective can get in the way of producing good
documentation. 

From a writer's viewpoint, there are dangers in becoming too closely associated
with particular projects: management may adopt the view that, since you have
been documenting device drivers for the last five years, you can't possibly
take on that job writing marketing glossies... Writers are some of the few
people around with skills genuinely universally applicable within the company,
and should not allow engineering ideas on the desirability of immensely
detailed product knowledge to obscure that point.

Some of the assumptions underlying the employee/contractor debates are a trifle
odd. (I am not an American, and I find many American attitudes strange - we are
indeed divided by a common language...)

The most interesting assumption is that a writer who has been fired will turn
up for work as a contractor. So s/he may - at another company. As I pointed
out, writing skills are universal.

A final question: many notes use the acronym "TFSO". I presume this is a
euphemism for being fired, but what does it stand for?

James  

re: .-1, James

> A final question: many notes use the acronym "TFSO". I presume this is a
> euphemism for being fired, but what does it stand for?

Not "fired, per se, but "laid off". The difference being, in American
culture, that the former is "for cause" while the latter, not. The types
of benefits available in the two circumstances vary widely.

re: TFSO

I've become so cynical that I can no longer remember the "formal" definition
of the acronym, and, since your query appears genuine, I will refrain from
entering any of the more common interpretations.

-Jack

    I thought it was a commonplace that when an empire becomes dependent on
    mercenaries instead of its citizens, its collapse is at hand.
    
    Dick

RE: .19

TFSO = "laid off" in American English, "made redundant" in British 
English.

--PSW

I too believe that the best docs come from writers that are part of the
team, but that just hasn't happened very much lately...

Given the choice of 'outsourcing' the tech writers or the engineers,
which would you choose?

	Joe (who is preparing to make the Quantum Leap)

    	I have only once dabbled in technical writing. I wrote and
    documented one of the example programmes for the VMS V1.0 System
    Services manual.
    
    	The code I wrote was correct according to the language standards. I
    had finished with that while the compiler was still pre field test. If
    I had been an external contractor, that would have been the end of my
    involvement.
    
    	However, I was in the same building as the compiler engineers, and
    had access to their machine. I compiled my code.
    
    	It would have been very embarrassing if everything had shipped and
    the example programme in the manual had caused the compiler to crash
    with a stackdump.
    
    	It seems that the compiler writers had just not thought of what
    seemed to me to be the obvious way of expressing omitted arguments in a
    system service call, and if I had not had access to a very early
    version of their compiler it is possible that their bug would not have
    been caught until shipment.

<<< Note 3238.23 by GEMGRP::gemnt3.zko.dec.com::Winalski "Careful with that AXP, Eugene" >>>

RE: .19

TFSO = "laid off" in American English, "made redundant" in British 
English.
    
    ... = `rightsized' in British DECspeak. Incidentally, I share the
    depression mentioned in the last sentence of .3; I say `incidentally'
    because there is no reason for hoping that the decision-makers may
    have any regard for this point of view. The clear conclusion is that
    mentioned in .11 - get out, and reap the benefits from outside. This
    strikes me as sad but inevitable.
    
    b
    
    b

    
    Having worked on various software projects within Digital, i find the
    prospect of outsourcing the documentation one which will backfire.
    
    A good Tech author tends to see the things that the team have missed
    (especially on the user interface) due to being to close. That extra
    level of testing (tech authors tend to be very picky and try all sorts
    of 'stupid' things) has proved invaluable.  Perhaps we didn't budget
    enough for testing :-) , but we had this extra level.  Presumably an
    outsourced tech author would stick to his brief - no freebies ?  
    
    Having managed to use the same technical author over a number of
    releases covering a few years (not continuously) , he also knows the
    aims of the product, and has been known to suggest a few extra's which
    have been put in.
    
    Having the tech author off site would make the situation even worse. 
    Lack of communication kills projects.
    
    Nigel
    

What I say below goes beyond technical writers and gets more to the point of a
bigger problem that exists in Digital.

If I am a project leader of an engineering project I am going to want the BEST
people on the project.  If I come in and take over an existing project I should
be able to fire (get them off my project) anyone who is not doing what I 
consider to be good work.  If this is a startup project (not too many these
days!) I should be interviewing people and not have people blindly assigned to
work on it.

What I have seen with technical writing is a project is assigned one or more 
writers.  If you end up with a good writer - consider yourself lucky.  If you
end up with a bad (many ways to define bad) writer - tough luck.  MAYBE you
will be asked to give input to their review to let your views be known.   

I have known good writers and not so good writer, I have known good writers that
turn into bad writers (hit a bad time in their lives).  In any case, I was
stuck, for good or bad, with the writers that someone assigned to my project.

Having a good writer, that uses and knows the product they are writing for is
great and saves engineers a great deal time (for example not having to explain
why the  "corrected for  English" version of what you sent them sounds nice but
does  not mean the same thing to an engineer reading it).

The above holds true for engineers on a project.  I have had bad engineers 
assigned to my project - people I would not hire off of the street, but I 
could not say no.  The project plan called for "N" engineers, and I was given 
that many engineers so if I missed my schedule it was because I was not doing
my job.  What it came down to is that I had to work around them.  (I have 
also had good people assigned to my projects - they are still working here...
just wanted to mention that in case they read this conference!).

If Digital acted like the small company that is slowing becoming it would fire
(never mind this TFSO stuff) people when they stop doing a good job - or stop
caring about the project they work on.  

Now, if I was this small company (I.E. an engineering project) and someone came
in and said:

	 "If you plan on documenting your software, you must have us write
	  and produce that documentation and here is what it will cost you."

I'd come back with "Who the hell are you?" followed by "Why?" and then a bunch
of other questions... If the answers made sense (good luck to the people who
are trying to think up answers right now) I'd give them a 6 month trial, if I
didn't like what I got out, I'd cut them right out of the process and start
shopping around for someone new.  

If SES/IDC ends up getting their nose wedged into the ability of engineering to
do their job in the best cost effective manner then they should be held
accountable.  Hey, maybe it will work (the majority of comments up to this
point are leaning the other way).

The drawback I see to contracting out the writing (with or without any SES/IDC
in place) is a possible inconsistency between what should be "common style"
books.  For example, all the books documenting OpenVMS should "read" the same
way (I know some of them don't today but...).  Can we contract out a
documentation person to say "document this, and use this style" handing them a
VMS doc set?

bjm - back to being an individual contributor on a software engineering project

>Can we contract out a documentation person to say "document this, and
>use this style" handing them a VMS doc set?

Of course. It's like telling a contract programmer what language to use.

Having no control over what writers work on your project certainly
sounds like a silly situation. 

Believing that the only or best way to gain that control is to
dismiss all your writers and contract in from outside seems sillier.

Surely there are other ways to gain that control. I'm sure that
contracting in writers can be made to work well, but it seems a rather
a draconian way to deal with the dissatisfaction with IDC's practices
that is being expressed in this topic. 

I am not personally familiar with IDC, having been hired directly by my
engineering group, but it sounds like the real concern expressed by 
several replies is that the writing organization is an impediment to
engineering, rather than the writers themselves. And yet, from previous
notes, it sounds like the organization will live on to perform some role
in controlling the outsourcing, but its writers will be dismissed regardless
of their individual merits. Do I hear correctly? ho hum.

� Given the choice of 'outsourcing' the tech writers or the engineers,
� which would you choose?

I take this to mean that you think writers are more easily replaced than
engineers. What is the essential difference between a writer and an engineer,
that makes you think that it is worthwhile to contract out all the writing work,
but not the engineering work?

What is the real cost of managing the contracting-out of all of a project's
writing work against the cost of having it done by Digital writers? 

The base noter says that [s]he finds some manuals easy to follow and others
downright frustrating. What bearing does this have on deciding where to get
technical writers from? Some programs are well-written, well commented, easy to
understand, maintain and correct. Other programs are a jumble of badly designed,
incompetent or smart-alec code that no-one except the original programmer can
follow, understand, correct or maintain. Would this fact make you decide to hire
contract engineers?

Perhaps the existing Digital writing organisations are not all they should be (I
don't know), but getting rid of all Digital writers because of organisational
problems is throwing the baby out with the bath water. We will lose a
significant source of knowledge, expertise and experience of our products, which
has cost Digital a great deal to build up, and we will have to start all over
again with contractors.

Vicky

    re: "laid off" 
    
    Being "laid off" used to be different from being "fired" in that it was
    expected when times were good, you'd be hired back.  Now, it means, as
    was pointed out, that you are basically being fired without cause. 
    And, one might sue for being fired without cause or for being 
    <fill in the blank with your favorite discrimination preference>.
    
    Steve

    
.31> Perhaps the existing Digital writing organisations are not all they should be (I
.31> don't know), but getting rid of all Digital writers because of organisational
.31> problems is throwing the baby out with the bath water.
    
    I agree 100%. However, people have complained about the current
    situation for some years now, and nothing has changed. It would be much
    more efficient to dump IDC management directly and fix the model so the
    writers can starting doing their jobs. But since nobody's been able to
    do that, our best bet is to grab the writers as they are dismissed (by
    employment in development groups if possible, by direct contracting if
    not) and let IDC management wither on the vine.
    

    When I was in engineering, working with tech writers, the best
    organization was when the writers worked directly for the engineering
    group.  When they got 'organized' into a central group, and
    contracted to engineering groups for specific projects, the writing
    quality seemed to go way down.

    The difference between contracting them from a central DEC group
    and from an outside agency seems pretty small.  Judging by the
    comments in here, using an outside agency might be better.

    It's a shame the writers are not being picked up directly by
    engineering groups rather than TFSO'd.
    bob

re: .33, Bill

>    do that, our best bet is to grab the writers as they are dismissed (by
>    employment in development groups if possible, by direct contracting if
>    not) and let IDC management wither on the vine.
    
Sounds like a good plan. One can only hope that it might be accomplished without
being thwarted by the typical bureaucratic obstacles. Won't hold my breath,
I guess .. . 

-Jack

I'm an IDC writing manager.  What follows is not a justification for 
what we're doing.  I intend it as a clarification of our intent.  
Whether it's "good" or "bad," you be the judge.

FWIW, we aren't laying off all the writers and outsourcing all of the
writing.  We are laying off more than half the writers and outsourcing
more than half of the writing.  The exact amount of "more than half"
will be determined by pilots that we are currently running to
determine what types of information seem to lend themselves better to
oursourcing and which types are too difficult to manage from a
distance.  We will be retaining enough technical writers (a much
smaller group) to handle the technical writing that is too
strategically important or difficult to outsource.  (MS Word based
HyperHelp comes to mind as a good candidate, since that information
needs to be imbedded into the code and tested along with the UI; a 
highly-technical Version 1.0 product might qualify.) 

FWIW, As best as I can understand it at my level (I'm first-level
management in IDC), Demmer and Strecker approved this "more than 50%
outsourcing of SES" plan.  If this plan is as detrimental to
Engineering as some of you think it is, then you might want to talk to
your own high-level management.  We here in IDC are (and have been)
getting very mixed messages about the value of in-house technical
writing.

*********************

This part is pure opinion:

If we oursource the documentation for the more mature products--documentation 
that is mainly in hardcopy form--and if we do the tough/funky stuff
(like HyperHelp) inhouse, then I think that the plan will work.  It's 
just that the vended documentation will be of lower quality than the 
inhouse documentation.  The degree of difficulty of managing this 
organization also goes way up, since there are so many players to 
manage (potentially).  And, with some types of documentation (Product 
X, in maintenance mode, Version 9, all hardcopy, techno-weenie-hacker 
audience), lower quality might be okay.  We'll succeed in saving a lot 
of money, and we'll get what we pay for.

Hey, I shop at K-Mart for some things whose quality doesn't really 
matter that much to me.  Throw rugs, wastebaskets, stuff like that.  
;-)

Finally, the engineering folks who think that they want to control the
documentation outsourcing are crazy (in my opinion).  It's going to be
very ugly, very difficult, and will produce mixed results.  I'm not
saying that you aren't capable of doing it and doing it well.  I'm
just saying that it's going to be a difficult managment job that a lot
of managers won't want to do (a lot of us in IDC/SES are trying to
figure out if we want to do that kind of management).  I think you'd
be happy to sign a contract with IDC/SES to have us manage that mess. 

Finally, I know that we are trying to prevent this situation, but
there may be a project that vends out some not-so-important docs, uses
a contractor to write another book, and uses several inhouse writers
to do the HyperHelp.  And an IDC/SES project manager (we used to call
them project leaders) would be the point of contact for the whole
mess.  In theory, the engineering group would always have a writer
right there (the project manager); it's just that the IDC project
manager may not have an inhouse team (or it would be much smaller). 


						--Gerry

.36> FWIW, we aren't laying off all the writers and outsourcing all of the
.36> writing.  We are laying off more than half the writers and outsourcing
.36> more than half of the writing.
    
    You haven't mentioned editors. My impression of IDC is that there are
    three tiers: managers, editors and writers. IDC seems to believe for
    some reason that writers are most easily "outsourced". I contend that
    the editing function, which seems to rely on well established language
    and style rules and little or not at all on technical expertise, would
    be more easily isolated and separated. Does IDC's plan call for laying
    off editors?
    
.36> ...If this plan is as detrimental to
.36> Engineering as some of you think it is, then you might want to talk to
.36> your own high-level management.
    
    Excellent advice. I hope all concerned individuals are heeding it.
    
.36> We here in IDC are (and have been)
.36> getting very mixed messages about the value of in-house technical
.36> writing.
    
    This is not a suprise. If you� create a bad model, you should expect
    "mixed messages" about the output. In my experience, negative feedback
    on in-house technical writing is based much less on the shortcomings of
    writers than on the system that sets them up to fail.
    
.36> ...the engineering folks who think that they want to control the
.36> documentation outsourcing are crazy (in my opinion).  It's going to be
.36> very ugly, very difficult, and will produce mixed results.  I'm not
.36> saying that you aren't capable of doing it and doing it well.  I'm
.36> just saying that it's going to be a difficult managment job that a lot
.36> of managers won't want to do (a lot of us in IDC/SES are trying to
.36> figure out if we want to do that kind of management).  I think you'd
.36> be happy to sign a contract with IDC/SES to have us manage that mess. 
    
    Allow me to paraphrase your argument: "We are creating a management
    nightmare; you're crezy if you take it on yourself rather than letting
    us manage it for you."
    
    The obvious rebuttal to that argument is, "You managed into the current
    state of affairs -- we're crazy if we contract with you to manage out of
    it!"
    
    I personally am not advocating that development groups take on the
    management of enforced documentation outsourcing. I personally am
    advocating that development groups implement what they know works (see
    many previous replies) -- incorporate documentation talent directly into
    the development group, through direct hiring is possible or long-term
    contracts if someone insists on playing silly games; contract with a
    much small and management-sparse central group to address matters of
    style and consistency (the editing and production functions).
    
.36> ...an IDC/SES project manager (we used to call
.36> them project leaders) would be the point of contact for the whole
.36> mess.  In theory, the engineering group would always have a writer
.36> right there (the project manager); it's just that the IDC project
.36> manager may not have an inhouse team (or it would be much smaller).
    
    Good theory.
    
    Now ask yourself, how much actual writing does a doc project leader do?
    Probably the same amount as a software project leader does coding --
    practically none. A project leader is typically tied up in process
    and administrative details; tracking the schedule, tracking conformance
    to the spec and plan, monitoring the problem rate and ensuring problems
    get tracked and closed, submitting to the weekly managerial floggings,
    making sure the periodic build goes well and assigning blame when it
    doesn't, juggling assignments, etc, ad nauseaum, ad inifinitum. Any
    of the above itens not germane to documentation project
    management/leadership would likely be more than offset by the need to
    manage the "mess" described elsewhere.
    
    If the above assumption is correct, you propose having a project
    leader, who does little or no actual writing, as the focal point, the
    funnel� of technical information between the development team and the
    writers.
    
    It won't work. The bandwidth is far to small.
    
    
    -----------------
    
      � "You" means IDC management in general over the past 5-10 years, not
        you personally.
    
      � AKA "choke point"
    

RE: Note 3238.36 by TNPUBS::FISHER

>We are laying off more than half the writers and outsourcing
>more than half of the writing.  The exact amount of "more than half"
>will be determined by pilots that we are currently running to [...]

Funny thing is that, according to the schedule from Ron Stokes' presentation
to IDC members, the changes to IDC/SES will be "visably underway" by the
time that anything can be learned from the pilots being set up now.  Make a
decision then scramble to rationalize it - seems to be what has taken place
here.


>We here in IDC are (and have been)
>getting very mixed messages about the value of in-house technical
>writing.

I think the message being sent is fairly clear, but it doesn't appear that
the message is being received.  The majority of past notes imply that
in-house technical writing *when the writer is involved with the project
long-term* yields the best results.  And when writers are systematiclly
removed from the projects and engineers, it complicates the situation and
quality decreases.  That message is pretty clear.  If this is true, then
this vending scheme is very likely to exacerbate the problem.  The mixup
here is that IDC's management has not been tuned into engineerings' messages
for a long time.


>Finally, the engineering folks who think that they want to control the
>documentation outsourcing are crazy (in my opinion). [...]
>I think you'd
>be happy to sign a contract with IDC/SES to have us manage that mess. 

So, the situation is that IDC/SES wants to outsource the documentation,
thereby (admittedly) making the situation "a mess", then offers to relieve
the engineering community of having to manage the "mess", for a price.  ?!?

>FWIW, As best as I can understand it at my level (I'm first-level
>management in IDC), Demmer and Strecker approved this "more than 50%
>outsourcing of SES" plan.

Seems that there is a lot of butt-saving maneuvers going on at all levels
here -- IDC management seemingly guaranteeing their own survival with the
"vending" scheme, individual contributors arguing their cases in the Notes
file and amongst themselves, and upper mgmt who will undoubtedly look good
if they can unload a bunch of expense (ie.  payroll, ie.  employees) with
little effort.  The question is, did Demmer and Strecker require this
action, do they really understand the consequences vs. benefits, and do
they really care? Or is IDC/SES's "proactive" stance on this subject driving
this?  Will we ever know?

An indisputable point is that this vending scheme is a MAJOR change.  Once
the majority of IDC is gone, it will be very hard to undo this action, if
necessary.  I have yet to hear a contingency plan if this vendor plan fails
to work satisfactorily.

-Mike

Being part of IDC I've followed this string with great interest, 
and I hope to be able to add a different perspective to the
discussion. 

The original question was how engineering feels about the value of
technical writing, and whether downsizing and outsourcing will affect
projects. I'd like to pose it a different way.  If there was any
choice in the matter, why would any writers want to have anything to
do with IDC once they become "free agents" and can work for whatever
agency and/or project they want? If SES/IDC (or whatever) is the
only conduit for getting Digital jobs, then the answer is obvious.
But if workarounds are possible, then there are a lot of reasons for
either side to not deal with this extra layer of bureaucracy.

At one time, it might have been advantageous to have a monolithic
organization (I'm thinking of CUP here) provide documentation
support to engineering groups in Digital.  At that time Digital was
very protective of its corporate identity, and so its books and
other documents needed a common look and feel. In addition, CUP was
locked in to its proprietary authoring tool, VAX Document. Why bother
getting outside contractors who had never heard of SDML, never mind
write with it? Nor did they understand Digital's SSB process, which,
by the way, made it very difficult (until recently) to release
anything that didn't meet the norm. (Try to release PC style
documentation 2 to 3 years ago - forget it!) While the rest of the
world move toward "industry standard tools" (read Wordperfect, WFW,
etc.), IDC writers couldn't even get PCs to do their work.

This is no longer true.  Writers have started to wean away from
Document, DECwrite, and other outdated or discontinued tools, and
they are now using what other folks in the industry are using.  
Win #1 for the writers! Who needs IDC's antiquated tools and
processes?

Now we hear talk about "commodity skills." It's both ridiculous and
demeaning to refer to someone's hard earned skills and experience as
commodities.  But that kind of talk is not surprising, coming from
an organization that has badly mismanaged its resources for the last
two years. It sounds like a rationale for dividing IDC up into two
camps - us and them - and making sure "them's" the ones that lose
their jobs. Project management can just as easily be outsourced as
writing - there are plenty of companies that do it.  

Now you can make a case for dividing work into core and commodity
*work*. IDC tried unsuccessfully to make this transition (I'll leave
it to others to try to explain why, but I think some of the reasons
were mentioned in previous notes).  The core work was supposed to be
information design and development, project management,
documentation and training for strategic and core Digital products,
and so on.  In other words, areas where we've already made heavy
investments in training and technical expertise, or where it was
strategically important to keep internal resources available.

Digital (IDC) writers, course developers, instructional designers,
could do the upfront design and development.  Either internal or
external resources could be deployed, depending on whether we had
the expertise in house, or needed to get it elsewhere.  Designing
version 1 of an information set could be considered core work; doing
revisions/updates was probably commodity work. Sounds reasonable,
right?  So why hasn't it worked?  And what makes anyone think that a
more extended version of this model can work successfully in the future? 

I think engineering will soon figure out ways of working around
whatever is left of IDC and bring in the people they want and need.
Victory #2 for the writers! They won't need IDC to find their work
for them, they can stay as long as they contract for and are
appreciated, and promotions and raises are not subject to the 
vagaries of quarterly results or organizational politics.

If engineering hires a writer from the outside, whether through IDC
or not, engineering will expect that writer to focus on its product,
work with its team, and satisfy its needs. The work that writer will
do will be the core work in the eyes of that customer.  The process of
finding, recruiting, and doing the paperwork to bring in the writer
is something that practical anyone could do - which is the really
the definition of commodity work.
    

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

===============================================================================

    Shades of 12 years ago, we all fought this same battle then.
    Engineering wanted to, and even did, hire their own writers. But the
    quality of the writing was inconsistent from one Engg group to another,
    and even the document size, color, cover design (I mean pictures and
    window cutouts also), and styles varied among Engg groups. Indeed, even 
    two documents from the same group were distinguished by their differences.
    
    At that time, Ed Services did hardware docs (having been assumed from
    Field Service) and asked Engg the hard questions, "Do you know how to
    manage a writer? Do you recognize good writing for your users or do you
    just go with a document that pleases your own manager who can say 'Look
    at what we did'? Do you have support services such as editting and
    illustrating that are readily at hand, or do you want your writer to
    begin running an independent service bureau from your shop? And do you
    maintain standards of quality that can be measurement tools from one
    writer to the next, or will you be satisfied with varying degrees of
    user acceptability across your products and product lines?
    
    Software Services, I believe, asked the same questions of the software
    development groups.
    
    Universally, the hardware and software groups agreed they'd prefer to
    develop hardware and software and leave writing to writing professionals. 
    Overhead is a part of the price you pay for letting someone else 
    manage your business; try being your own construction contractor, or
    hiring one who will manage the subcontractors for you. One gives
    personal satisfaction and maybe aggravation and frustration, while
    the other moves those emotions to another person and the job still
    gets done.  With a subcontractor to manage the project, you can also 
    do other things yourself and not let your primary job suffer. And if
    you decide to use a subcontractor, you can look at other jobs the
    person did and decide if you want that person to do the job for you.

    Although our discussion here concerns contract writers, remember also
    that a contract writer has only one loyalty. When a project's end looms,
    and when the final effort must be made, and when everyone is pushing
    hard to meet the deadline, who do you suppose is spending time polishing
    a resume and is out interviewing for the next job?
    
    You pay your money and take your choice -- or chance. What is the
    element of risk? Can Digital afford the risk? Be careful of what you 
    ask for, because you may get it. 

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

==============================================================================
       Re: -.36  

       It's good to see someone from IDC responding to this note.
       But I question your views:

              ... We will be retaining enough technical writers 
	      (a much smaller group) to handle the technical writing 
	      that is too strategically important or difficult to 
	      outsource.

        Sounds like the decision of what to outsource will be made in
        SES, another step away from where the understanding of what is
        "important" exists (the product team).

              ... Demmer and Strecker approved this "more than 
	      50% outsourcing of SES" plan.

        Could be a sincere attempt at a better organization. But sounds
        like someone telling the VP's, "I've got a plan. Save my job and
        cut these other people."

              We here in IDC are (and have been) getting very 
	      mixed messages about the value of in-house 
	      technical writing.

        You (IDC) have also been sending some very mixed messages about
        the value of technical writing in general. Many of the comments in 
	this string from engineering make a better case for the 
	contributions of technical writers than their own management.

              Hey, I shop at K-Mart for some things whose quality 
	      doesn't really matter that much to me.  Throw rugs, 
	      wastebaskets, stuff like that.  ;-)

        Are you saying that for some of our products "quality doesn't
        really matter." Is this based on sales?  Platform?  Customer
	base?  Your opinion?  PLEASE correct my understanding of what you
        are saying.  

              ... it's going to be a difficult managment job 
	      that a lot of managers won't want to do... .  I 
	      think you'd be happy to sign a contract with IDC/SES 
	      to have us manage that mess.

        If we agree that it's going to be a mess, can't we come up 
	with a plan that looks cleaner and more sensible?  If we 
	have to layoff more people,  why not just do it and not
	burden the company with another reorganization?

As a member of the SES management staff and a former member of the IDC management
staff, I've read all these replies with the intention of understanding  what the 
key issues are for engineers.  There are lots of opinions expressed in here. 
Some I agree with and some I disagree with, but I believe that this notesfile
exists to give people an opportunity to express those opinions so I don't intend
to debate any of the opinions.
 
However, I think lots of legitimate issues are raised. I also think that there 
are some misconceptions about what the actual plans are.  The details of the 
plans are being worked out, so more specific information can be provided very
soon.
But for the moment, I want to make sure I understand what the issues are so that
they can be brought back to the SES staff and the teams working on the plans can
continue to address them.

The issues are:
 - Cost
 - Quality
 - What makes a better doc process - integration w/ a development or not
 - Offsite/Onsite vendors
 - Control - Eng Project leaders? Functional management (Like IDC or ISE)? 
             Mktg Management
 - Benefits/Disadvantages of outsourcing as a strategy.   

I'm sure if I've missed any I'll read about them in follow-on notes.

Donna

        I work at the US CSC in Alpharetta, GA.  In-house or out-sourced
        writers would make no difference in documentation for the products
        I support.
        
        I believe, if we used out-sourced quality writers for our PC product
        lines, software & hardware, call volume would decline 25%.  There
        are good technical writers for PC products out there, Digital just
        doesn't know where to find them.
        
        A better point is that most engineering groups are responsible for
        documentation Q/A.  As long as the engineering groups are in
        charge of the QAR and SPR processes, nothing will change unless
        they are held responsible.  Maybe not allowing a product to ship
        with more than 25 reported and unresolved documentation problems.
        
        Digital should examine existing documentation (ours and others)
        and hire whomever is responsible for the best quality.
        
        Dave Zaniewski
        
        (who is in the process of rejecting over 50 SPR responses regarding
        documentation errors submitted at least 3 versions or more back, that
        have not been corrected)

    I must make a few comments focused on documentation quality.
    
    Quality can usefully be defined as conforming to the requirements of
    your customers, your clients, and your professional standards. 
    Customers are, in this context, the end users of our information
    products -- the paying customers.  Clients are the people who pay the
    bills -- Engineering, Marketing, and other groups.  Our professional
    standards include things like using the right paper weight (which
    customers and clients don't notice much, but we do).
    
    Now, I've seen comments that the IDC outsourcing plan will satisfy
    customers.  
    
                Has any Digital customer asked us to do this?  What
    customer critical success factors does this plan address?
    
                                                               It really
    bothers me that anyone invokes customer requests to rationalize this
    maneuver, because it seems a transparent lie.
    
    Will it satisfy clients?  It is said this plan will produce the same or
    better quality for a lower price.  I don't think anyone's had the nerve
    to ask yet, but judging from the remarks in this conference, I don't
    think the clients sound satisfied; and I don't think Engineering asked
    to be rid of us.  In a bull (or maybe a bitching) session, it was
    pointed out that the only way this model could work is if Engineering
    treated off-site contract writers with rigid specificity -- for that's
    what a contract is.  The current state of affairs was illustrated by a
    colleague of mine who was asked "to add TCP/IP to the Domain Gateway." 
    That was the whole spec!  Now, he could do it, because he's good and
    because he's very familiar with the existing documentation and the
    technology.  But if you want a vended writer to do it, someone will
    have to sit down and pass along marked-up pages.  Who will do that prep
    work?  Clients.  Actually, it's good for engineers to specify precisely
    what they want, but it's going to be a sea change for Digital engineers
    to actually 
    
    	         *write everything down in specifications before starting.* 
    
    That's what you'll have to do, or else you're going to be very
    surprised and unhappy with what you get back -- and you'll have to pay
    extra to get it fixed.  Again, client satisfaction sounds like a
    rationalization.
    
    When I started with this company, I recognized that in documentation
    Digital had a core competency: that is, documentation was key to the
    success of Digital products, and Digital's documentation was as good as
    anybody's.  We've come a long way from that time to the present state.
    Will it satisfy our own professional standards to be called expendable
    commodities, like the people who clean the toilets and mow the lawns?
    
    No.  
    
         At any rate, our own standards will be replaced by the standards
    of others.  They might be better standards; they might not.  I do know
    we spent many years building this team, like a poker player drawing a
    hand, and now we're getting a new deal.  I don't like the odds.

    User documentation production is just as much (or as little) a core
    competency as programming is. Both skils are _writing_ skills.
    Both need to achieve exactly the same goals albeit to different
    audiences.
    The user documentalist must write a clear and complete story of product
    function understandable by end users.
    The programmer must write a clear and complete story of product
    function understandable by both the computer as colleague programmers.
    
    My experiences with outsourcing both programming and user documentation
    work are identical:
    
    * You can use external contractors for both types of work without
      problem.
    
    * There is a major drop in quality (and non-value add communication
      and coordination) if either type must work off-site. If the IDC
      model is to have some sort of on site coordinator acting as a
      communications channel to off-site writers then THIS IS ASKING
      FOR SERIOUS HEADACHES AND INEFFICIENCIES as well as a definite
      drop in quality. 
    
    * I have never seen an intervening management layer between 
      project manager and writer (or programmer for that matter) 
      adding value (but they have given me headaches).
    
    * A person who has the skill to judge/manage a software engineer
      generally has the skill to judge/manage a writer because many
      of the same skills are involved: ability to formulate, ability
      to abstract to essentials, ability to communicate and work as
      a team player.
    
    * If a project manager can hire his or her own resources directly
      (being either engineer or writer) then there is no "mess" to
      manage: look at the CV, look at some examples of the persons
      work, judge the persons character as a team player and if alll
      positive bring the person on board. 
    
     There simply is NO value add in having an intervening coordination
     layer between writers and the engineering team (in fact, there is a
     major negative value). _If_ this is the proposed model the sooner 
     it is dropped the better.
    
     re roelof
     

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------
    
Please reflect for a moment on the possible justification for what was
recently described here as a Draconian move (firing all the writers,
course developers, and artists because they have "commodity skills"):

                              $$$ Cost $$$

Also in this topic we've heard a complaint that is a recurring theme: DEC
tech writers cost a lot. This can be quantified: $59 per hour is the
going rate.

It does seem like a lot, when you think about that pay stub in your
pocket.  Well, for that price you don't just get a writer. The writer is
the tip of an iceberg (or the nose of the camel poking under your money
tent).

Here's what you get for $59 per hour:

       o You get the (writer or course developer, now called:) Information
         Provider or Resource
       o You get some of an editor's time
       o You get some of an artist's time
       o You get some time from a person who has the skills to get the
         book/article/sales brochure/marketing piece onto paper or onto a
         CDROM (the Production people)
       o You subsidize people who are doing Advance Development in the
         field of the delivery of information. (Bookreader is going away;
         what will we use next? World View; Multimedia; World Wide Web...)
       o You subsidize work on software (and information) usability
       o You contribute to the administrative and technical support
         structure for an 800-person organization
       o You subsidize the dogged continuation of an experimental
         organizational/cultural structure which (among other things)
         causes a "Business Coach" and a "Resource Coach" (50MB, 
         first level managers) to do what *one* Supervisor (50MB again)
         used to do, and has writers struggling with spreadsheets and
         financial forecasts
       o You subsidize articles written for submission to outside
         publications (such as Harvard Business Review), extolling the
         wonders of the IDC Organizational Experiment 
       o You subsidize the IDC Opportunity Packaging (or Information
         Packaging or whatever) Group, which literally travels around the
         world trying to sell IDC as an information delivery business for
         outside customers (someone please give us a balance sheet of
         this venture?)
       o You subsidize the IDC Organizational Excellence Group (someone
         please qualify - and quantify - the value added to delivered
         products?)
       o You subsidize special IDC-funded studies in Cultural Diversity
       o You subsidize world travel in the interest of
         internationalization (I18N) of our docs
       o You subsidize the liaison with the Stone Center
       o You subsidize training in Information Mapping - a technique
         which writers have been using (anyway) since before Runoff
         
That's what your $59 per hour pays for.

If you were going to cut non revenue-producing activities, where in this
list would you draw the line? Now look at the SES plan again.

What's wrong with this picture? 

You get what you pay for, Engineering. You have chosen to adopt a "hands
off" policy toward the machinations of IDC. As a result, you stand to
lose the knowledge pool and talent pool of the information people who
have been in your areas, on your projects, since Phase 0. But, you get to
continue to deal with the "Business Coaches" and "Leaders" (catchy
titles, eh?) -- those who "embraced" (their own word) the IDC experiment. 

Such a deal.

What if:

      *  We went back to pre-IDC�, pre-CUIP�, maybe even pre-CUP� days,
         and we eliminated the chaff (instead of the wheat, which the
         apparently private SES plan winnows), and kept those who
         directly provide services and value to your products? What if we
         had these folks report to Engineering at the highest Facility
         level?

      *  SES (IDC) laid off everyone who is not presently on a funded
         project, and vended the cut services that prove to be needed?

Now how much would that writer or course developer cost? A lot less than
$59 per hour.

If, for example, adoption of one of these suggestions dropped the
price to $40 per hour, and there are 300 actual writers and course
developers (out of the 700 +/- Resources in IDC):

  $19 (saved) * 2080 (work hours per year)* 300 (people) = $11,856,000 
 
... off Bill Strecker's engineering budget.

That's not chump change.

Your milage may vary: we might have fewer actual contributors, and the
hourly reduction might be considerably more (which is likely).

Do you still think "hands off" is in Digital's best interest?

I have a pig in this here poke. Want to buy it? One of your neighbors
bought two. {It's the current trend. It's PeeCee.} Don't mess with
opening the poke. I'll save you time, and keep your hands clean. Trust
me. Sign here.

------------------------------------------
� - Information Design and Consulting
� - Corporate User Information Products
� - Corporate User Publications
    

I have waded through all the replies in this note, and it seems to me
that contributors have not realised that not all writing groups in
Digital are part of IDC.

Here in Reading, there is a group of writers (nine in all) who are
emplyoed directly by an Engineering group.  Some of us have been part
of this group for 10 years.  We have witnessed the rise of T&N Pubs,
CUP (later CUIP), and later still IDC.  We have witnessed the demise
of T&N Pubs, and, it seems, we are soon to witness the demise of IDC.

Writers are fully integrated into the engineering group and are
involved in a project from the beginning.  Hopefully, we have not
lost our ability to look at things from a user's or manager's view,
but we are sufficiently immersed in the project to liaise
knowledgeably with the engineers.

The writing team leaders (of which there are three, and who still do
full-time writing) report directly to the project managers.  We
adopted this model over four years ago when our Publications Manager
left.

The project managers are as responsible for the documentation as they
are for the other aspects of the project (e.g. code development,
testing).  The writers are experts in their field and provide the
project manager with documentation-specific expertise.

As we are such a small group, we have to do a lot of the peripheral
work of producing documentation ourselves, e.g. artwork, editing,
submission to ESSB, even submitting SPDs.

Our relationship with the larger writing groups in the past has been
cooperative.  Some of our writers have contributed to the T&N Pubs
IPA (Information Presentation Architecture) task forces, and we have
experimented with including help in the DSSR registry, and volunteered
to be a pilot for the forthcoming WorldView implementation.

We have also benefited greatly by the tools that have been developed
and the processes that have been put in place by these groups, e.g.
specific doctypes for DOCUMENT, the EDMS submission process. 
However, as mentioned in .40, DOCUMENT is no longer the only text
processing tool we can use, and the Software Supply Business groups
(particularly ESSB) have become so flexible that we can submit any
form of PostScript to them for manufacture.  This, therefore, means we
are not so reliant on the tools and processes developed by the larger
writing organisations, and can experiment with easier to use tools.

We are just one case of a small group of writers who are attempting
to produce quality documentation with the minimum of overheads.  I'm
sure there are others dotted around the company.

    Gill.

    RE: .47  by ANON::YMOUS
    
    >If, for example, adoption of one of these suggestions dropped the price
    >to $40 per hour, and there are 300 actual writers and course developers
    >(out of the 700 +/- Resources in IDC):
    
    As cynical as I may be about IDC's management structure, I find it hard
    to believe that 57% of the work force are in overhead functions.
    

    As cynical as *I* can be (and I've been burned before by precisely the
    "they stay, we go" scenario the most cynical among us have predicted),
    I must point out that the "camel" in reply .47 is not so big as you
    might think.  
    
    $59/hour for IDC can be compared to the mercenary wage of $40/hour some
    contractors can get in our specialty.  Add to that the costs of
    managing and equipping contractors (whoever does it, it gets paid for)
    and you see the gap shrink.  Throw in office space (so far, the
    alternative of off-site writers seems fraught with catastrophe) and
    that gap closes rapidly.
    
    The departed Telecommunications & Networks Publications was a very lean
    and mean organization, with a much higher ratio of workers to overhead
    people than IDC, but it also spent money on training, travel, capital,
    systems support, Valuing Diversity, honoraria, some modest advanced
    development, and other line items.  The base T&N rate was roughly 15%
    less than the IDC rate.
    
    For an organization of permanent employees, on whom you must spend
    money for benefits, training, office space, equipment, etc., you're not
    going to realize massive cost savings no matter what model you use.
    
    (For a collection of contractors, the jury is still out, but clients
    such as engineering and marketing will have to pay constant attention
    to shopping around to keep the costs down, much as homeowners who act
    as their own building contractors.  Or they'll have to come to IDC for
    project management.  Or they'll go with an outside vendor for
    everything, at which point I submit that costs will probably increase
    even as quality declines further.  But we shall see, won't we?)

>    The departed Telecommunications & Networks Publications was a very lean
>    and mean organization, with a much higher ratio of workers to overhead
>    people than IDC, but it also spent money on training, travel, capital,

As an aside, is this the organization that produced the documentation for
the 9600 modem that DEC sells? All three volumes?

Quick rat hole:

>>As an aside, is this the organization that produced the documentation for
>>the 9600 modem that DEC sells? All three volumes?

If they are, and they are gone - I'm very happy.  That documentation is the
worst I have ever seen in terms of format, orginzation or ease of use.  Go
ahead, I dare ya, give the books to someone and ask them to find the section
that describes how to change from AT mode to DMCL mode.

bjm

    What's the address on the Reader Remarks Form?

>    What's the address on the Reader Remarks Form?

                      Digital Equipment Corporation
                            Continental Blvd.
                           Merrimack, NH 03054

Attn:  Documentation Services

    Not us, mon.

As a matter of interest, what is the hourly cost of an engineer, and where
did those figures come from anyway?

re .55

I dont think it was IDC, DCD, or CU(I)P that created the 9660 - modem
doc set. The copyright page says: This document was produced by
Computer Special Systems Services in Merrimack, NH. 

>              Hey, I shop at K-Mart for some things whose quality 
>	      doesn't really matter that much to me.  Throw rugs, 
>	      wastebaskets, stuff like that.  ;-)

Yeah, so do I.  I also had a 2.6 liter Mitsubishi engine in my previous car.
the 2.2 and the 2.5 didn't have problems.  The 2.6 did.  I didn't know this
until after I bought my previous car; I didn't bother to find out, either.
A car is a car and a engine is an engine.  Surprise.

Many years ago I bought a microwave oven with a dial for setting the time.
At the time, I didn't think I could afford the extra $30 to go to the 
push-button, multi-setting model.  I regretted that purchase almost from
the day I bought it.  It did the job, and we used it for years.  After all,
a microwave is a microwave and it makes cold food hot.

People make cheaper things because there is a market demand for it, because
people have just enough money to buy whatever and they want it.  I can
write a book with bare bones in it and print it in shrink-wrapped three-hole
punch.  But as has been said, you'll get what you pay for, and sometimes less
(as in the case of my former car).

I object to the K-Mart characterization, though, when what we've been talking
about is over half (51-99%) of the writing people in IDC.  Perhaps up to half 
of the information Digital delivers is information where "quality doesn't
really matter."  Remember when "Made in xxxxx" was synonymous with cheap 
junk?  But by golly it was affordable.

I asked these three questions inthe IDC notes conference, too:

(1) Who defined the core competencies?

(2) How were these determined to be core?

(3) Who benefits by the definition?

While the numbers in .47 may not be completely accurate, I share some of the
concern over what has gone into the $59/hour for documentation and what in
the list of overhead (and who contributes to it) could be trimmed to bring
down the $59/hour without causing a hiccup to the value documentation brings
to the product.  And I also agree with .28 - go ahead and fire non-producers
which are the "bigger problem that exists in Digital."  Examine the overhead
for fat (*some* overhead is necessary) and trim the dead weight and you'll
see that $59/hour come down and retain your valuable assets.

We're not downsizing because of product - we're downsizing because of cost
per employee ratio.  Bring the cost down, improve the ratio.  Recklessly
maintain unnecessary overhead while outsourcing supposed comodity skills,
and you won't see the ratio change.  Instead, you'll see the downward
spiral where people bleed the company to death and then hop to another host
company and perpetuate the cycle.

Mark

I don't know where the $59 per writer number comes from, but we were told
to budget $144K per writer for FY95.  This includes some support functions 
(artwork/editing/production).

This is more like $72/hour per writer.

    The breakdown for the $59 may not be entirely accurate.  Editors and
    graphics artists do not usually come free with a writer and will also
    charge the project $59 for their time. Overhead is included in that
    $59, however.
    
    Back when I was doing some benchmarking for what was then called
    CUP/MKO, which was an internal consulting group which used the model
    IDC now uses, writing was about 70 to 75% of the cost of documentation.
    Since our rate at that time about $42/hr., a bundled rate (writer,
    editor, production, art, etc.) was more like $55-60/hr. 
    
    If my ratio still holds true today, the real hourly documentation rate
    is more like the $72/hr. (and more) noted in the previous note.   A
    simple formula could be to take the cost of a writer and add another 
    30% on top of that to estimate the total documentation costs. What
    typically started to happen as budgets tightened was that customers
    would decline the use of editors and ask us to minimize graphics - in
    other words trade off quality for quantity.  I imagine engineering was
    forced to make the same choices too.  What I never saw happen was a 
    serious discussion of other ways of bringing down the cost of producing
    information.  That has started to happen recently (reuse, new tools,
    etc.), but, alas, it may be too late - success will belong to the
    efficient.  High documentation quality at low cost will be the "new 
    paradigm" at Digital - as a stockholder, I can appreciate that.
    

    Where to start?  There's some interesting theory going on here!
    
    .38:  Bill, the main reason you haven't "heard" about editors is that
    writers have been doing the writing in this conference!  Technical
    editors do not only "rely on well established language and style rules 
    and little or not at all on technical expertise."  That's one of the
    reasons we had to go to a centralized structure in the first place: 
    engineers who said, "Hey, we don't need to edit books.  Just write
    them!"  Yes, editors have been very hard hit already, and will continue
    to be hard hit in IDC.  Primarily because of ignorance about the value
    of editing, which includes technical content, testing of sample
    programs, design of documentation sets, creative consultations with
    designers/illustrators, knowledge of Digital-imposed standards, format
    expertise (all those comments about how the writers don't have to use
    those nasty Digital authoring tools and can now use "industry standard"
    tools make the editors job all the more critical:  "Sorry, writer,
    you're off by 12 picas - you're text is outside the image area and the
    customer won't see it.  Should have used the approved templates!"), and
    indexing (which most haven't been allowed to do in years, because
    engineering doesn't want to pay for editors - we have some of the worst
    indexes going because of this!).  (In case you can't tell, I was an
    editor in the past!)
    
    Engineers are willing to hire the writers directly into their
    organizations (of course your management may have a totally different
    attitude with massive restructuring going on at Digital).  But what
    about editors, graphic designers/illustrators, & publication specialists
    (who know how to get products through the SSB and are experts in
    file-to-film and file-to-plate requirements from the documentation
    standpoint)?
    
    .40:
    
    Leo, I understand your point about "will writers be willing to come
    back and work here as contractors if they have to to through SES," but
    your contention that the SSB process is no longer something to worry
    about is 100% incorrect.  As I said to Bill, writers' use of "industry
    standard" tools makes the editors' jobs much more critical, and ditto
    the publication specialists (i.e., "production").  The processes are
    more critical now, because the SSB has very finely tuned their
    requirements.  Want high-quality documentation (visually, at least) at
    1200 dpi and simultaneous worldwide delivery of files?   Better not use
    Quark Xpress or PageMaker, then.  The SSB's EDMS tools do not currently
    support them.  Want to use color in documents created with
    Interleaf/SGML, Word Perfect, or MS-WORD?  Sorry, not and have a
    file-to-film submission.  That means 300 or 600 dpi goes to the paying
    customer.  Does the SSB have a mechanism by which it charges customers
    getting lesser quality docs less money?  I don't think so!
    
    .44:
    
    Dave, your comment about PC documentation is interesting, because much
    of the PC documentation is already outsourced.  I wish I knew which
    product you were referring to.  IDC does some PC documentation, but
    much of the PC hardware docs are done by another group that oursources,
    using a very similar model to the one being proposed by SES, but which
    has one person performing all the "management" functions defined in the
    SES core competency list.  (I don't mean that they have only one
    person, but vendor management, project management, resource management,
    etc. are all done by one account/business manager.)
    
    .48:
    
    Gill, I'm curious about your contention that the SSBs will take "any
    form of PostScript" for manufacture, because this is definitely not
    true in the U.S.  I had a long talk with Jae Kim just today.  It *must*
    be Adobe Standard PostScript, using the correct PC printer drivers and
    settings, and all graphics must be *encapsulated* PostScript, not just
    PostScript.  Is the ESSB different from USSSB?  Maybe you just happen
    to be using tools that create Adobe Standard PostScript.  Yes, the SSB
    is definitely more flexible than in the past.  But there are still very
    stringent standards and very specific criteria.
    
    You are correct that IDC is not the only group writing documentation
    and courses - there are *many* groups such as yours all around the
    company.
    
    .59:
    
    Jean, you were told told to use $72/hour, because (contrary to what was
    stated in the anonymous entry about services being included in the
    $59/hour rate) you pay separately for graphics, editing, and publishing
    support.  Each of those is billed at $59/hour, along with writing.  But
    they don't usually require as much time as writing (I say "usually" only
    because there are always exceptions!).  Someone within your own
    organization most likely figured out the "loaded" cost of a writer
    adding in those services rather than telling you to plan for 100% of a
    writer's time, 25% of an editor's time, 25% of an illustrators time,
    and 12% of a publishing specialist's time.  (Those figures were made
    up; that is not to be construed as a formula of any kind!)  It's easier
    for you that way.
    
    This is not a cut and dried "well we'll just hire the writers into
    engineering" situation.  It is much more complex than that.  I would
    very much like to see engineers and engineering managers respond to
    Donna Tramantozzi - here or off-line.  Concerns need to be addressed. 
    SES must be concerned with customer satisfaction first, immediately
    followed by client satisfaction.  This has rarely been the case with
    IDC (or CUIP/CUP before it).  Client satisfaction came first, whether
    or not the customer's needs were being met.  And in many cases,
    engineering managers are not a good judge of their customers' needs in
    documentation - that's why you hired us in the first place!
    
    I have lots more to say, but this is already way too long!
    
    
    Susan

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ----------------------------------------------------------------------
    
    Here's the basic premise of the "outsourcing" plan.  Get rid of
    anyone doing any actual work, keep the managers, and farm the work
    out to some 3rd party writing firm to pin the blame on when the
    fiasco implodes.

    Hmm, but won't engineering want to hire the writers directly, or
    hire them directly as contractors?  Engineering will not be
    allowed to hire writers in to their groups or to hire contractors
    directly. Engineering will be *forced* to use SES Management.

    Yes, that really is the stated SES plan!

    Did IDC/SES bother to ask engineering managers if they want this? 
    After all, they are actually paying for the documentation. 
    No.  At least not until this notes topic popped up. 8-)

    >Hmm, but won't engineering want to hire the writers directly, or
    >hire them directly as contractors?  Engineering will not be
    >allowed to hire writers in to their groups or to hire contractors
    >directly. Engineering will be *forced* to use SES Management.

    Sigh.
    
    I'd like to see how well they (SES) will be able to shove that down
    engineering management's throat -- especially in those groups that are
    perceived to be highly strategic to the Corporation's future.  I work
    in one - PATHWORKS products.  Next to OS and base networking, our stuff
    is what every other strategic software product in the company is
    depenedent on.  Lots of people buy Digital iron just to run PATHWORKS
    server products.
    
    I bet that whenever the day of the long knives hits the doc group
    attached to us, our management will find a way to "do the right thing"
    and quietly hire back/contract the people that have worked on our
    products for years.  Especially if the alternative is a potentially
    disaterous slip in product delivery dates due to unfinished
    documentation.  If our stuff slips, it will be just like watching
    dominoes fall.
    
    At least I _HOPE_ that's what will happen.  If it doesn't, it 'll just
    be "another brick in the wall" -- the one Digital is building between
    itself and profitability.
    
    John
    

>>Engineering will be *forced* to use SES Management.

I still don't understand this notion of "force". By what means
is anyone "forced" to use any service that they consider contrary
to their requirements? If this "force" really exists, how is it
that "there are many groups like ours" in the corporation who cannot
sense it? Sounds like dark matter theory to me.

As it has been explained in the IDC/SES reorg meetings, Engineering will be
under the similarly headcount restraints as IDC/SES. As a result, Engineering
will not be able to hire writers, editors, and others because they will not
be able to increase their headcounts. We can translate that into "Engineering
will be forced to use the new IDC/SES model of outsourcing" or not, but the
effect is the same. 

In addition, we can certainly expect to see an increase in the number of
outsourced engineering projects. In those cases, it's likely that all of
the development work will be shipped to an outside vendor, with only the
specification, coordination, and final submission work remaining inside
Digital. Stay tuned. It's going to get very interesting.

~/karl

> with only the
> specification, coordination, and final submission work remaining inside
> Digital.

So that means these are perceived "core competencies" that we should be
retaining?  (Something seems "a little broken" when we've had such problems
with global strategy, and have been relying on "bottom up" determination
and innovation - and now we're saying that we're going to farm out the
bottom...  You can pay a 3rd party to meet a spec.  It's a lot less clear
that you will get ANYTHING other than stuff that meets the spec - like
observations about what should really be getting done, re-use across
projects to reduce cost, reduced communication overhead to reduce costs,
etc.)  Seems a little backwards...

    This started out as a specific reply to .66's remark that the company
    wouldn't get anything beyond the spec, but the issue seems more general
    than that. 
    
    You don't succeed in documentation consulting by sticking to the spec
    and charging for every ten minutes of your time.  You succeed by caring
    about your products -- for the length of your contract that product is
    yours as much as if you'd worked with the company for 20 years.  You
    succeed by adding value to the product.  
    
    I haven't been at this for very long, and wouldn't want to present
    myself as an expert here, but maybe explaining some of the procedures
    will help people understand some of the issues.  
    
    Digital is the only company that has contracted for my services by the
    hour.  All the other jobs I did were on a per-job basis.  $500 to write
    a ten-page technical sales brochure, $2500 to edit an installation
    guide and test it against the software, that sort of thing.  It's not
    clear to me whether SES wants to continue the per-hour hiring, or if
    it's going to a completed-project basis.  
    
    In the jobs I've bid for, the usual procedure has been that after I get
    a lead on a project, I go talk to the company involved and get as much
    information as I can.  This is usually with the group that wants the
    writing.  I prepare a proposal that argues for the value I can add to
    their product.  Often, the proposal stage is competitive; the company
    is looking at more than proposal.  I have found that most engineers
    want the quality of a $50-an-hour expert from a $25-an-hour college
    intern.  When push comes to shove, they frequently prefer the cheaper,
    lower-quality manual.  
    
    If the company wants you, it usually comes back with a counterproposal. 
    Next, negotiation, usually with the finance people.  Engineering and
    marketing also participate, especially when there's a question of
    cutting back on what's required.  When everybody's happy and I get the
    contract and nondisclosure signed, I do the work I contracted for, and
    if it takes longer than I planned, I eat the difference.  (The contract
    lists the kinds of things the company will have to pay extra for.)  
    
    I presume that SES is talking about taking over responsibility for the
    middle step -- the negotiations.  This is typical of how other
    companies that use outsourced documentation work.  Some of the
    information we've seen makes it seem like SES plans to handle the first
    part, too, and then just go find somebody who can implement it.  I
    suspect that won't work.  The writing consultant(s) making the proposal
    just won't have enough information about the kind of work that's
    involved.  
    
    I'm a one-person operation right now, so I can't offer a complete
    package including production.  Many consultants can, usually through
    subcontract.  And at the high end, there are companies that offer
    complete service, some in-house and some outsourced yet another level. 
    (For instance, nearly all printing is outsourced.  Digital's been doing
    that for years.) 
    
    --bonnie

    I can't resist replying here.  People seem to be panicking.  I think
    this is because the writing community of IDC thought they'd be the last
    to go, and that all the editors, illustrators, and publications
    specialists would go first.  Now they're shocked!  That's just my opinion, 
    though!
    
    After the last TFSO, we had 748 people in IDC.  If we downsize by 50%
    (which is the approximate number for all of SES - IDC's number could be
    higher for all we know), we'll be down to 374 people.  IDC had 85
    people in management - that number is lower now, due to attrition and
    downsizing, but I don't know what the number is.  That means that
    almost 300 people will still be employed here *if* all the management
    types keep their jobs.  As an editor mentioned in another note, there are 
    "hints" that many of those who remain will be instructional designers.  I 
    wonder if we have 300 of them, though?
    
    As Karl said, it's going to be interesting to see what happens next.
    
    I'd very much like to hear from other contractors like Bonnie and get
    their perspective.  Her insights were very helpful.  I'd also love to
    hear from folks in the PCBU, who have been outsourcing most of the
    documentation for some time.
    
    
    Susan
    

    This note was posted in the IDC conference.  Sue Gault gave me
    permission to cross-post it here in this conference.  --Susan
    
                  <<< VAXUUM::W7_:[NOTES$LIBRARY]IDC.NOTE;3 >>>
                                    -< IDC >-
================================================================================
Note 263.15               SES Future State Information                  15 of 15
DONVAN::GAULT                                        46 lines  12-JUL-1994 10:38
                                -< Outsourcing >-
--------------------------------------------------------------------------------
I'd like to address a misunderstanding expressed in this stream of notes 
as I interpret them.  SES is planning to out source work, not bring in 
contractors.  What this means is that we (information designers, 
technical experts, project managers, etc. in SES) will work with our 
clients to agree on the deliverables that we want a vendor to produce 
for us.  That is, the design and management of deliverables stay 
within SES and Digital, and the implementation of the design happens 
at the vendors.

As many of you have pointed out, the implementation of the design 
requires information skills,  technical knowledge, and interpersonal 
skills.   This has implications for the type of relationship SES has with 
its vendors.  In particular, we will have a close, long-term 
partnership with a limited number of vendors.  We know that 
writers are not interchangeable.  Partnerships are key.

Finally, some food for thought:  Some of you have already said to me 
that you see an opportunity in working for the vendor.  I agree that 
that opportunity exists.  I also think that vendors have to make 
investments to stay in business that we in Digital have trouble 
making.  PCs are a good case in point.  We know we need them to do 
our work and yet have difficulty obtaining a large enough capital 
budget to get a sufficient number.  

I am not saying that the transition to outsourcing will be easy.  I 
understand that it is a difficult change for many of us.  Nor am I 
saying that working for a vendor is going to be utopia.  I do believe, 
however, that a vendor's business is the creation of quality 
information and that fact will drive the vendor to make investment 
and keep up with technology in a way that will allow people working 
for the vendor to keep current with developments in the industry.

IDC has always been very cost driven by our clients and in some 
ways this is an advantage.  It has driven us to reduce our 
management structure and overhead to where we run more lean 
than most (if not all) of the Corporation.  The result has been that we 
reduced our hourly rate  by approximately 10% from FY93 to FY94.  
Our rate was $59 for FY94 and we plan to stay at that rate for FY95.
In other ways, being too cost driven hampers our investing in 
ourselves.

Today, many businesses are outsourcing work so that they can focus 
on what is core to them.  If you are interested in reading more about 
this, I recommend "The Age of Unreason" by Charles Handy.

Regards, Sue
                                                                 

    
    In response to some of what Sue Gault has to say in the previous note,
    I am posting a note that appeared before hers in the IDC notesfile.
    
    Ruth-Ellen
    
    
                  <<< VAXUUM::W7_:[NOTES$LIBRARY]IDC.NOTE;3 >>>
                                    -< IDC >-
================================================================================
Note 263.12               SES Future State Information                  12 of 13
NURSE::FLANAGAN "Not Fade Away"                      44 lines  11-JUL-1994 13:18
                           -< Can you say cheaper? >-
--------------------------------------------------------------------------------
    
    
        <<< Note 263.8 by DBLDOG::DONHAM "Progress Through Tradition" >>>
    
>>>Overall I think it makes a lot of sense to use contract writers for what we
>>>currently do in-house, and I think that the argument about needing in-house
>>>writers because they have special knowledge of a particular product is a
>>>bunch of bunk. Any good agency is going to be able to provide writers with
>>>a solid technical base, and those that don't have that are'nt going to be
>>>working. It's a great weeding-out process.
>>>
>>>Perry
    
    This is just not true. 
    
    First, no matter how good a technical base you might have - it is still 
    not equal to my 8 years experience working on DSM or someone elses 5 
    years working on PATHWORKS, for examples.
    
    Second, according to a recruiter I spoke to - contractors need to 
    specialize (for example, networks). If they don't start out
    specializing, I bet a good number tend to work in the same areas.
    
    And then what about those contractors who end up working at the same
    place for years? 
    
    Third, at the STC Annual meeting I sat in on a session called "Industry
    Demands Industry Knowledge". The slant was towards Technical Writing 
    Programs and what do they need to teach their students. One of the 
    presentors (who works for a placement agency in Texas) stated that he 
    placed some writers at Exxon and Exxon didn't want them because they knew 
    nothing about the oil industry.
    
    
    ******************************
    
    I find it totally unethical to lay off people and hire them or others 
    back as contractors. The bottom line is COST... MONEY is the reason. 
    They aren't doing this for any other reason. I find it also unethical to
    build a manufacturing plant in Malaysia and close plants like Phoenix
    and Puerto Rico and Roxbury etc etc (And reducing headcount as someone
    else pointed out).
    
    They say ISE did it - well this is not Europe... we don't have benefits 
    guaranteed - also we aren't doing the same kind of job.

    
    
    
    The thing about a capitalistic society is that there are no guarantees. 
    As with your header note regarding healthcare, we have to decide what
    type of a society in which we want to reside.
    
    
    Mike

This is apparently what's going to happen:

 From Sue Gault (head of IDC) in .69:

>I'd like to address a misunderstanding expressed in this stream of notes
>as I interpret them. SES is planning to out source work, not bring in
>contractors.....

>the design and management of deliverables stay within SES and Digital, 
>and the implementation of the design happens at the vendors.

The way I interpret her reply is as follows:

You need some documentation written as part of your product. You contact 
SES, who assigns "information designers, technical experts, project 
managers," etc. to "agree on the deliverables". The documentation is then 
designed (and managed) by someone in SES. After the design is ready, it is 
"implemented" by a contractor working for one of a handful of approved 
vendors. The contractor works offsite, doing what amounts to data entry.

Do you like this model?

Mike

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

=============================================================================

The purpose of outsourcing is to save money. There's no point to doing it
otherwise. Companies typically outsource truly commodity services;
the examples most often cited by the management literature are
facilities, landscape services, janitorial services, cafeteria
management and the like.  There are, however, examples of 
outsourcing "intellectual-property workers". 3M, Xerox, Honeywell, 
and to a lesser degree, HP have all outsourced facets of both
documentation and course development. Digital has been using
contract instructors for quite awhile (quasi-outsourcing). GM, Ford,
etc. have outsourced design services for autos and parts of autos.

So, to me, the question isn't whether it can be done (it can). The
question is whether it saves money. My advice is that if you can 
answer that question in the affirmative (and back it up with the 
requisite financial analysis, then by all means, go for it.)  I 
have been thinking about the financial piece, however. So let's 
do some back of the envelope calculations, (using some assumptions).

Assumptions
===========

Contract people in the computer industry need to make a middle-class
wage. Otherwise, they will migrate to other occupations (econ.101).
My estimation is that a consultant/contract writer basically needs
to get between 40-45/hour. They'll need to pay health insurance
(500-900/mo), disability, life insurance, Keogh plan, invest
in equipment, on-going training, pay for downtime and marketing,
etc. plus pay the normal middle-class bills. There are special 
cases where spouses can pick up some of the costs (e.g., medical
benefits), where the consultant/contractor has already retired
from somewhere else, etc., but for the most part, I think my
number is close.

Additionally, there will be a need for the vendor to integrate
into Digital processes and deliver to requirements like SSB's --
that means having the right software, etc. Also, there is a
need for office space, telecommuncations capability, travel/expense
coverage, and so on.

N.B: all these costs *must* be borne by someone. Either the writer,
the outsource vendor, or Digital. 

Now, you can without doubt get people cheaper. The question is,
will they be serious? If you starve them, they'll bail at the first
opportunity (some will do that anyway), leaving you with an interruption
of service.

So, if I've made my case for the 40-45/hour, let's progress a
bit further. To that charge, you need to add a 25-30% markup 
of cost by the outsource vendor (they need to add profit,
unemployment insurance, *their* overhead for office staff,
telemarketing, etc.). Using the lower end of my figures, you're now up to 
$50.00/hour. Cool. Engineering clients have now saved about $9.00/hour. 
But wait! You need to add the overhead costs associated with SES 
management. If SES plans on keeping 50% of it's staff to spec
stuff out, then you need to add another markup to the $50.00/hour.
How much will that be?

Based upon my salary current salary (which is at the high end
for technical writers), and the rate SES/IDC charges me out
at, I think I can conservatively say that IDC's *current* overhead
rate is about 33%. It'll be higher for lower paid writers. I think
that'll remain *at least* constant, because the people who remain
will be performing almost totally "overhead" functions (i.e., they'll
be planners, not implementers).

So, now you can add 33% to the 50.00/hour for a grand total of 
66.50/hour. The current charge is 59.00/hour. If IDC/SES cuts
their overhead by 50%, a good, experienced writer who is serious
about long term contracting will cost about 58.00/hour, or 1.00/hr
less than they do now.

So, someone please tell me about how this saves money. Better
question: does it save enough money to justify it?

Now, here's the other fly in the ointment: when DCD and CUIP merged,
there were about 1100 people in the new group. And that was after
DCD, at least, had already downsized twice (I think). We are now
at 700-and change. That means that there has been, conservatively,
a 33% downsizing/attrit already. If we did it right (haha), we've
already picked the low-hanging fruit. Those left are the best and the
brightest (and I dare say as good a group of 700+ writer/dev/editors/
production folks as you'll find outside -- check out the list
of awards sometime). What I'm saying is that you've already got as
good as you'll get in most cases. 

So my prediction is that in addition to *not* saving an appreciable 
amount of money, you'll also get no better, and quite probably worse
quality.

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------
    
    One wonders what IDC/SES is actually going to do with any feedback
    being collected here.  I  have been told in no uncertain terms
    that this plan is a "done deal" and Engineering has nothing  to
    say about it.  The schedule calls for it to be mostly implemented
    in Q2 and Q3 and for it to be  fully in place by the end of FY 95.

    I know the slides detailing this plan have been declared top
    secret.  If IDC/SES *really* wants  feedback from the Engineering
    community, why don't they post these slides here?

    Last year IDC management reorganized their group to get rid of 
    managers and supervisors.   They became "Leaders" and "Coaches"
    instead.  This "Self Managed Team" approach implied  that it was
    the "empowered workers" who were important and the managers who
    could be  replaced.

    One year later and it's job functions with "Management" in the
    title that are critical to keep and  it's the "Self Managed"
    workers who are TFSO'd.

    Would you trust this gang to manage a critical piece of *your*
    product?
    

>>    One wonders what IDC/SES is actually going to do with any feedback
>>    being collected here.  I  have been told in no uncertain terms
>>    that this plan is a "done deal" and Engineering has nothing  to
>>    say about it.  The schedule calls for it to be mostly implemented
>>    in Q2 and Q3 and for it to be  fully in place by the end of FY 95.

IDC should wake up and realize that "engineering" is its "customer"
and ask us what we want to buy.  

Garry

    RE: .75  by FREBRD::POEGEL 
    
>>    One wonders what IDC/SES is actually going to do with any feedback
>>    being collected here.  I  have been told in no uncertain terms
>>    that this plan is a "done deal" and Engineering has nothing  to
>>    say about it.  The schedule calls for it to be mostly implemented
>>    in Q2 and Q3 and for it to be  fully in place by the end of FY 95.

>IDC should wake up and realize that "engineering" is its "customer"
>and ask us what we want to buy.  
    
    Is there any precedent for this?  I mean, when has Digital ever asked
    its customers what they wanted?
    

    Sorry, I deleted my original note and am reposting it...
    
    Re .36 from Gerry Fisher 
    
    >>>And, with some types of documentation (Product
    >>>X, in maintenance mode, Version 9, all hardcopy, techno-weenie-hacker
    >>>audience), lower quality might be okay.  We'll succeed in saving a lot
    >>>of money, and we'll get what we pay for.
    >>>Hey, I shop at K-Mart for some things whose quality doesn't really
    >>>matter that much to me.  Throw rugs, wastebaskets, stuff like that.
    >>>;-)                         
    >>>Finally, I know that we are trying to prevent this situation, but
    >>>there may be a project that vends out some not-so-important docs, uses
    >>>a contractor to write another book, and uses several inhouse writers
    >>>to do the HyperHelp.
    >>>I think you'd be happy to sign a contract with IDC/SES to have 
    us manage that mess.                                          
    
    Was he kidding - did one of our management really write this drivel?
    And maybe he thinks we should have rationed health care for old people 
    too :-) - you are over 70 and don't have a life anymore so forget about 
    that cataract operation. 
    
    **************************
    I think the anger from writers is coming from the fact that we are
    feeling devalued again. We had made strides to become part of the
    engineering team (I have been with the DSM group for 8 years). And to
    the engineers who have had different experiences with IDC - well I 
    am not sure why. Now we are being told that we can be outsourced. 
    Well, engineers - wake up cause you are being outsourced in a lot 
    of places too. 
    
    I am sure that none of the funders were asked by their senior managers
    what they thought about all of this. They aren't being asked now.
    
    *********************
    
    re.73 is right on....
    
    The going rate for contractors from some agencies for someone with 9
    years tech writing experience is $28-30 maybe $33.00. That is without
    the agency's markup. So, then figure $45.00. And that is for placing
    people in companies - no equipment etc.
    
    I am still trying to find out from someone the names of agencies who
    actually have the resources to do this kind of work - equipment, people
    who have powerful machines to work from home, money for licenses of
    software. 
    
    Most of the jobs out there right now are permanent jobs in small
    companies. It is the larger companies who are laying off and then
    hiring back contractors.
    
    I suspect that there must be something going on that we don't know
    about as to setting up people (the spinout, buyout)? 

    >>> I am still trying to find out from someone the names of agencies
    >>> who actually have the resources to do this kind of work - equipment,
    >>> people who have powerful machines to work from home, money for 
    >>> licenses of software. 
    
    This is going to be a problem with this scheme -- Digital uses a very
    narrow set of authoring tools, very few of which are commonly used in
    the rest of the world. 
    
    I own the equipment (hardware and software) to produce as large a
    technical manual as you want, and I can do it rather quickly.  I can
    deliver you camera-ready copy (I subcontract that, i.e. take it to
    AlphaGraphics downtown) or source files in most standard formats.  I
    can generate and include graphics.  If it's a PC product, I can run the
    software directly on my business machine; if it's not, I'd have to log
    into a vendor's test system -- but I've got the equipment for that,
    too.  I've got Internet access through a commercial provider.  I'm
    willing to invest in hardware and software for a particular contract.  
 
    But if I were to subcontract with whatever vendor Digital outsources
    to, I'd have to deliver a DOCUMENT file.  Does Document even run on a
    PC?  Even if it does, I doubt that I could afford it, and since Digital
    is the only company that can use it, I'm not sure it would be a good
    investment anyway.
    
    This means I'll be effectively shut out of working on Digital writing
    projects.  (Not that the prospect exactly breaks my heart, but I do
    enjoy working here and on Digital software products.)
    
    --bonnie

>    Last year IDC management reorganized their group to get rid of 
>    managers and supervisors.   They became "Leaders" and "Coaches"
>    instead.  This "Self Managed Team" approach implied  that it was
>    the "empowered workers" who were important and the managers who
>    could be  replaced.

I had almost forgotten this.  It *was* the stated purpose to develop
self-managed teams and empowered workers and phase out "coaches."

What happened?  Inquiring minds would like to know.

    You're right -- no shop out there has VAX DOCUMENT.  (Actually, one
    does, I'm told, but they're small.)  The data base of pages in DOCUMENT
    is an absolute prohibition against vending out updates.
    
    So you know the way around that? For portability alone (I mean from
    vendor to vendor), it would be much cheaper to create MAIL output and
    send the files to Bombay or Singapore or Bupapest and have them
    re-keyed into some other tool, probably Microsoft Word.  (It's true! 
    Check out the wages there.)  Then the files can be vended out.

    
    
    Naive spoiler>
    
    
    
    
    A $183 million loss?
    
    

>    You're right -- no shop out there has VAX DOCUMENT.
    
    Risking the wrath of Bonnie :^] I'm gonna have to differ.  My wife is
    a technical writer at a client site that uses VAX Document.  Also,
    Document is not used that much here in the US outside of military
    applications (automatically formats milspec guidelines for documents
    and I don't remember that option in WordPerfect, verdad?) and Digital
    BUT it is used heavily in less developed countries where labor costs
    are fairly low and PCs and workstations are cost-prohibitive.
    
    Is VAX document portable?  To an extent, in that you can generate many
    different types of output (it uses a standard ASCII file with embedded
    tags, like LaTex) for screen, help, line, laser, etc.  Development can
    be done on a PC then ported to a VAX for compilation.  This is usually
    done within LSEDIT for debugging purposes.  So, Bonnie, you can quit
    using this excuse to lounge around in that sexy lingerie eating
    bon-bons and GET TO WORK!  :^]
    
    I've always looked at Document, DecWrite, and PC-based systems as
    providing a full range of documentation products and would hate to see
    the loss of Document as it means many sites I've had to work at would
    be back to the use of RUNOFF (if you know what that is, you'll
    understand.  If you don't, congratulations). I had to use RUNOFF at one
    site too poor to even buy Document.  We here in the States often take
    our technology and toys for granted, I'm afraid.
    
    It's very easy to say "Old technology, unused, can it" without taking
    into account those Digital customers that would just die for a VT420
    and a laser printer and know there's no PC, workstation, etc. in their
    future.  I don't believe it costs us a pence to keep and maintain and
    it's still generating cash.  As to Digital using it...it is nice to
    dial in from a client site w/ their VTs or PCs and be able to read a
    file you're interested in, edit it for the customer, create a new PS
    version, and kermit it down for printing.  It also integrates fully with
    CMS, as does DecWrite, which makes it easy to track revisions and
    manage a large-scale documentation environment.
    
    Whew!  Most I've entered for a month.  Hope this is educational to
    someone (and not used as food for the lurking vipers).
    
    								Tex

>    Is there any precedent for this?  I mean, when has Digital ever asked
>    its customers what they wanted?

     The instruction set for the PDP-11 was a direct result of customer input.

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------

Going to contractors is one thing.  Going to contractors and then having the
corporation closing ALL purchase orders for outside vendors during the 
quarterly expense "saving face hysteria" will, in my opinion create havoc for
those employees who have to have something go out the door, whether it's
code, documentation, or proposals.  

Don't laugh, it happened to me this year and I then had to scramble for 
someone to help me out and eventually ended up doing most of the work myself,
at a cost of me not doing my primary job effectively.

When I asked my manager about this, he didn't seem so concerned about it.  But
then, he wasn't doing the work.

Just one more reason why my resume is out on the street.

    

    re: .84
    
    >    Is there any precedent for this?  I mean, when has Digital ever
    >	 asked its customers what they wanted?
    
    
    >>The instruction set for the PDP-11 was a direct result of customer
    >>input.
    
    
    yeha, and digital has probably never asked a customer for input since then.

I've seen direct requests for customer input many, many times.  And that
input is often acted on.   VMS, through the DECUS VAX SIG's SIR process,
polled customers twice a year for suggestions as to what they wanted to
see in VMS and to then rate the suggestions.  The top 10 vote-getters got
formal responses from VMS engineering and a significant portion of the
requests were implemented.

				Steve

    RE: VAX DOCUMENT
    
    Not all Digital documentation -- not even all of it created by IDC --
    is done with VAX DOCUMENT, and the use of other tools is increasing
    steadily.  So it is incorrect to characterize VAX DOCUMENT as a
    requirement for all, or even most, future Digital documentation jobs.
    
    VAX DOCUMENT runs only on OpenVMS VAX at this time.  The new owners,
    Touch Technology, have said they plan to port it to OpenVMS AXP, but I
    doubt it'll ever go farther, for technical reasons.  On the other hand,
    as indicated in previous notes, you can edit the source file on
    anything that has a text editor and copy those back to a VAX to run the
    formatter (which is what I understand the ISE translators do).
    
    This doesn't mean there is no problem, just that the problem is not
    universal, and will become less over time.
    
    -Mark

    re: .83
    
    Yes, Tex, I know Runoff.  I used to write Runoff-coded files using TV
    on a TOPS-20 system named YOYO.  I like Runoff better than Document. 
    You can at least get your processed file back in the length of time it
    takes to get a cup of coffee.  No, I do not do lingerie and bonbons. 
    Cowboy boots and beer, yes.  Bonbons don't go well with beer. 
    
    I think you slightly missed the point.   Yes, Document with CMS is a
    good combination for managing and tracking large-scale documentation
    projects.  But large scale means large systems, which means large
    budgets, which individual contractors don't generally have.  Which
    means Digital's only options for outsourcing would be companies big
    enough to afford a full-scale setup for running Document and CMS and so
    forth.   Only a handful of "we write for you" shops around here that
    meet those requirements -- and a handful may be an exaggeration.  
    
    Yes, lots lots of customers don't have nearly the equipment we take for
    granted and can't even aspire to the things many of us are teed off
    that we don't get.   Yes, customers, especially defense contractors,
    use Document.  We're not talking about either situation with the IDC
    outsourcing proposal.  It's not defense industry stuff, it's several
    hundred mostly very large conventional software manuals about things
    like LSEDIT and CMS and VMS and DECforms, all done in internal doc
    types that use several dozen specially defined tags (which I've been
    told there's nobody to  maintain anyway).  Many of them include
    extensive syntax diagrams written in an unsupported internal tool. 
    Graphics have to be generated and processed separately.  
    
    None of which is necessarily bad -- given the need for internal
    controls and tracking, the unweildiness is probably unavoidable.   It
    is going to make outsourcing very much more difficult than it might
    have been.  (The problems of an individual subcontractor downloading
    and uploading .SDML files to the vendor's system for processing
    probably is more of a nuisance than an insurmountable problem.)
    
    I'm especially curious about this, though:
    
    >>> As to Digital using it...it is nice to dial in from a client site
    >>> w/ their VTs or PCs and be able to read a file you're interested in,
    >>> edit it for the customer, create a new PS version, and kermit it down
    >>> for printing.  
    
    Are you talking about regular manuals here?  Because as far as I can
    tell the only thing covered by this outsourcing proposal are manuals
    and courses.  Specs and other things written by other groups -- STARS
    articles, for instance -- won't be affected. 
    
    --bonnie

.80>I had almost forgotten this.  It *was* the stated purpose to develop
.80>self-managed teams and empowered workers and phase out "coaches."
.80>
.80>What happened?  Inquiring minds would like to know.

    
.82>    Naive spoiler>
.82>        
.82>    A $183 million loss?

Spoil me some more, please.  I believe the implication is that the loss
is causing a change in the stated purpose.  is this what you mean?

Naive knave

    Oh, by the way -- the reason I had time to write such a long note is,
    I'm waiting for Document to finish processing the chapter I'm working
    on so I can check the alignment of the examples . . .
    
    --bonnie

    Anent .83: Tex, this is perhaps a rathole, perhaps an important
    question.  If there are lots of vendors out there that can accept
    DECwrite and DOCUMENT files, outsourcing becomes easier.  However,
    I believe that license for license, our proprietary tools are utterly
    blown away.  In fact, to an order of magnitude, ain't it like this...?
    
    		TOOL		  LICENSES
    		====		 =========
    		Word		 1,000,000
    		Interleaf	    10,000
    		DECwrite	     1,000
    		DOCUMENT	       100

    Anent .88: Mark, are you suggesting that we could vend DOCUMENT source
    files, take back the result, and process them ourselves?
    
    If so, that is possible in theory, but in practice flat-out won't work.
    It would be like asking a contract programmer to produce code without
    access to a compiler.  You'd need a production-support staff that would
    consume most of the slots IDC has left, and everything they do, in the
    language of Crosby Quality, would be scrap and rework -- a dead loss.

Re .81:

I have actually done this...

Years ago, I worked for another company that moved a big software project from
Boston to Melbourne. There were thirty large manuals, all prepared with
Honeywell's equivalent of DOCUMENT and coded for an obsolete typesetter. The
illustrations, thousands of them, had been prepared by contract artists using
Macintosh programs. Final versions of manuals were prepared by mechanical
paste-up.

The typesetter was sold for scrap, and there were no equivalent models available
in this country. 

Since all the diagrams were in Mac formats, I decided to move the whole lot to
Microsoft Word, Mac version. I prepared a style sheet that looked like the only
hard copy manual that we had. Preparing plain text versions of the files,
stripping out the codes and applying styles paragraph by paragraph kept three
typists busy for six months. The end result was not bad at all.

I know Digital has thousands of manuals, not just 30, and there are serious
labour-cost problems to consider. However, brute-force conversion of source
files in this way could be an option in some circumstances.

James

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------
    
re: 69

> I'd like to address a misunderstanding expressed in this stream of notes 
> as I interpret them.  SES is planning to out source work, not bring in 
> contractors.  

OK now its clear to everyone that tech writers will do their work outside the
Digital premises.  Engineering of course has *no* say in this arrangement
right?   Even though Engineering has consistently said that having
the writer onboard as part of the long-term team results in the best
documentation.  If you want something done, you wander over and talk
to the writer about it.  But we are going to satisfy our Engineering customer
by having the writer blindly working from the spec at some distant agency?  

> Today, many businesses are outsourcing work so that they can focus 
> on what is core to them.  If you are interested in reading more about 
> this, I recommend "The Age of Unreason" by Charles Handy.

Great, another case of management from the best-seller list.  Last year it was
Self Managed Teams.  This year it's Outsourcing.  What's next?   
                                                                 
    

    Of course, all the discussions of contracting, outsourcing, and so
    forth have assumed something reasonably local -- per process, per
    project, per site.  There's also the possibility that they're planning
    to farm the whole shebang out in big chunks to national service
    companies (EDS? Arthur Anderson?) -- just sign a contract for the other
    company to maintain all the documentation as well as the products.  
    
    In which case all this discussion is moot and all the writers are, as
    they say, SOOL.
    
    --bonnie

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

===============================================================================


                       FOR DIGITAL INTERNAL USE ONLY
  
 +---------------------------+
 |   |   |   |   |   |   |   | TM       INTEROFFICE MEMORANDUM
 | d | i | g | i | t | a | l |
 |   |   |   |   |   |   |   |
 +---------------------------+

 TO:   Bill Strecker                    DATE:  14 July 1994
       Bill Demmer			FROM:  A. Noter
       Sharon Keillor		        

 SUBJECT:  Reorganization of SES/IDC:  An Alternative Proposal (Plan B)
 
		The following proposal provides a less complicated
	and more practical process for providing documentation and 
	courses for Digital's customers than the current plan
	proposed by the IDC leadership.  Please consider the logical
	features of this plan and the potential advantages.


	Plan Features:

		o The current IDC leadership team (leaders and 
		  coaches) will contract with engineering and 
		  marketing to provide their expertise in vendor, 
		  resource, project, and account management.

		o All technical writers,  course developers, and 
		  supporting personnel will report directly to the 
		  engineering or marketing cost centers they currently 
		  work with.

		
	Plan Advantages:

		o Eliminate duplication of effort in the area of 
		  project management by merging documentation into 
		  the product teams.  Product teams can directly 
		  manage all the resources needed for their success 
		  and accountability.  This will also facilitate 
		  teamwork through team continuity.

		o Maximize the efficient use of capital equipment 
		  eliminating duplication of systems for separate 
		  Engineering and Information groups.

		o Streamline the current organization by creating a direct
		  link between engineering and documentation (eliminating 
		  current steps from Engineering to Business Coach to 
		  Resource Coach to contributor.)

		o Increase the flexibility of cost centers to improve their
		  efficiency by enabling them to create or subcontract 
		  as they best see fit to make use of the best people.

		o  Maintain productivity by avoiding a lengthy 
		   transitional period of reorganization and keep 
		   people focused on productive projects rather 
		   than on the learning of a new organization.

		o  Retain technical expertise and core writing skills 
		   within the company.

		o  Simplify any future down-sizing procedures.  With 
		   individuals assigned directly to cost centers,
		   down-sizing can be aligned directly with reductions in 
		   product investments.  Conversely,  this will
		   revitalize employees working on strategic projects.

		o  Enable the current IDC leadership to focus their 
		   valuable skills on their customers by removing the 
		   current burden of continually focusing on "process".

    There seems to be an assumption in this string that Engineering will
    continue to operate as usual. Is it worth challenging that assumption?
    
    Marty

>    There seems to be an assumption in this string that Engineering will
>    continue to operate as usual. Is it worth challenging that assumption?

At least one answer is that the writing resources reporting to product
teams (or their close management) would allow localized decisions
for different organizations to be made to find something that works
for them.

Offhand, the proposal certainly seems less beaurocratic and have a lower
level of "built-in overhead" (a constant Digital problem) than the IDC
proposal, and would seem (at least one the surface) to be more likely
to allow the right thing to happen (even if "the right thing" is
different low-level organization inside eng.)

There has been a lot of speculation in this stream about the current 
overhead of IDC.  So, in an attempt to interject some facts into the 
discussion, I went to the IDC Finance Manager to get his count of the 
IDC manager to individual contributor ratio.

The ratio is 1:14.  In the manager category, we counted all leaders 
and most of the coaches.  Some coaches are charging directly to projects 
and fulfilling the role of project leader so I didn't count them.

1:14 is a very good ratio, as good as you will find in the company.
If anyone is aware of a better one, I'd like to talk with the manager 
in charge and learn how they do it.

Regards, Sue

>1:14 is a very good ratio, as good as you will find in the company.
>If anyone is aware of a better one, I'd like to talk with the manager 
>in charge and learn how they do it.

A group I used to work with at the Colorado Customer Support Center
usually ran about 1:30 (at the peak as I recall).  Talk to Wanda Pechnik,
or Karen Julian (former managers of the group).

    
    as of today we don't even have a "reak" manager...
    
    When we get 1 he/she will have about 30 people working for them in 2
    different type of business, internal and external field service...

RE: the last few notes

For me, there are questions beyond "What's the ratio and how do they do it?"

o How well do they do it?

o Would customers agree/disagree with the assessment?

o Would individual contributors agree/disagree with the assessment?

o What are the gaps among the different assessments?  

o What are the reasons for the gaps?

Span of control is a pretty important issue; it has a history dating
to the Roman legions, building the pyramids, and I'm sure long before
that.  And we continue to have lessons to learn from it.

RE: a few notes back...

I don't know him, but IMO Gerry Fisher was misinterpreted when he referred 
to "managing this mess".  He'll correct me if I'm wrong, but I don't 
think he was referring to the new plan specifically, but the headaches 
involved in management in general.

And you can extrapolate that to any managerial job where the person is 
really working at it versus coasting.  I often wonder where the 
gratification is in having those managerial jobs. 


Rose

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------


RE: .100, Sue Gault, Head of IDC


Sue, now that you're here, perhaps you can answer some questions about the
outsourcing plan.  

Specifically: 

      1. As explaned in the IDC outsourcing meetings, the plan is to have 
         *all* writing done by agency personnel.  That is, no provisions
         are planned to keep key documentation in house???

      2. SES wants to prevent engineering groups from hiring writers directly,
         or from bypassing SES and going directly to agencies or individual 
         contractors.  True?  Why?

Yo!  None!

--PSW

    Uh, in context of the Bastille Day announcement (reorg du jour),
    
    BP now says that the Divisions will be autonomous and own their
    own engineering, etc.  So Enrico and Charlie, as Senior VPs, are
    now peer to and separate from Bill Strecker, also a Senior VP.
    
    If they are really separate divisions and not just a fig leaf on the
    same old club, then they should not have to buy ANYTHING they don't
    want from a common Engineering service group, right?  Is SES more
    poweful than Enrico or Charlie?  Has BP made this an exception?

Re: 3238.104 (CXDOCS::JOHNSTON)

>I don't know him, but IMO Gerry Fisher was misinterpreted when he referred
>to "managing this mess".  He'll correct me if I'm wrong, but I don't
>think he was referring to the new plan specifically, but the headaches
>involved in management in general.

Is that really how you interpret the following from Gerry's .36? 

>Finally, the engineering folks who think that they want to control the
>documentation outsourcing are crazy (in my opinion).  It's going to be
>very ugly, very difficult, and will produce mixed results.  I'm not
>saying that you aren't capable of doing it and doing it well.  I'm
>just saying that it's going to be a difficult managment job that a lot
>of managers won't want to do (a lot of us in IDC/SES are trying to
>figure out if we want to do that kind of management).  I think you'd
>be happy to sign a contract with IDC/SES to have us manage that mess.

Mike

        re: .100
        
        The corporate goal is 1:25 - 1:40.  Your group is at least 50%
        overstaffed in the management area, by BP's definition.
        
        Dave Zaniewski

    I believe Sue was addressing the perception that IDC will lay off 50%
    of its headcount and leave only managers.

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

==============================================================================


		Clarification on Overhead Calcs:

	Re: -.100

		I think I can clarify this whole overhead ratio bit.
	As an individual contributor in IDC I report to a single
	Resource Coach and,  for each project I work on,  a Business
	Coach.  So, for example,  while working on two projects,  my 
	ratio of overhead to individual is 3:1. ... No, that's not 
	a good way to look at it.  Never mind that.

		No wait.  Here's how it works.  Before the '92 Reorg.,
	I had a supervisor who held staff meetings,  worked with
	funders, and did my performance reviews.  After that reorg.,
	I became part of a self-managed team;  There are no staff 
	meetings,  no performance reviews,  and I work with the 
	funder directly.  So ... I guess the ratio for overhead is 
	something like 0:1.  There, doesn't that look a lot better? 
	Of course it does.

		Now back to the outsourcing question.  In this new 
	plan,  if I take the 0:1 ratio I just calculated,  and add 
	in an account manager,	resource manager,  vendor manager, 
	and project manager,  the ratio becomes more like 4:1.  
	Next, I outsource myself by using a subcontractor and the 
	ratio becomes 4:0.  Clear enough?  Any further questions?  
	

    RE: .105 
    
    Well, maybe you missed it, or maybe you were at a presentation that
    didn't cover it for some reason, but at the ZKO presentation Ron Stokes
    *did* say that certain strategic projects and projects that cannot
    reasonably be handled by a vendor would still be done in-house.  What
    we don't know is how SES will define "strategic."
    
    There is also an assumption in here that this whole plan was an IDC
    idea, but we honestly don't know that.  It could have been the
    brain-child of someone on Keillor's staff or Keillor herself.  And it
    certainly could have been someone of IDC's leadership team.
    
    Another assumption is that vendor management, account management,
    resource management, and project management will all be done by
    different people.  We don't know that, either.  In PCBU, those tasks
    are all done by the same person, and that could easily be the case in
    SES.  We're supposed to get the preliminary implementation plan today,
    and I'm hoping it's on time.  Maybe that will let us know something
    more concrete, so we won't have to assume anything anymore!
    
    My more immediate concern is how this all fits in with BP's
    announcement yesterday.  Without central engineering, how will Shared
    Engineering Services be handled?  *Should* there be Shared Engineering
    Services at all?  Why should Digital present a single, unified "look
    and feel" to all courseware and documentation?  Other companies do not. 
    But within a single product space, they present a single, unified "look
    and feel."  This new set-up should allow that to happen.
    
    So what does that do to DEC STD-073 (packaging standard) and STD 073-4
    (film mastering standard)?  Does each business then get it's own
    equivalent of the standard?  Will the standard be split into sections
    to cover each of those businesses, whose markets are distinctly
    different and whose documentation must reflect those markets?
    
    Ah, more things that make you go "Hmmm."
    
                                                                    
    Susan

.112...I think you may have identified one of the missing Core
Competencies ----- Standards Manager!! In fact, we may need a LOT of
standards managers!

	DEC STD 500 - Standards Manager 
	DEC STD 073 - Standards Manager

		.
		.
		.
		.
		.
		.
	DEC STD xyz - Standards Manager

I wonder if we have 700 standards?

dave 

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

==============================================================================

As a writer who knows that seeing is believing, I have attempted to 
verify Sue Gault's (see .100) ratio of IDC individual contributors to 
managers of 14 to 1, I delved into DBDOC (labor reporting system used
in IDC). Those with access to DBDOC can check this themselves.

This analysis does not differentiate managers who bill themselves to
overhead from those who bill to projects. As I see it, management is
management.

Enter DBDOC.

To get a list of managers:

Select:
(2) All Other Functions
(1) Employees
(55) Reports
(2) Distribution Lists
(1) Leaders and Coaches

DBDOC writes a file named LDR_CCH.DIS to your current default
directory.

This file lists 86 leaders and coaches.

To get a list of worker bees:

Backup (key F8) in DBDOC to the "Reports" menu

Select:
(1) Old DBDOC Reports
(1, for display) or (3, for file) Organization Communication List
Report on Organization: (2) (code for IDC/Resources)

This lists 740 "resources", of which 36 are coaches (all the
non-business coaches) who are also listed in the LDR_CCH.DIS list.
Subtracting these leaves 704, 101 of which are identified as
contractors. Subtracting these leaves 603 permanent (for now)
"resources".

Ratios:

704 total individual contributors to 86 managers is 8.2 to 1.

603 permanent individual contributors to 86 managers is 7.0 to 1.

Presumably the LDR_CCH.DIS list is up to date. The list of "resources"
is not up to date (it is under "Old DBDOC Reports", whatever that
means), as there are people listed who have been TFSO'd. Presumably the
current number of individual contributors can only be smaller, which
makes the ratios even worse.

    The list of Leaders and Coaches is not up to date.  At least two are
    listed in there who are gone, and at least one is not longer a coach.
    If the leader doesn't bother to have the system updated, it doesn't
    contain accurate information.  I believe we're down to 80 in
    management positions, but I'm not positive.  --S

>    reasonably be handled by a vendor would still be done in-house.  What
>    we don't know is how SES will define "strategic."
 
    Back at Philips we used to say that there are two types of
    projects: "profitable projects" and "strategic projects".
    
    Using the above criteria it was always easy to determine whether
    a project was "strategic" or not :-)   
    
    re roelof

Just a pointer,  Sue Gault's monthly report for IDC can be found
in the notes file VAXUUM::IDC (unrestricted),  note 23.488.  At the very 
end,  she lists a few issues relating to the outsourcing plan.   I didn't
see anything in her report that would indicate she has any concern for
providing engineering something it wants but rather just telling us
again, that this is the plan, like it or not.  Read for yourself.
Oh, and look out for all those individual contributors who are spreading
inaccurate information.... 

Garry

    This is a reply to note 3238.105.  There is no plan to outsource the
    work done by **all** writers.  There is a plan to outsource the writing
    of some information.  The IDC workforce plan indicates those skills
    that we believe we need to retains within SES.  For writers, these skills 
    include information design and technical mastery.  Execution of the
    design is the work to be outsourced.  I think what may be causing the
    confusion is that some (maybe even many) writers do both the design and 
    execution.    
    
    Secondly, SES wants to provide Engineering with an added advantage (cost 
    and quality) in doing business with us.  Our focus is on providing a world
    class service, not on preventing Engineering groups from doing things.
    
    Part of what SES brings to the table that Engineering groups can't 
    do easily on there own includes:
    
    	- A high-volume partnership with vendors to get the lowest possible
    	  price. Individual projects, for the most part, don't have the
    	  volume.
    
    	- Expertise in vendor management. It takes significant expertise to
    	  build a good working relationship with vendors of information.
    
    Contractors are generally more expensive than direct reports (though
    there are exceptions) and are subject to legal regulations that require
    a break in employment from time to time.  They are a good solution for
    variable amounts of work but not a good substitute for a permanent work
    force.
    
    Regards, Sue  
    
     

    Ok, so people have voiced opinions on the issues, and we seem to be at the
    point where we are dealing either in speculation or generalities.  It
    would be helpful now to know when the SES plan will be unveiled, what
    the mission of the new organization is, and what will happen over the
    next few months.  I understand the plan will be released in mid-August.
    True?
    
    

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------
    

>        The corporate goal is 1:25 - 1:40.  Your group is at least 50%
>        overstaffed in the management area, by BP's definition.


      I'm so sorry that you still don't understand.  Each management head in 
      IDC actually has a 1:50(!) span of control.  From the IC point of view, 
      they can have several "bosses", responsible for the different essential 
      management functions.  Like this:


                     leader A   leader B  leader C
                       /  \       /  \     /  \


            xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx  (50 IC's)


      So, obviously each of the Leaders has a 1:50 ratio, the *best* in Digital!

      Of course, this simple drawing doesn't do the plan justice.  We don't 
      have anything so antiquated as a hierarchy; picture a big bowl of
      froot loops...   

      Feel free to contact our Organizational Excellence group if you'd like
      a presentation on how you can rework your group to use the self-empowered
      team approach.  Please do not approach any IC's directly as they are
      still misinformed about the benefits of this plan.
    

    re .120:
    
    Where are the smileys in that note?  It is very disturbing to see a
    note like that presented as it were serious.

>>    Where are the smileys in that note?  It is very disturbing to see a
>>    note like that presented as it were serious.

Because of the lack of "smileys" in .120 I took it as if the person WAS 
being very serious and IS really pissed off at the way things are setup.

Especially the part about:

>>   Feel free to contact our Organizational Excellence group if you'd like
>>   a presentation on how you can rework your group to use the self-empowered
>>   team approach.  Please do not approach any IC's directly as they are
>>   still misinformed about the benefits of this plan.

I kind of like the anonymous notes, gives us a chance to try and think of who
might have written it.  Here's my guess:

I assume it was witten by someone in IDC.  I can then go to either a 
"leader" or an IC (what are they refered to as? "information providers"?)

If I say a non-IC wrote note .120 - I take everything up to the two paragraphs
as:  "we're doing one hell of a job here".  The last two paragraphs, well they
just don't fit - except maybe to simply put down IC's.

Now, if I take that note and apply an "IC author" to it, its someone blasting
IDC management for the current origanization and letting them know that:

  "I don't understand what you have done to our organization because you have 
   not explained it to me"

(with a hint of "maybe they don't understand what they have done themselves")

Me, I think its an IC bitching about the current mangement chain.

bjm

I haven't read most of the other replies.

Our group has transistioned, over the course of the
last 4 years from dedicated technical writers for
our product to using non-dedicated internal
writers.

I have long been of the opinion that the way in
which we do technical writing needs to be
re-engineered and that the results of the process
could be sold as a product.

I think that we almost achieved something good with
the use of bookreader and the system we had of
creating links to the card filing system.

What I am talking about is how do we manage the 
process of creating, and revising manuals to
reduce the amount of redundency and waste that
is inherent to the process.

One way to reduce the cycle time is by having
dedicated technical writers who then know the
product and make less errors and can catch the
errors that the engineers make.  Since the
corporation seems to be headed the other way
toward contract and internal freelancing this 
problem could grow to become critcal.

If we are going to outsource technical writing
then a paperless revision system should be
created which will allow us to track changes
in the document and quickly transmit those changes
to the document writers.  Otherwise our quality
of documentation will suffer.

Documentation that is incorrect is just as bad
for the product as software that does not work!

    re: .120
    
    >>>
      Of course, this simple drawing doesn't do the plan justice.  We don't 
      have anything so antiquated as a hierarchy; picture a big bowl of
      froot loops...   
    >>>
    
    I know froot loops.  I eat froot loops. Froot loops are my friends.
    IDC is no bowl of froot loops. ;^)
    
    Actually, this could not have been written by a writer in IDC.  No
    writer would have spelled it "froot loops", unless that is the real
    name, in which case it should have been capitalized.
    
    I think when the Plan comes out, we'll look more like a refrigerator
    with a bunch of magnets - the fridge being the core organization, and
    the magnets being the outsourced staff. 
    
    Ok, now back to the serious discussion. ;^)
    

    RE: .124  by CUPMK::TALBOT 
    
    >I know froot loops.  I eat froot loops. Froot loops are my friends.
    >IDC is no bowl of froot loops. ;^)
    
    I thought we were Cheerios.  
    
    At least that's what everybody keeps saying.
    

Re: 3238.118 (DONVAN::GAULT)

>Secondly, SES wants to provide Engineering ....

Sue, could you give us some idea of where SES is in the new organizational 
structure? 

Thanks.
Mike

    A leader (not Sue Gault) in IDC told me that we fall under Pesatori in
    CSD.  --Susan

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ----------------------------------------------------------------------
    
Sue, thanks for some accuarate information.  I do have 2 questions.

1: Now that we know that a core group of tech writers will be kept, who should 
engineering contact to add writers to the core list?  

2: I understand from your message that Engineering for any project will be 
free to hire its own writers/contractors if the SES model does not meet their
needs or is too expensive.  Is this correct?


    

>    I think when the Plan comes out, we'll look more like a refrigerator
>    with a bunch of magnets - the fridge being the core organization, and
>    the magnets being the outsourced staff. 

Organizations sounding a lot like organisms, this could easily translate to
the fridge being Humphrey Bogart the organism and the outsourced staff being
leeches attached like magnets to the organism like in the "African Queen."

>    Ok, now back to the serious discussion. ;^)

Sorry, couldn't help myself!  ;-) 8^D

John Smith (not)

    RE: .130  by TOKNOW::METCALFE 
    
>>    I think when the Plan comes out, we'll look more like a refrigerator
>>    with a bunch of magnets - the fridge being the core organization, and
>>    the magnets being the outsourced staff. 

>Organizations sounding a lot like organisms, this could easily translate to
>the fridge being Humphrey Bogart the organism and the outsourced staff being
>leeches attached like magnets to the organism like in the "African Queen."

    If I were casting this, the outsourced staff would not be the leeches.
    

>    If I were casting this, the outsourced staff would not be the leeches.

Ah, yes.  Perspective is a curious thing.  ;-)

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------
    
In a late-breaking development, the Boston Celtic organization has decided to
follow the potentially highly successful Digital Equipment Corporation business
model.  This means that the Celtics have adopted a long-range strategy that
focuses on and invests in a set of competencies core to its business and
aggressively outsources all others.  

As a result, work needs to change dramatically to fall in line with the new
Celtic strategy.  The Celtic Staff has given basketball pioneer and long-time
winner, Red Holtz, the charter to lead a Future State Program Team to define
the processes necessary to move to this new model. The Program Team is divided
into smaller teams focused in the areas of Rebounding Management, Dribbling
Management, Scoring Management Management, Food Vendor Management, and Coaching
Tactics Management.

The Celtic organization has already had much success in the area of
outsourcing, specifically in the area of Spongy Floor Management and Parking
Lot Management. The results have been impressive with respect to cost savings
and the Celtics want to build on that success. The members of the five new 
program teams are:

1. Rebound Management - Muggsy Bogues, Ralph Sampson, and Gerry Cheevers 

2. Dribbling Management - Curly Neal, Roberto Duran, Dick Stuart, and Flipper
(Mr. P.W. Herman will serve as a consultant)

3. Scoring Management - Wilt Chamberlain, Diego Maradona, and Geraldo 

4. Food Vendor Management - Tom Heinson, Melvin Turpin, and Karen Carpenter

5. Coaching Tactics Management - Dick Vitale, William Westmoreland, and Gene
Hackman 

    Here are some of the results you can expect:

o The goal of the program is to be visibly operational by the start of the
1994-1995 NBA season.  The program will be fully operational by the June 1995
NBA draft, specifically the lottery-pick portion of the draft.

o A good portion of today's Celtics' basketball (referred to as "floor work")
will be outsourced; that is, external vendors will produce the actual
deliverables based on management's well-designed specific requirements. Core
services that we will retain in-house will revolve around definition, design,
project management, and any other tasks that can be done by management.
      
o The fully operational end-state will have a smaller base of internal people,
or permanent Celtics employees.  These people will leverage a larger variable
external  workforce.  The expectation is that the Boston Celtics will be
reduced by at least 50%. As mentioned, less important positions, such as
guards, forwards, and centers are prime candidates for outsourcing. 

o This model will basically implement the previously stated, 'best-in-class'
Digital Plan.  Once it has been updated to include requirements for
outsourcing, and we finally know what we are doing, we will make available the
document that defines skill requirements in the new organization.

o The new Boston Celtics will be one integrated organization, using the
processes of account, vendor, project, and resource management.  The stovepipe
groups and positions that make up the Celtics today, such as Center, Shooting
Guard, Point Guard, Quarterback, Goal Keeper, and whatever the others are, will
no longer exist.

My father and I have high expectations that the new Celtics will return to the
successes and financial benefits that were commonplace in the John Y. Brown
era.  It will not be an easy transition -- we extend a sincere 'happy
job-hunting' to the unlucky 50%.

    
    re: many replies back
    
    It's most intersting that many of the replies begin with the banner
    "The following ... who wishes to remain anonymous".  Why is this?  Are
    people afraid of asking questions about this organization and letting
    others know who they are?  What does this say about the organization
    in which the writers belong?  What has happened to people who expressed
    their concerns and revealed their identities?  Were they sent of to
    "pursue other interests"?
    
    Dennis
    

    Nah, I'm still here!  Next downsizing won't be done until late August
    or early September! ;-)
    
    I, too, think it's sad that so many in SES/IDC have this obvious fear
    of retribution.  Very sad.
    
    BTW, we (individual contributors, at least) did not receive a
    preliminary plan on July 15.  I have no way of knowing if the Future
    State Teams actually delivered the preliminary plan or to whom.  I do
    keep wondering what the larger Digital reorganization and our placement
    under Enrico Pesatori will mean.
    
    From what I know about Pesatori (and it's probably not as much as I
    *should* know), he believes in outsourcing, so it will probably happen. 
    What isn't clear is whether a Shared Engineering Services is really
    needed without a Central Engineering group.
    
    Of course, Central Engineering was only about 1/3 of IDC's business in
    the first place.  Might it be possible that SES documentation and
    training folks will be split up to follow the model of each business
    being responsible for its own engineering, marketing, sales, etc.? 
    This certainly makes sense after seeing the DVN this morning.
    
    If so, part of the organization will probably fall under Christ, part
    under Rando and part under Pesatori (the split in our funding was
    almost equal among hardware, MCS, and software).  This seems to follow
    the new "business model."  And if so, it is possible that outsourcing
    could still be an option for all three division or for some of the
    divisions.
    
    As I've said so many times recently in conversation, "Fasten your
    seatbelts; it's going to be a bumpy ride!"
    
    
    Yours in speculation,
    Susan
                         

    re -.2: If you were Bob Palmer, you also would not want your name
    associated with a bunch of gripes or blowing the whistle on some
    screwy practices. You might loose your credibility as a professional
    person. Yet everyone needs to blow off steam once in a while, or say
    what is *really* going on.
    
    I hope this accounts for it. Perhaps we can have some anonymous replies.
    
    Al
    

    Many people in the organization do seem to fear retribution.
    (I have been told by some colleagues that I will definitely be laid off
    for things I've written here, but hopefully they're wrong 8^(
    
    Also, the anonymous reply mechanism allows disgruntled individuals to
    take potshots at Sue Gault and the rest of the management team from
    behind a mask.  The most entertainingly sarcastic replies here seem to
    be of that form.
    
    I think it's perfectly understandable that in an organization whose
    announced purpose is to lay off at least half the population, for the
    period of time until the ax falls there will be intense pressure and
    emotional reaction.  We're all looking around at each other and
    thinking either "I hope it's her and not me" or "It's gonna be me."
    Neither is a healthy thought.
    
    The other thread you may pick up here is that many IDC people seem to
    assume that anything leadership says is false and interpret
    accordingly.  As a recent addition to the organization I have been
    struck by the same observation.  It's nearly universal!  I think it's
    fair to say that any organization suffering from that problem is in
    serious trouble indeed.

    
                         <<< Note 3238.136 by ULYSSE::ROEMER >>>
                   -< Nah, they want to remain being professionals >-
    
    re -.2: If you were Bob Palmer, you also would not want your name
    associated with a bunch of gripes or blowing the whistle on some
    screwy practices. You might loose your credibility as a professional
    person. Yet everyone needs to blow off steam once in a while, or say
    what is *really* going on.
    
    
    	Wow!  Is it rue then?  BP does contribute to this Conference?
    
    
    				Malcolm.

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

===============================================================================

re: -.134

		"What does this say about the organization
    		 in which the writers belong?"

	
		I feel disconnected from my organization.  I work with 
	an engineering group.  I feel like part of the engineering
	team.  
		A couple of years back,  IDC gave us "self-managed
	teams" and "dollars-for-deliverables."  The "self-managed teams"
	in reality meant that we had fewer supervisors and that their
	responsibilities were no longer clear.  

		The "dollars-for-deliverables" program attempted to 
	put fixed prices on documentation as opposed to simply 
	including the work in the overall development process for a 
	product.  This focused a lot of attention on estimating and 
	tracking labor and took time away from the actual work to be 
	done.  There seemed to be a change in attitude from our
	expertise being part of the good ingredients going into the 
	product to an attitude that it was added cost, more like 
	the cost of the bottle than the wine inside.  

		At the same time,  we were told that part or our
	performance evaluation would be based on how much support we 
	showed for these new programs.  This made many of us feel
	like we had to act enthused unless we wanted poor reviews.

		Perhaps they meant well but their ideas seemed to have
	no connection to the problems of doing my job and were actually
	more of a distraction.  And,  with a few notable and admirable 
	exceptions,  the leadership spends little time communicating
	with the rest of the organization.  If you compare the time 
	Bob Palmer spends with us through his DVNs and the time 
	our senior managers spend talking with us,  Bob beats them 
	hands down.
			signed,
				Enthused in public, confused in private.

    
    >	At the same time,  we were told that part or our
    >performance evaluation would be based on how much support we
    >showed for these new programs.  This made many of us feel
    >like we had to act enthused unless we wanted poor reviews.
    
    This is very intriguing.  Having taken a management 101 course, I found
    that if you reward individuals (e.g., pay them, grade them, etc.) for
    making more widgets, they will make more widgets.  Extrapolating from
    what I learned, if a terrible comedian pays an audience to laugh at
    his/her terrible jokes, they will laugh.  But, does this make the
    comedian a good comedian?
    
    Perhaps, we should judge the methods by their results.  What were the
    objectives of the new system? has the new system met those objectives? 
    
    Dennis
    

Well, one of the objectives was to flatten the organization...

Perry

There are more anonymous replies in this string than in any string I've 
seen in any conference in my 7 years here. 

So, yes, it's obvious that many people do not want their names to appear 
with what they are writing, and feel that there might be repercussions.
I don't think that this fear is totally unfounded. 
As someone mentioned, IDC individual contributors were told that part of 
our performance evaluation (20%) would be based on how much support we showed 
for the new IDC organization. In fact, here's the exact wording from 
Sue Gault (head of IDC):

"The salary plan is also a means of rewarding people who have helped
move IDC toward the goals, values, and characteristics of the new
design. Thus, for this year, 20% of your performance rating will
be based on your work in making the new IDC a reality, and 80%
will be based on your performance on projects."

Of course, the "new IDC" mentioned here is now the old IDC. But 
saying something negative about the new emerging SES/IDC is not 
seen as a career enhancing activity.

Mike

As an engineering supervisor who spent many years closely tied to CUP/CUIP/IDC
writers, I was originally concerned when the "self directed teams" concept
was put in place. I was concerned because it didn't look right, and wasn't
DIGITAL-like.

Shortly thereafter, I became even more concerned when I heard rumblings that
the model might be extended into engineering. I found out later that there
wasn't really any basis in the rumor, but it was disconcerting nonetheless.

Then I began watching many friends and associates in IDC being wounded by
the new organizational model. Over, and over, and over.

And now, the whole thing is being dismantled, as it were.

An odd way to admit that a bad idea failed.

-Jack

RE: -1 and self-directed teams

>Then I began watching many friends and associates in IDC being wounded by
>the new organizational model. Over, and over, and over.

I'm part of an (in progress) self-directed team, and I don't feel 
wounded by the experience at all.  

>And now, the whole thing is being dismantled, as it were.

I think this is a premature statement.  Outsourcing does not automatically
negate self-directed teams; nor does a restructuring of IDC.

Could it be dismantled?  Sure.  But it could just as easily stay.

The IDC ODT document had a list of responsibilities that teams were 
expected to have, along with a timeline with full implementation (as 
I recall) in 1995, maybe 1996.  So now maybe the timeline is just
extended.  

In the meantime, everything that's going on with restructuring is 
just a sometimes painful diversion rather than a given.

>An odd way to admit that a bad idea failed.

Even *if* it is dismantled for IDC, it's a win for people who graciously, 
effectively participated in teams and gave it their very best shot.

Call it a buzzword, the fashion-du-jour, whatever.  A number of external
companies are looking for people who are willing to do teams, and 
who preferrably have experience at it.  

Being able to talk coherently about the experience, why it failed
(if it did), and what it needed to really succeed is, IMO, 
worth some points.

Rose

For those of you who saw my two- to three-minute posting in this space,
I decided to think better of it and not post my comment.  I should learn
to follow suit with some of the anonymous posters (though let me be quick
to disassociate myself with those naysayers, if I need to fear for my job).
Yellow isn't my favorite color, but neither is pink so I'll stick to yellow.

Mark

> Yellow isn't my favorite color, but neither is pink so I'll stick to yellow.

Thereby hoping to stay in the black? All of this has some people feeling
    very blue...

Re: .145

Well, from some of the comments I've received (from those who speak to me)
perhaps what was unsaid was more juicy than what was said.  Let's not blow
what I deleted out of proportion.  (Funny how that works.)  It was a brief
(and admittedly cynical) comment about Rose receiving her 20% but not being 
able to collect it for 18 months or so.  Simple as that, but I thought better 
of making it.  But since speculation seems to create a bigger monster, now 
you have the real story behind my two- to three-minute posting.

Mark Purple-heart Metcalfe

Well, I'm off to become a commodity. Not only can I write; I can read the
handwriting on the wall and decided to get into the market before the rush
hits.

I've found that there are many, many companies who are willing to pay big
bucks for writers with real technical skills (and I do mean *real*
skills...correcting the spelling in a engineering spec and turning it in to
an editor is not considered a skill). I've also found that there's a stigma
attached to being a DEC employee...the perception is that we have few
skills that the 'real' world uses.

Good luck to you all.

Perry ([email protected])

    
    Re .12 (written 07-Jul):
    
>>    The preliminary plan is supposed to be ready a week from Friday.  We'll
>>    see what happens next!
    
    has anybody seen this plan yet?
    

    I heard that the preliminary plan was delivered to Sharon Keillor on
    time and will not be made public.  As I understand it, Sharon is
    working on the final strategic plan and has people (unknown who)
    working or readying to work on the implementation plan.  I don't know
    if this will be on schedule, but do not believe that we (individual
    contributors in SES/IDC) will ever see the written plans.  Just the
    results! :-}
    
    
    Susan
    
    PS:  "Unknown" to me.  There might be others in IDC who know who's on
    the implementation team.

      FWIW: I doubt that any individual contributors in any part of SES 
            will see/hear anything except the results of the plan.  I'm 
            in SES/ETS now and I haven't heard anything about them 
            either.  It's probably just a matter of Sharon's planners
            working under a tight deadline imposed by someone higher in 
            whatever division/function SES is part of now.  Our knowing 
            the plans won't change anything except making us feel more 
            included.  That would be nice whatever the results, but 
            spending the time required might not be practical given the 
            company's current state of flux.

      Terry

    
    But... but... This not just more of the usual layoffs. This is a major
    change in the way engineering gets the documentation that is an
    integral part of its software products. Do other engineers besides me,
    or their managers, feel the need to understand the new order as soon as
    possible in order to start planning the next wave of projects??
    

    
    Note 263.35 in the VAXUUM::IDC conference mentions a question and
    answer document that IDC was supposed to distribute to engineering
    managers.
    
    Have any engineering managers out there seen it?
    

....or have the gags been sufficiently distributed?

From:	VAXUUM::DONVAN::GAULT         4-AUG-1994 13:03:46.65


Subj:	Status of SES Future State Implementation


TO:	SES
FROM:	Sue Gault
SUBJ:	Status of SES Future State Implementation
DATE:	August 5, 1994

The purpose of this memo is to communicate the overall
activities and status relative to the SES Future State.
Further communications will follow focused on specific
topics with more detailed information.

          ************************************

	Status of SES Future State Implementation
		   August 5, 1994

BACKGROUND

The need for a more efficient and cost-effective model of 
work is being driven by the competitive nature of the 
computer industry and an environment of decreasing revenues 
and increasing costs.

To meet these pressures and to provide leadership, SES will 
focus on and invest in a set of competencies core to our 
business and outsource all others.

An aggressive design and implementation schedule was put in
place and a SES Future State Program Team, led by Dave Popp,
was formed to begin the design work.  

OUTSOURCING STRATEGY

In May of this year, the SES staff did an analysis of the 
current portfolio of services and skills to determine which 
were core to our business and which were potential candidates 
for outsourcing.

The SES core competencies are utilized primarily in the 
project definition and design phases of a project life cycle.  
The skills to be outsourced primarily fall within the 
development and delivery phases.  The resulting strategy is that 
SES will define, design, and manage products and services that 
are developed and delivered by external suppliers.

It is important to note that core skill is not necessarily a
reflection of the job title.  For example, many technical 
writers have design and project management skills and technical 
expertise core to our business.

DESIGN PLAN 

The Program Team began work on a Design Plan on June 9th and 
delivered on July 15th.  

The design work is based on SES as one integrated organization.
A future state process is defined from the initial contact 
with a client through the acceptance and delivery of the 
contracted service or deliverable.  The processes of account, 
vendor, project and resource management support the future
state process and are described in detail.  

The Design Plan does not address organizational structure.
Account, vendor, project and resource management are processes 
and are not necessarily specific positions.  For example, 
a Technical Writer with project management skills may perform 
the role of Project Manager.

The primary purpose of the Design Plan is to define an 
integrated process to support the delivery of competitive
products and services through an outsourcing strategy.
The design, in conjunction with an organizational structure, 
is the basis of implementation planning.


IMPLEMENTATION PLAN

The Design Team leaders met with the SES staff during 
the last two weeks of July for implementation planning. 

Implementation tasks were brainstormed, categorized, and
analyzed for inter-dependencies, and Implementation Team 
Leaders were assigned.

	TEAM				LEADER

	Competitive Analysis 		Sue Gault
	and Communication		

	Activity Based Management	Dave Popp

	Vendor Management 		Celeste Larock
	and Outsourcing Pilots	

	Technology			Andrew Gent

	Human Resources			Pat Fleming

	Account Management		Rich Willey

	Business Practices		Karen Andersen

	Project Execution		Ron Stokes

The Implementation Team Leaders are currently forming teams
to plan activities and create an integrated Implementation 
Plan.

ORGANIZATIONAL STRUCTURE

Sharon Keillor, as part of the 2-week implementation planning
meeting, took responsibility for defining the organizational
structure.

Structure definition is still in process, but the key attributes 
of the future state organization have been defined as follows.

	The future state is:

	* a flat structure, based on 1 level of management
	  responsible for strategy and business operations
	* based on virtual teams with core competencies
          accountable for operational excellence
	* limitless in capacity 
	* implemented by the end of Q2

The structure and the process for assigning and/or filling
positions will be communicated at a future date.

OUTSOURCING PILOTS

The outsourcing pilots are continuing.  We are learning a lot
about the vendor capabilities and capacity for volume business.
In addition, we are identifying our internal needs for 
processes, business practices, training and tools to support 
doing business with external vendors.

The July 15 status report from the Outsourcing Pilot Team
will be sent as a separate message.

MORE INFORMATION

More detailed information will be following in the upcoming
weeks to help you further understand the SES strategy and
the implementation steps to move to the future state.

    
    .155 confirms the suspicion that the "future state" calls for IDC
    to specify and design doc sets, with vendors (not on-site contractors)
    doing the actual writing.
    
    How does this plan account -- or eliminate the need -- for the enormous
    bandwith that is required and currently available between developers
    and on-site writers during the implementation phase of a project?
    

    
    Does the need for a huge bandwidth indicate that quality information
    is being transferred efficiently?
    

>    Does the need for a huge bandwidth indicate that quality information
>    is being transferred efficiently?

Not necessarily, but that is neither here nor there.

Concerns here about "efficiency" are secondary to concerns about the basic
*ability* to communicate.

Hopefully, no one doubts the need for communication between the engineers
and the writers.  How will this communication be affected by geographically
separating engineers and writers as would be the case in this vendor
scenario?

Talking, face to face, historically seems to be a very efficient method of
communicating, learning, and gaining an understanding.  (If it weren't then
why would we have so many meetings?) The vendor plan would largely eliminate
this avenue.  That is the major concern with this plan.  This is what the
Future State folks have not yet addressed publicly - how we will compensate
for the lack of face-to-face comunication, which we depend so highly upon
today.

To go forward with this plan while not addressing the issue of communication
is sheer negligence.  On the other hand, having a plan but not disclosing it
creates an atmosphere of skepticism and mistrust.  If the plan is really
capable of working, then it should be able to withstand a little public
scrutiny.

-Mike

re 156:

    How does this plan account -- or eliminate the need -- for the enormous
    bandwith that is required and currently available between developers
    and on-site writers during the implementation phase of a project?
    

Someone asked this question at one of the Ron Stokes presentations, and the 
answer was to the effect "Engineering will have to change the way they work
too."

Asked who would enforce this new discipline, the answer was "Strecker."


Pilar.

re: .159

>Asked who would enforce this new discipline, the answer was "Strecker."

Did someone point out to him that Strecker does not own most of Engineering
anymore?
								- paul

    re: .160
    
    Hi Paul,
    
    At the time the talk was given, Strecker did still own most of
    engineering.  I think the change was announced only a couple of days
    later, though, which made it seem like IDC management was, um, somewhat
    out of the loop as far as future corporate direction goes.  Not that
    they're any different than the rest of us in that regard, but it seems
    like the rug's been pulled out from under some of their central
    assumptions. 
    
    --bonnie

    
    The question is not whether someone is in position to force engineering
    to work within the "future state".
    
    The question is whether it is possible at all to produce complex
    products with useful documentation within the "future state".
    
    Has anyone described how "Engineering will have to change the way they
    work too"?
    

1.  Outsourcing and Writing Documentation

I've been a technical writer for DEC for 15 years.  I have never worked
anywhere else, so I have a lot to learn about how other places do
business.  But I know how DEC engineering works, and I know they are
not prepared to change their way of designing and developing
products.  

Software development is an iterative process.  Skills
required in planning and design are required again and again
throughout the project development and release stages.  

Software design is successful only if it fits a user's model of
working, and relieves users of mechanical or repetitive functions.
This is a principle of good software design.  Some concepts need a
term, or a name, or a real-life model, so users can understand how to
make use of new functions.  That is where the knowledgeable technical
writer comes in.  

Having been involved since the product requirements were gathered,
or earlier, the technical writer takes the engineering features, the
product management vision, and the user's current environment, and
comes up with an organization of information that leads the users to
making use of a new piece of software.  It may take three versions of
the software before the product fits the user's workstyle and
workplace.

A technical writing position in the product development team cannot
be replaced by a project manager.  The work of planning and design
ends only after the product is "out the door."  The vision for the
way the software is percieved by the user does not come from
marketing input.  Perhaps it should, but the marketing organization
at DEC has little presence in the user workplace and almost no
influence over the product design, for the most part.  So the
technical writer assists the engineer to fine-tune the design and
interface, suggesting simplifications and structure, terms and names,
throughout the process.

I don't see any other way to ensure high-quality information products
and software, unless some other organizations and processes at DEC
are radically altered.  Specifically, the requirements managements,
the product design, the method for testing and reengineering the
product, all require flexibility, commitment, and responsiveness of
the writing team. The only other organization that is chartered to
understand user needs and why the competition succeeds is the
marketing organization, but in my experience, marketing is not
adequately represented or respected on product teams.
Usually they lack resources and knowledge for guiding product design
and development toward a high-quality, successful result.

2.  SES and IDC culture differences

How long has IDC been part of SES?  As an independent group, CUIP was
very successful at providing support and training for the writers and
documentation staff.  The CUIP organization promoted Information
Mapping, on-line documentation instead of hardcopy, and contextual
inquiry, offering courses, seminars, notes files, experts, and tools.
What has SES done for this part of Digital?

Growing with CUIP has been a sorry evolution.  Early in my career, I
learned to invest myself in the organization, becoming part of major
decisions and discussions, and providing feedback that was useful in
improving the way we do business as an organization.  Open, frank
discussion was the key to developing successful tools and processes.
Most improvements came from the writers, editors, and illustrators,
and we were successful.  VAX DOCUMENT was no prize, but we made it
into a useful tool, and today it is used by engineers, secretaries,
and other people who have to develop and maintain documents from
version to version, over the years.

Today, we are moved by other forces.  The management does not share
with us the problems of running the business in a hostile financial
and technical world.  Instead, they send down numbers for headcount
reduction and new names for our organization and goals, then mumble
about costs and overhead problems as the *reason* for the mandates.
Even as the leaders create an entirely new way of working, they are
unwilling to share information about their work in progress.  At a
meeting with our leader, we are asked not to talk about what is
discussed at the meeting.  The activity that will most likely affect
the way we do our work and our ability to achieve high quality
results, is a secret.

The plan will be developed in a vacuum without adequate input from 
individual contributors, feedback from engineering and other clients,
or provisions for steering the changes to meet our goals of lower cost
and higher quality.

The message is clear to me: the SES-level participants are not
focused in improving quality or cutting costs.  They are focused on
how to resume "business as usual" with less than 50% of the
organization.  Headcount reduction becomes the goal, instead of a
method for solving the problems.

3.  Correcting the course

Dare I suggest alternate methods of managing IDC?  Spitting into the
wind invariably results in an embarrassingly wet face, but as a
member of DEC and IDC, I feel somehow responsible for the way the
"future state" is being managed.  I am (still!) committed to making
my position as technical writer work.  I respect the other parts of
the product development team too much to simply sit back and wait for
a plan that will cut me off at the knees.  I would have no right to
complain, if I let this happen without voicing my suggestions.

The two groups whose product is most likely to suffer by the new plan
are the clients (in my case, software engineering and associated
organizations), and the users.  First, let's get them involved in
reviewing the plan and getting changes made where necessary.

The group with the most information about how we do our work, and how
we *should* do our work, are the experienced individual contributors.
Second, let's have a wide distribution of the overall strategy, and
the actual plan, to contributors.  Let's have brainstorming sessions
to solve real problems, like how to cut costs.  Let's include
clients and customers whose work is going to be affected by the changes.

The process will work only if integrated with the product development
process.  Let's work with engineering to develop a mutually
acceptable way of limiting costs and wasted effort, then imposing the
changes, restraints, and new requirements on engineering groups.

Spare me your sarcasm.  If engineering can't respond to this
pressure, what will they do when their own organizations are reduced
by over 50% and most of the work is outsourced?  This is the
direction of the company.  If we don't like it, we are obligated to
make our disagreement known, and pressure our company president and
vice presidents to adopt goals that will result in success for
Digital.

Let's not allow management to run the company into the ground while
chasing ephemeral goals and statistics without reminding them that
their company is made up of highly-skilled, dedicated, and
knowledgable professionals who may know more about the industry today
and the trends for tomorrow than the managers do.

4.  Client information and feedback

A software engineering group is my client.  They are even less
informed than I am.  For the most part, they do business the way it's
been done since the 1970s. Any changes have happened slowly and
gradually, based on proven successes.  They are not responsive to a
need to change their working styles and processes in such a major way
as the new "future state" will require.

The result will be a headlong collision of requirements: the new IDC
vs the engineering processes.  Is the management of SES cognizant of
this forthcoming explosion?  As our managers, they have the option to
ignore what is happening.  The result will have project managers
picking up the pieces of our ruined relationships with our clients,
as well as trying to implement a new and often mismatched way of
doing business.

Management should be prepared to deal with this situation up-front.
Getting the clients involved in planning the "future state" would be
a way to ensure the success of the new plan.  In addition, it would
provide vital information for the clients to prepare for change,
perhaps averting disaster in product development and delivery.

"Preparing for Change" may not be a topic in the management education
curriculum...that would explain a lot.

5.  Outsourcing pilot programs

The pilot programs for outsourcing projects is probably the most
potentially useful activity going on right now.  There are just two 
drawbacks to the way it is being implemented:

	a) They will not affect headcount.

	   Headcount reduction is not based on the relative merit of
	   the outsourcing strategy, it is a mandate.  The outsourcing
	   pilot programs will have no short-term affect on the
	   important decisions around how many people are actually
	   required to continue doing business.  Without any teeth,
	   the pilots are just paper tigers.

	b) They will not prove (or disprove) cost-effectiveness.

	   On a typical project, I may be involved in a release for
	   12 months or more.  Since the results of a successful pilot
	   cannot be evaluated until it is concluded, I assume the
	   pilot projects have considerably shorter development
	   cycles, and thus must be very different from my typical 
	   project, and perhaps not applicable to software projects.
	   Since the entire plan is supposed to be revealed in
	   September and implemented by December, I gather that it
	   matters not whether outsourcing is actually a cheaper way
	   to get the same quality product.  

What purpose, then, does the pilot program serve?  To gather
information about outsourcing vendors, so we will have a "preferred
list" of vendors with whom we will be allowed to do business.  I
leave it to you to decide whether these programs will provide
solutions for your projects.  I think every project being outsourced
will be a new pilot, having unique requirements and solutions.

At the very least, individual contributors may have an idea where to
send their resum�s.

6. Quality vs quantity

At the heart of the matter lies the question:
Is the goal to produce high-quality products
at a lower price?  Or, is the goal to reach a certain headcount at
DEC by a certain date?

If the former, there is no evidence that management has the
flexibility of process and thinking, and respect for the knowledge
of contributors who have done the work for years, to achieve those
goals.

If the latter, then IDC is a sacrificial lamb surrendered up to the
Wall Street gods.  When the company is run to meet stock prices and
other numbers, then it just doesn't matter what you do or how hard
you work or how much you know.  What is more threatening is the fact
that the gods may not be placated by the sacrifice.  The numbers may
not match up at the end of FY95.  Who will be chosen next?
Engineering has more of a stake in the "future state" than just
preparing for the changes in IDC.

Only by a concerted effort by all organizations
directly involved in providing products and services, can we change
management mindset and make significant improvements to the way we
design, develop, and deliver products.  All of these organizations
may need to change the way they do their work.  

More and better design specifications, closer attention to customer 
needs, and flexibility in the process, recognizing the need for changes 
and redesign, might significantly improve our products and our
productivity.

This requires engineering to take the initiative to:

	a) communicate with management, and to expect results from 
	   management based on their input

	b) be ready to change their own processes and working habits

It requires:

	a) better integration of the several disciplines involved:
	   marketing, testing, user feedback

	b) elimination of walls that prevent these groups from
	   effective two-way communication

	c) more attention to the way this company is being run. Don't 
	   leave it up to the high priests of Wall Street.  If you 
	   ignore them, you cannot complain when major changes affect
	   your product quality and delivery.

Maybe, if we try to sincerely examine the company's problems, construct 
solutions and alternatives, and suggest changes to corporate management, 
we have a chance to save the best of DEC culture: our high standards and
our dedication to our customers.

re:.162 & .159
>    Has anyone described how "Engineering will have to change the way they
>    work too"?
 

It took 159 replies before anyone said engineering would have to change the way they work, too...
159 replies discussed how and where we would get our tech writers from... sorta of an oblivious
p.s. that we have to change the way we deal with the problem - THATS A RATHER HOLE THAT WAS LEFT
UNCOMMUNICATED, UNMENTIONS, AND UNRESOLVED.  Pray, do tell us how we will have to change???

As an example of how important I view the writers in our group and their contribution, today I recieved
a notice from one of customers on the sucessful completion of their project.  After mentioning the members
of their group who contributed to the success, they mentioned several folks in our group who also contributed.
One of them was our tech writer, but as far at the customer (and the note) were concerned, that person was an
integral part of our group not another group.

I've read all the replies, and I just don't see how the new system is going to work very well...

Alice

         <<< HUMANE::DISK$CONFERENCES:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
                        -< The Digital way of working >-
================================================================================
Note 3238.164 A Question for Engineering - Is Technical Writing Valuable? 164 of 164
CADSYS::CADSYS::DIPACE "Alice DiPace, dtn 225-4796"  20 lines   9-AUG-1994 14:58
--------------------------------------------------------------------------------
re:.162 & .159
>    Has anyone described how "Engineering will have to change the way they
>    work too"?
 

It took 159 replies before anyone said engineering would have to change the way
they work, too... 159 replies discussed how and where we would get our tech
writers from... sorta of an oblivious p.s. that we have to change the way we
deal with the problem - THATS A RATHER HOLE THAT WAS LEFT UNCOMMUNICATED,
UNMENTIONS, AND UNRESOLVED.  Pray, do tell us how we will have to change???

As an example of how important I view the writers in our group and their
contribution, today I recieved a notice from one of customers on the sucessful
completion of their project.  After mentioning the members of their group who
contributed to the success, they mentioned several folks in our group who also
contributed. One of them was our tech writer, but as far at the customer (and
the note) were concerned, that person was an integral part of our group not
another group.

I've read all the replies, and I just don't see how the new system is going to
work very well...

Alice

Re: how Engineering will have to change the way they work ...

.45 addresses at least one way engineers will have to change the way they 
work. If this plan is implemented, you're going to be dealing with 
contractors who are working offsite. You'd better get used to specifying 
precisely what you want and writing everything down in specifications. 

Mike

    re: .165
    
    Ron Stokes' answer seemed to mean mostly that engineering would have to
    exercise some discipline with regards to planning, schedules,
    specificaitons, and so forth. 
    
    With decently detailed specifications that approximate what was
    actually coded, and a working copy of the software, a good writer
    doesn't need a whole lot of access to engineers.  Of course there are
    questions and problems, but I've worked this way in the past and not
    had a lot of trouble.  
    
    --bonnie

>      <<< Note 3238.167 by WEORG::SCHUTZMAN "Bonnie Randall Schutzman" >>>
>                     -< mainly it means thinking ahead... >-
>...    
>    With decently detailed specifications that approximate what was
>    actually coded, and a working copy of the software, a good writer
>    doesn't need a whole lot of access to engineers.  

 1) Engineering specifications are the wrong source documents 
    from which to create user documentation.  Specs are written 
    for implementors, not users, and do not provide the right balance
    of importance and focus that reflect actual intended product use.
    If anything, product requirements documents are a more reasonable
    primary source.
 2) You don't write the books until the product is finished (or at least
    at a late stable base level)?  Are you staking out your turf on the
    critical path?
 
A good, but underapplied, paradigm is to write the books first and THEN
create the product.  That's what the user sees.  If you can't describe it,
how can you create it?

Documentation is a critical element of the delivered product (and please 
remember not all  products are software products - my personal experience
here is derived from the creation of DEC printer products).
Writers must work with the engineers to execute their component of the 
product set.

- tom]

    re: .168
    
    Tom, 
    
    I admit I wasn't thinking of hardware documentation, which is an
    entirely different proposition than software documentation.  You're
    right, I can't sit down with a printer and figure out what the customer
    needs to know. 
    
    My main point was NOT that you use the spec as user documentation.  
    Of course you don't use the spec directly.  The biggest factor is
    indirect:  probably three-fourths of the times I go to developers, it's
    with an inconsistency or problem that should have been thought through
    and specified early in the design process.  In this company, the
    writers often perform the function of locating such problem areas, but
    we're just covering up for a gap in engineering procedures. 
    
    If the spec is decently thought through and up to date, I as writer can
    go to it to answer questions about how the product is supposed to
    work.  Problem reports  become much more a matter of "this doesn't work
    the way the spec says it's supposed to" than of just trying to figure
    out how it's supposed to work.  
    
    Yes, after a late, stable base level.  Remember the outsourcing
    proposal isn't talking about starting from ground level with the
    writing.  The doc set design and so forth is supposed to have been done
    in-house, up front.  If the product has also been adequately spec'd up 
    front, and adequately tested during development, it doesn't take a year
    to write and review the manuals.  It doesn't even take six months. Out
    in the real world, I've seen entire doc sets done in three months.  
    
    I won't get into an argument about whether to write the software from
    the manual -- my own feeling is that it wouldn't work unless you've got
    a writer trained in interface design to write the manual you're working
    from.  Might be a good idea, but it's an entirely different way of
    working.  
    
    I would agree that the ideal way is to have writers participating
    as active team members from the beginning -- but in most cases Digital
    isn't doing that now.  Software writers who are at the beginning of the
    product aren't reviewing specs and contributing to designs, they're
    being pulled onto other products to finish manuals that describe
    software that keeps changing right up to the submission date.  I see
    far too many products where not only isn't there a spec, there isn't
    even a reliable list of what features will and won't be in the shipping
    version, even up until late field test.  I grant you that sometimes
    late ship/noship decisions have to be made, but in some areas of
    Digital the procedure seems to be, "Well, it's two weeks to code
    freeze. What's working?  We'll tell the writers to document that."
    
    --bonnie
    

    
    re: .162
    
    	I suspect that Engineering will change much in the same way that
    SES and other orgs are changing. I detect a strong trend towards less
    technical involvement in many areas. Some of this is being driven by
    streamlining product lines and TFSO, some of it is due to lack of
    technical wherewithal at management levels, some due to shifting away
    from proprietary to open/commodity products, etc. 
    	I wonder if, when all is said and done, the divisions will have 
    anything left to contribute towards true progress in the industry,
    other than putting up a management/consulting front or just being
    another PC clone vendor like Dell.
    
    - Jim K
    
                          

    re: .163
    
    Great response, Mary.  But it looks like the answer is that the New
    Digital is not the Digital we desire.  Unfortunately.
    
    >...unless some other organizations and processes at DEC are radically
    >altered...
    >Today, we are moved by other forces...
    
    It looks more and more like there *are* radically different processes
    ahead, in reaction to forces we (Digital) have inadequately fully
    heeded before.  More and more, we (in software, at least) are doing
    less  and less that is new, innovative, dare I say proprietary.  More
    and more, I think, the bulk of "user" documentation will be stuff you
    buy at Barnes & Noble, and not stuff that Digital hires writers to
    write.  In the software arena at least, our documentation will be more
    about the exceptions and extensions to de jure or de facto standards on
    which our remaining software projects will be based.
    
    If that's even approximately true, then our documentation will be
    greatly  reduced in volume, and its threshold of acceptability will be
    judged according to Unix and PC norms, not the historically high norms
    of Digital's proprietary product documentation of the past.
    
    For example, I'm trying to renew old Unix knowledge and become more at
    home on DEC OSF/1.  I've been all over the network to try to get some
    coordinated "getting [re]started" user information.  Finally, I had to
    go to Barnes & Noble and buy a Unix book (for which my cost center will
    no longer reimburse me).
    
    Wanna know about our compilers?  Get C or C++ book from B&N.
    Wanna know about our operating systems?  Get an NT or Unix book from
    	B&N.
    Wanna know about our applications?  Sorry, we don't do applications.
    
    So I think the fact that the perceived (since it's not revealed) new
    organization cannot support the documentation effort as we know it is
    not accidental -- because the documentation effort will be changing
    greatly in its own right.
    
    If this view is even half right, I think the perceived new structure
    can work -- as long as it's run by people who can function in that
    environment.  Whether or not you can take the existing body of doc
    managers (or whatever the plan is) and reasonably expect them to
    function well in a completely different milieu is another matter...
    
    This is just my perception of where things are headed -- not my desire
    or proposal.  I'm at least as ill-informed as any of you reading this. 
    Please don't blame me if it comes true!  :-)
    
    -Mark

    
    re: .0
    
    	As to the basenote, I have always valued a good technical writer as
    part of the product development team. From a services standpoint, they
    are crucial to our success. 
    	I would hope that the role of IDC is expanded rather than
    diminished due to the reorg. I think there's a good case to be made for
    one cohesive unit to bring all information (sales, marketing, technical 
    support, user, service, training, etc.) together, so that everyone is 
    working off the same page. Today it seems these areas are separate efforts 
    with little to no coordination or consistency. Admittedly each area
    has different areas of emphasis (service --> troubleshooting, 
    training --> concepts, etc.) but there is a good deal of overlap between 
    them as well, for instance product features. It would be nice to see a
    set of general information developed that everyone can use, followed by
    development of specialized information targeted to a particular
    audience. IDC/SES has a lot of potential here.
    
    - Jim K   

re .171:

>    Wanna know about our applications?  Sorry, we don't do applications.

re .172:

>    	 I would hope that the role of IDC is expanded rather than
>    diminished due to the reorg. I think there's a good case to be made for
>    one cohesive unit to bring all information (sales, marketing, technical 
>    support, user, service, training, etc.) together, so that everyone is 
>    working off the same page. 

Certainly there is a good case for truly cross-function product development
teams.  And I glad to see somebody can still be optimistic about IDC.  But
information is only one part of product development.  Why not organize product
teams to contain engineering, sales, marketing, tech. support, documentation,
service and training people?

But first, somebody needs to decide whether Digital does software.


Pilar.

    
    re: .173
    
    	Whether it's hardware, software, etc. I would agree. But I also
    think that information shared between the groups can bring them
    together as a team versus a corporate edict which identifies players on
    corporate teams.
    
    - Jim K

re:
>                    <<< Note 3238.166 by CADSYS::BELANGER >>>
>                       -< One way you'll have to change >-
>
>Re: how Engineering will have to change the way they work ...
>
>.45 addresses at least one way engineers will have to change the way they 
>work. If this plan is implemented, you're going to be dealing with 
>contractors who are working offsite. You'd better get used to specifying 
>precisely what you want and writing everything down in specifications. 
>
>Mike
>

If I could specify and write things that clearly, then maybe I wouldn't
need a tech writer.  But most of the time, I know what the tools
is (or should) be doing, etc, but can't explain it clearly.

I'm willing to adjust/change, but there are somethings I don't do very well.
That's why I work with team of people with complimentary skills.

The new Digital way of doing things may only work for the prefect people that
the perfect adminstration of perfect managers decide to keep around.

Alice

SES and IDC are threatening my team's ability to deliver quality
products.

I'll share my observations as an engineering manager at Digital to
explain that statement.

There is a natural ebb and flow in the methods employed to allocate
scarce resources effectively.  Documentation here at Digital is
a good example. One day you look and find that 200 development groups 
are each supporting their own staffs of editors, illustrators, and 
production specialists, in addition to their writers.  You say, quite 
reasonably, "There is too much duplication of effort.  By pooling some 
of the resources, we can be more productive." Thus, IDC was born.

Over time, the pool of resources grows larger. Some infrastructure is
required. Then some additional infrastructure is required. And then
some more infrastructure. You awake one day to find that the tide has
turned the other way -- An enormous bureaucracy has grown in your midst.
And you say, again quite reasonably, "The organization has grown too
large to support the work required." And that's where we seem to be
today.

But how we are addressing the problem? It appears that SES and IDC are
voting in favor of preserving the bureaucracy, and setting the
productive resources free.

Now let's look at the typical documentation needs for a product
development group.  Some projects require a base of shared knowledge
and experience to produce an effective product. Others are equally or
better suited for contracting to third parties. Often, the correct
answer lies in the middle.

For example, in my organization, a core group of engineers and writers
is responsible for the maintenance and development of our products. We
have invested 3-5 years in both our engineers and our writers -- it
allows us to communicate quickly and easily to get our work done.

At times, when a short-term need arises for additional resources, we
hire contractors. Contractors can help to fill critical short-term
gaps without imposing long-term requirements to keep them productively
employed.

So what do we do with our writers when they're not in the throes of
delivering documentation for a specific product release? We do the
same sorts of things that we do with engineers! Often, we have them
work on lower priority writing projects, or we have them survey the
market (or the net!) for tools and ideas, or otherwise support the
work of the group in the myriad ways that intelligent human beings
can support the work of a product development group.

According to the rumors, IDC won't allow us to use learned and
productive people in the future. Instead, they propose (and I'm not
making this up) that I should commission them to commission a
contracting house to commission a writer who likely has not a clue
about the work that we do to get our writing done.  Somehow, by paying
IDC's overhead, and a contracting house's overhead, we'll spend less
than if we paid the writer directly -- Unbelievable!!

I say "according to the rumors..." because, even though I am a client
of theirs, they haven't told me a thing about what they're doing!  It
reminds one of Nixon's secret plan to end the war in Viet Nam, or Joe
McCarthy's evidence that the State Department was full of communists.
With the failure of our "communications" organization to *communicate*,
we are all left guessing.

This is a fascinating strategy. Indeed, if one were writing a communist
fairy tale describing the evils of capitalism, this would be the
story.  Can you imagine?  "The workers be damned!  Save us, the
managers, at all cost!"  Unbelievable.

My request to SES and IDC: Please go away. You have become the problem.

/s/ Andy Riebs
    Alpha Migration Tools

    
    Re .176:
    
    Excellent perspective!
    
> My request to SES and IDC: Please go away. You have become the problem.
    
    Excellent suggestion.
    
    Let us do all we can to make it easy for IDC to go away. Hire the
    people you need directly into your organizaion. Remember the names of
    the writers you can't hire, and establish contact with them when they
    are laid off. We should start a database of former DEC writers that
    other engineering groups might be able to use -- perhaps a separate
    Notes conference of writers with resumes and contact info.
    

RE: .177 - you can do that, plus you can discuss the issue with your
management, and push the issue up the chain. It's been hiding under rocks
way too long. 

Venting here is okay, but it allows the issue to remain out of the
general DEC attention. Ten years ago many issues were resolved simply
because they were aired and discussed openly. It will be hard to ignore
(and be allowed to run someone else's course) if you add it to the agenda
for your next group meeting, your next staff meeting...

We're all in the same company, with all our careers on the line.

Art 

    Anent .167, .168 (Bonnie Schutzman and Tom Powers):  If I had a good
    engineering specification, I could write a decent manual without much
    access to the engineers, whether I sat in the next cubicle or at home.
    However, this is a hypothetical question, because I haven't seen a good
    spec very often (no offense intended).  In these times of reduced
    time-to-market, in fact, the spec is among the first things to be
    eliminated.
    
    Working from product requirements would be nice, but they are one step
    removed from the engineering specs: they describe a product that would
    be nice to have, but engineers must then implement the requests.
    In nearly twenty years I have never seen a requirements document
    implemented 100%.
    
    So both your points are valid in theory but moot in practice.  The real
    question, I think, is whether vending documentation will be successful
    in the development environment we now have, whether the environment
    will change (which I hope happens in any case), or whether vending will
    be unsuccessful.
    
    (The cynical side of me urges that I place my money on another
    scenario: The survivors of outsourcing work heroically to ameliorate
    their lot, costs skyrocket, and victory is declared even as Digital
    tries to hire back former writers about two years from now.  I would
    hope that this does not happen.)

    	The only time I have written anything that appeared in a DEC manual
    it was a documented example programme. I wrote it from the language
    specifications since I wasn't very familiar with the language. This was
    the Coral example programme in the VMS V1.0 system services manual.
    
    	I happened to be working on the same floor as the developers of the
    Coral compiler, and tried my programme out. My conversation with the
    project leader went something like :
    "Can you check that this is correct Coral"
    "Yes, it appears to be"
    "But your compiler crashes with an access violation when I try to
        compile it"
    "Impossible!"
    
    	In the follow up, the compiler bug was fixed before it shipped, but
    it is very embarassing when an example in a manual is both correct
    according to specifications and also crashes your compiler, but that
    could have happened if I hadn't had access to their development machine.
    
    	It could just have easily been my misunderstanding of the language
    specification that caused my example programme to fail, but without
    reasonable contact with the development group it is quite easy to
    produce non-working examples.

.180> In the follow up, the compiler bug was fixed before it shipped, but...
 
This happened on the last project I was on.  I was testing out some software
which should have worked as expected.  Upon closer inspection by the engineer
of the software, this was still true (the software should have worked as
expected... but wasn't).  The cause was traced and a Showstopper QAR was 
entered against the operating system, and was fixed before it went out the door.

Now (tongue-in-cheek), I don't know why a technical writer should be testing
software - isn't my responsibility to write?  Well, less and less these days,
unfortunately - but it isn't even in the fun stuff of testing software - 
we're being taught how to count beans.  On the plus side, we're learning
new skills.  On the minus side, we used to have supervisors who did this,
freeing us up for writing (and testing).  On the plus side, the new skills
we're learning will help us as outsourced personnel.  On the minus side, we'll
be outsourced personnel.   ....

MM

    Also, it isn't necessarily required that the writer be in direct day to
    day contact with a developer for this kind of problem-finding to be
    effective -- as long as there's a channel for reporting and resolving
    the problems.  On my biggest contract, for which I did document
    verification (run the software as described in the manual and note
    discrepancies), every question, problem, and issue was funnelled
    through the full-time writer who was in charge of the project.  I only
    talked directly to a developer a couple of times.  It worked just fine. 
    
    --bonnie

.182 (Bonnie)

Glad to hear there was a full-time writer through which to channel information.

>...document verification (run the software as described in the manual and 
>...note discrepancies)

I think I know you enough better to believe that you run the software
as described in the manual *and then some,* because I always ask myself
something along the lines of "what if I put in unexpected data?" and
try it.  Yeah, my example may work because it is coded properly, but
sometimes the software hasn't taken all possibilities into account;
and maybe I can find those and funnel them through, or maybe I can
test my examples and just my examples.

>It worked just fine. 

I would guess that often it would.

Mark

    re: .183
    
    >>> I think I know you enough better to believe that you run the
    >>> software as described in the manual *and then some,* because I 
    >>> always ask myself something along the lines of "what if I put in 
    >>> unexpected data?" and try it.  
    
    Well, yes, of course, trying to locate omissions is nearly as important
    as making sure what's there is described correctly.  Though in two or
    three jobs of this nature, I've found that the most frequent problem 
    is something that shows up in the documentation that never actually got
    put into the software.  "But that passed all our regression tests.  It
    has to be there!  Oh.  Look.  We coded a stub routine that always
    returns success.  Isn't that special." 
    
    >>> Glad to hear there was a full-time writer through which to channel
    >>> information.
    
    In the situation I was talking about, the "writer" did little actual
    writing.  She outlined the doc set and the individual manuals, arranged
    for contract writers and editors, and for production, and coordinated
    reviews and other writer-developer interactions.  She did write one of
    the manuals, but I'd guess that over the course of the  project, she
    spent about 75-80% of her time managing and only about 20-25% writing.  
    
    --bonnie

>                                                    She did write one of
>    the manuals, but I'd guess that over the course of the  project, she
>    spent about 75-80% of her time managing and only about 20-25% writing.

Wave of the future, it seems.  {heaving sigh.}

    She was pretty happy with it, but then she was getting paid more like a
    manager than like a writer.  I kind of doubt that that's going to be
    the wave of *our* future...
    
    --bonnie

    RE: .181  by TOKNOW::METCALFE 
    
>.180> In the follow up, the compiler bug was fixed before it shipped, but...
 
>This happened on the last project I was on.  I was testing out some software
    
    This happened just this past week on a project I'm working on.  We're
    all set to ship the product out the end of this week and I was running
    the application to snap a new picture for a dialog box they added a
    help button to.  When I re-constructed a query example that I had used
    in the previous illustration, the whole thing did a core dump.  It
    turns out they had fixed some bug that altered something else.  You
    know how it goes.  It had checked out OK with a straight query, but I
    had used something a little bit more complex.  Luckily, they were able
    to find the problem and fix it, but considering where they are going
    with this, it could've been really embarrassing if someone tried the
    example I used in the book and had the same result.
    
    My point is, technical writers need to have access to the software to
    produce a good product.  Documentation is only one part of it.  We're
    the professional idiots whose job it is to get in there and make it
    break.  You can't do that writing from a spec because, on paper,
    everything always works fine.  
    

    Dennis, the proposed outsourcing scheme does not prevent writers in
    Rangoon from getting access to the product being documented. 
    Engineering simply has to ship them copies periodically.

> .188 Title:  Harder, but not impossible

And it comes down to >money<, and the point of diminishing returns for
keeping people on versus vending out, (not unlike the quality versus schedule
dilemma we've had forever).  

My sincere hope is that decisions will be made based on facts rather than 
"I think this will work, the textbook says it should work, therefore I will 
convince myself that this will work, therefore we must work to make it work."

Mark

    RE: .188  by TNPUBS::JONG 
    
    >Dennis, the proposed outsourcing scheme does not prevent writers in
    >Rangoon from getting access to the product being documented. 
    >Engineering simply has to ship them copies periodically.
    
    It better be more often than periodically.  Every time they change one
    little widget in the software, it has the potential for throwing
    something off in an unexpected way.  Unless they send a new copy every
    time they update, then there's a greater potential for error.  
    
    It's much better if you can have access to the developers platform so
    that you are always playing with a full DEC.
    

re cooperation of docos and devos:

the organization gets in the way.  back about 1981, we had writers and
software engineers working together on a product development team.
the build procedure was an example of that integration.
every night: build the software, run the regression tests, including
every example in the books, suck the results of the tests into the
"source" text for the books, build the books, all automatically.

most of the writers i've talked to think that is a good approach.
most of the engineers i've talked to think that is a good approach.
try to make it happen.  listen carefully to the reasons why it can
not be done. draw your own conclusions.

    Good grief! You do go back a ways if you recall the terms 'doco' and
    'devo'!
    
    But I don't get your point: if both parties think it's a good idea,
    then who is supplying the reasons (obstacles) why it cannot be done?
    And what are their reasons?

.192>    But I don't get your point: if both parties think it's a good idea,
.192>    then who is supplying the reasons (obstacles) why it cannot be done?

.191>the organization gets in the way. 

I believe Chuck thinks that overhead and red tape have become
unwieldy and unprofitable and that a return to "development teams"
where devos and docos report to a single overseer would solve the
problem, instead of having devos and docos report to several overseers
and then put together onto a development team.

I state what I believe by permission of Chuck to "draw my own conclusions."

Mark

re: .193

>.191>the organization gets in the way.

And the organizations in question were probably justified during the '80s
as providing cost reduction through economies of scale and better service
through common standards and practices.  Many organizations were built up
to centralize functions on this rationale in the late '80s, but not many
(i personally believe) delivered on their promises of cost savings AND
better service.  Some couldn't deliver on either one.  I think this was
because more diseconomies of scale were introduced than economies, and the
goal of commonality was subverted by politics and the endless negotiations
required in a matrix management culture.

Decentralizing the worker bees in these kind of groups back to the business
unit end users would seem to be the way to go if we're giving more than lip
service to the alleged end of matrix management.
								- paul

          SES's future plan describes a state where work is done by an
          expandable work force, some of whom are direct employees of
          Digital and some of whom are employed by vendors. In this state,
          Digital will always have just the right number of people with
          the needed skills to do our work.

          Our driving principle is that we will keep the people who have
          the skills to define, design, and manage deliverables within
          SES. This set of people includes those with advanced skills in
          writing, editing, and graphics as well as instructional design
          and usability design.

          For our clients, we are ensuring that we have the capability to
          supply them with high quality deliverables on their schedule.
          The operational details for each project will vary depending on
          the needs of the client and the project.

          The SES staff and a number of SES task teams have done a lot
          of detailed planning to prepare for the implementation of this
          new model. The people doing the planning are knowledgeable in
          our work from both the individual contributor and management
          perspectives.

          The planning includes work force planning to decide what skills
          are needed for:

          o  The definition and design of project deliverables

          o  The creation of those deliverables

          o  The management of projects, vendors, and accounts

          We have defined the processes for our partnership with ven-
          dors and clients and for managing and staffing projects.
          The document "SES Future State Design Plan, V1.1" provides
          a guide to the processes. You can obtain this document from
          ZEKE::DISK$USER01:[DALE]FINAL1.PS.

          Currently, implementation teams are working to refine the pro-
          cesses. Pilot projects are providing additional input, and we
          expect further refinement as we work with our clients and inte-
          grate their input as well.

          We also have defined an organizational structure that:

          o  Shares management responsibilities with individual contrib-
             utors, for example, project management and vendor relation-
             ships will be the responsibility of individual contributors

          o  Has reduced layers of management whose function is to set
             strategy and manage SES's business and resources

          o  Relies on teams to accomplish work

                                                                         1

 






          o  Sees value in retaining individual contributors with advanced
             skills such as usability design, instructional design, infor-
             mation set design, graphic design, and technical mastery of
             Digital's products


          1  What Skills Will SES Retain?

          Currently, across IDC we have people with a range of skill sets
          and levels of expertise within one or more of those skill sets.
          That is, we have people with entry level skills in technical
          writing, editing, and illustration, and we have people who
          are experts in designing complex information sets across all
          functions.

          Our research has shown that the lower expertise levels within
          skill sets can be obtained more cost effectively through ven-
          dors than by using a permanent Digital work force. People with
          the higher expertise level skills hold Digital's intellectual
          property (that is, have core skills and technical knowledge) and
          should remain within the Company.

          Outsourcing is a proven industry trend. For example, HP/Apollo
          outsourced it's publications work a few years' ago and has
          maintained quality at substantially reduced costs. In addition,
          we have found that there is a broad vendor base employing people
          with the technical skills needed to support our products.

          2  How Will Individual Contributors Work?

          Many of you have asked how this will work, that is, how will
          people on information project teams work with their counterparts
          in client organizations and how will Digital project teams work
          with vendors.

          The reality is that, within established bounds, how we work
          with client organizations is something that SES will negotiate
          with clients so that we meet their needs. Therefore, writing
          down hard and fast rules for how we work with clients would be
          inappropriate. Rather, I'll write down some likely scenarios in
          the following paragraphs.

          Please remember that these scenarios are models for how work
          is done. We will negotiate the implementation of the model on a
          client-by-client basis.

          2.1  Scenario 1: Complex, Long-Term Projects

          SES has a number of projects that have been ongoing for a num-
          ber of years. Typically, these projects have a high technical
          content and IDC maintains a set of people who have intimate
          knowledge of the product. On these same projects, we have a
          number of folks who write documentation that is less techni-
          cally challenging, for example, updates to existing manuals and
          reference manuals.

          2

 






          For one product set, for example, it is very important to spec-
          ify the overall architecture of the information set because
          it consists of many individual component products. Setting the
          standards, selecting the right tools, determining how infor-
          mation would be shared, and writing the over-arching documents
          are critical, high-level tasks. In addition, the overall project
          management of the effort is critical to providing timely, in-
          tegrated, high-quality information. These are all examples of
          work that would be done by information designers/writers who are
          Digital employees within SES's new model.

          Within the individual components, designer/writers employed by
          Digital would do a similar job of planning the information sets
          and writing the over- arching and highly technical information.
          So far, this is pretty much standard operating procedure.

          So, what's different? Once our information design experts (that
          is, for example, writers with senior level skills) describe the
          information set and establish the product context, we will out
          source the writing of various documents to vendors.

          We will select vendors based on a number of qualifications,
          including:

          o  Knowledge of the product to be documented

          o  Ability to produce high quality information using appropriate
             tools

          o  Ability to deliver information on time

          o  Cost competitiveness

          It is important to note that SES plans to have very close part-
          nerships with a small number of vendors who can invest in people
          with the skills we need and provide the infrastructure (tools,
          etc.) that we need. These are long-term, stable, and carefully-
          managed vendor relationships.

          During the course of the project, writers employed by these
          select vendors will communicate with people in SES and client
          organizations in the normal ways. That is, they will use the
          network to send mail, and they will come to Digital sites for
          meetings as needed. They will have access to the products they
          document under nondisclosure agreements so that we maintain a
          high-level of hands-on product knowledge at the vendor site.

          As we make the transition to the future state, SES will discuss
          with vendors the possibility of having Digital employees be
          employed by the vendor as we move work to vendors. This will
          ensure the continuity of work and skills as well as offering
          continued employment to individual contributors. Thus, people
          employed by vendors may, in fact, be the same people who wrote
          about the product previously as Digital employees. We consider
          this an important part of our negotiation with vendors.

                                                                         3

 






          In any case, writers employed by vendors will work on projects
          on a long-term basis, will be knowledgeable of products, and
          will have working relationships with their counterparts within
          Digital.

          Vendors will also dovetail their processes with ours so that,
          when vendors deliver the specified information, it meets all
          of Digital's standards for quality, submission to the SSB, etc.
          A tight partnership of both people and processes will ensure
          high-quality information products.

          Again, I want to stress that these scenarios are models for how
          work occurs; the implementation details will vary from project
          to project.

          2.2  Scenario 2: Packaged versus Hard copy Information

          Much of the information that we produce now contains a substan-
          tial portion that is integrated into the product, for example,
          context-sensitive HELP that ships as part of the product. Pro-
          ducing this type of information effectively, requires:

          o  An overall strategy for what information will be delivered
             as part of the product, what will be available on-line (for
             example, via the Bookreader) and what will be hard copy

          o  Usability design to ensure a user-friendly interface

          o  A close partnership between a designer/writer and an engineer
             to link the information to the software

          All of the above work, requires core skills and would be done by
          Digital employees.

          The actual writing of the HELP modules, however, could be done
          by a vendor with consultation from Digital designer/writers.
          Writing of books (both hard copy and on-line) would be done by a
          vendor.

          2.3  Scenario 3: EPSS Modules

          EPSS (Electronic Performance Support Software) is a methodology
          for improving the performance of users by providing needed in-
          formation in the user's work context. IDC has produced a number
          of EPSS products including the Sales PowerPack, the Consultant's
          Workbench, the Digital 2100 Fast Track to Information, and the
          INOS Family Information Shelf.

          There are two major components to EPSS work:

          o  Establishing the framework for the information it contains

          o  Collecting or developing that information


          4

 






          Establishing the framework for an EPSS product is an activity
          that requires a highly-skilled person and is work that is core
          to SES. It is the work of deciding what information the user
          needs and how best to make it available.

          Some EPSS products repackage existing information, for example,
          the product data sheets made available through one function
          of the Sales PowerPack. Others require the creation of new
          information. Whether that information is created within Digital
          or by a vendor needs to be decided on a product-by-product
          basis.

          3  Management Roles and Jobs

          The success of the SES plans depend on the effective management
          of vendor relationships and projects. For this reason, the SES
          design document carefully details how the processes for these
          two functions work.

          Traditionally within IDC, individual contributors (editors,
          writers, graphic designers, instructional designers, etc.) have
          worked in the role of project managers while retaining their
          functional job titles. At the end of the project, they may
          continue in a project management role for another project or
          return to work as an individual contributor in their functional
          role. This has been a successful model that has provided a
          development experience and job variety over the years.

          In the SES future plans, individual contributors will continue
          to perform the role of project management and, with appropriate
          training, will also have the opportunity to assume the vendor
          relationship role. Like project management, vendor relationship
          is a role for an individual contributor, not a management job.

          The implication of the new SES structure and our approach to
          project management and vendor relationships is a significant
          reduction in the need for management within SES.

          4  Summary

          The SES Future State is a plan to meet our clients' information
          needs while responding to Digital's need for greater operating
          efficiencies including reduced headcount, reduced infrastruc-
          ture, and greater productivity per employee. It is a significant
          change for everyone in SES and our clients, and it is the type
          of change that Digital needs from everyone to ensure a success-
          ful future for the Company.








                                                                         5

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

================================================================================

	A few questions re. -.195

	1. Core skills?

	         "Our driving principle is that we will keep 
		the people who have the skills to define, design, 
		and manage deliverables within SES. This set of 
		people includes those with advanced skills in
		writing, editing, and graphics as well as 
		instructional design and usability design."


	Then why weren't these skills emphasized in the recent "core
	skills" evaluation administered to the members of IDC?  
	Editing doesn't even appear on that list of twenty-one skills.  
	(I note that the word "management" appears nine times in the 
	skills listed.)  

	"Design" appears 17 times in the descriptions of the 
	"core skills" but that seems like a function that can 
	best be done by the product team as a whole including 
	engineering,  product management,  and marketing.


	2. Entry level skills?

		"...we have people with entry level skills in 
		technical writing, editing, and illustration..."

	We do?  After all the downsizing?


	3.  Vendors already have all the writers they need to 
	    support our products or vendors might want to hire our writers?

		"...we have found that there is a broad vendor 
		base employing people with the technical skills 
		needed to support our products."


		"SES will discuss with vendors the possibility of 
		having Digital employees be employed by the vendor 
		as we move work to vendors."

	Hmmm. I'm having a little trouble following all this.

  
	4.  Won't this way of working require more management than
	    we have now?	       	     	

The following topic has been contributed by a member of our community who wishes
to remain anonymous.  If you wish to contact the author by mail, please send
your message to HUMANE::MODERATOR, specifying the note number.  Your message
will be forwarded with your name attached unless you request otherwise.

Paul, co-moderator DIGITAL


         Sue, the bottom line of your plan is that any writers SES
         does keep will be relegated to "planning" work and will *not*
         be allowed to write documentation. 

         The writers who know and understand their products will be
         *GONE*.

         Engineering will be having fits trying to get a release out
         on time.

         If SES is too expensive, TFSO managers and let the writers
         get on with their jobs!

    Anent .197 (anonymous): Where did you see that?  I saw the opposite!
    (I may be seeing with my heart...)
    
    I too appreciate the open statement about the future state of SES/IDC.
    I also appreciate the very important correction that Hewlett Packard
    did not outsource all of its technical communications business but only
    the (small) portion from the acquired Apollo Computer.

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

===============================================================================

.195!      Our research has shown that the lower expertise levels within

  Really?  What research?

.195!      Outsourcing is a proven industry trend. For example, HP/Apollo

  Proven?  Proven to be what? a trend?  But is the trend a beneficial trend?
  Pet rocks were a trend, and what a success!  Can you say, flash in the pan?
  Do you know that although it may be a trend, many companies STILL employ
  the people full-time and can be proven to produce a profit efficiently?
  Would you like to hear from some writers at HP and Apollo?  We might be 
  able to get some first-hand stories over the Internet.

.195!      knowledge of the product. On these same projects, we have a
.195!      number of folks who write documentation that is less techni-
.195!      cally challenging, for example, updates to existing manuals and
.195!      reference manuals.  (-- Sue Gault)


.36! Hey, I shop at K-Mart for some things whose quality doesn't really 
.36! matter that much to me.  Throw rugs, wastebaskets, stuff like that.  
.36! ;-)  (-- Gerry Fisher)

  What is the real difference between these two paragraphs?  
  Management-speak maybe?


.195!      It is important to note that SES plans to have very close part-
.195!      nerships with a small number of vendors who can invest in people
.195!      with the skills we need and provide the infrastructure (tools,
.195!      etc.) that we need. These are long-term, stable, and carefully-
.195!      managed vendor relationships.

  Does "small number" mean "closed number?"  Does engineering *have* to 
  contract through SES?  Will engineering *want* to contract through SES?

.195!      The implication of the new SES structure and our approach to
.195!      project management and vendor relationships is a significant
.195!      reduction in the need for management within SES.

  Does anyone buy this?  The implication of hiring writers directly
  is a significant reduction in the need for management within SES.
  Incidentally, one could infer from this statement that while the 
  need for management is reduced, the management number (and subsequent 
  overhead) is not necessarily reduced!

.195!      4  Summary
.195!
.195!      The SES Future State is a plan to meet our clients' information
.195!      needs while responding to Digital's need for greater operating
.195!      efficiencies including reduced headcount, reduced infrastruc-
.195!      ture, and greater productivity per employee. It is a significant
.195!      change for everyone in SES and our clients, and it is the type
.195!      of change that Digital needs from everyone to ensure a success-
.195!      ful future for the Company.

   My understanding of this summary is "we're going to do it anyway."

    re:.199
>  Does "small number" mean "closed number?"  Does engineering *have* to 
>  contract through SES?  Will engineering *want* to contract through SES?
    
    	If technical writing is a commodity then it should be purchased
    through the purchasing department. They have the experience (or should
    have) of negociating the best price for commodities.
    
    	If it is not a commodity, then....

  I am not a tech writer, but I work on projects that depend on the services
of tech writers.
  What it looks like to me, in plain language, is that even if we spend $1.50
on contractors, increased engineering man-hours (due to having to work with
off-site, off-Easynet writers), and increased management overhead for every
dollar we save due to reduced employee tech-writer headcount, we are seen as
coming out ahead because we have helped meet the SLT's corporate headcount
reduction goals.
  This thing about writers losing their jobs at Digital and being offered jobs
at vendors who do writing for Digital doesn't really impress me. A few may come
out ahead, but I think the majority will come out behind, losing their senior-
ity, having to commute farther, etc. 

RE:  <<< Note 3238.195 by DONVAN::GAULT >>>-< How IDC Works in the Future >-
>          During the course of the project, writers employed by these
>          select vendors will communicate with people in SES and client
>          organizations in the normal ways. That is, they will use the
>          network to send mail, and they will come to Digital sites for
>          meetings as needed.

How much "research" has been devoted to the examination of communication
between writers and engineers? How much time does the writer spend
communicating with engineers? How does more or less communication affect the
quality of the results? What percentage of that dialog is face-to-face?
telephone? email? hardcopy? How will the geographical separation affect the
costs incurred via these communication chanels? If you cannot answer these
questions definitively, then you have not done your homework nor can you
predict how your plan will impact the work.

When the vendor/writer is located in New Jersey or North Carolina (as some
of the vendor sites are) and the engineers are in Spitbrook, do you *really*
think "they will come to Digital sites for meetings as needed."? Or as they
can afford it?  Now, what does this do to communication and quality?


>          They will have access to the products they
>          document under nondisclosure agreements so that we maintain a
>          high-level of hands-on product knowledge at the vendor site.

What version of the products? The same version of the development software
that the engineers updated the other day? The one with the rearranged
interface? Or the stale field test version that engineering sent them on
TK50 tape last month? Will the writers only work from "stable" versions of
the software? How will having to wait for shipments of updated software
impact the documentation delivery schedule?


-Mike

    The following entry has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to QUARK::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

				Steve






    10 things to improve cost per employee
    
     1. Hold management responsible for cost overruns; not the worker bees.
     2. Hold management responsible for charges for non-business related
        activities.
     3. Hold management responsible for processes that choke production.
     4. Hold management responsible for failures of leadership.
     5. Hold management responsible for mismanagement of Digital resources.
     6. Hold management responsible for meetings that produce nothing.
     7. Hold management responsible for measurable successes and give them 
        what they deserve.
     8. Hold workers responsible for the quality of what they produce; same
        for management.
     9. Reduce overhead and staff more than individual contributors.
    10. Eliminate redundant management structures.
    

    Anent .203 (anonymous): It spoils the purity of your ten suggestions
    that one of them is directed at employees 8^)
    
    I should point out that according to Dr. Deming, quality problems are
    almost always (he estimated 94%!) the result of faults in the system of
    production, not worker errors.  The production system is the
    responsibility of... management.  So there you are: ten for ten.

    RE: .204  by TNPUBS::JONG 
    
    >Anent .203 (anonymous): It spoils the purity of your ten suggestions
    >that one of them is directed at employees 8^)
    
    Managers are not employees?
    

    .205, .204:
    
    The eighth point mentions "workers" and "managers" (one could read this
    as implying that they are two disjoint sets).
    
    Dick

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL

================================================================================

    Remember when people were arguing whether the ratio of
    managers to ICs was 1:14 (Sue Gault's number) or 1:6 (from
    DBDOC information)?  Well, whatever it was, it's a whole lot
    worse now.  Attrits and the last two TFSOs in July and
    September resulted in the loss of 106+132=238 people.
    Only 10 of them were identified as "overhead" reductions, but
    that included secretaries and reqs to replace managers that
    were closed out.

    NONE of them was a manager or coach TFSO.

    As someone said in one of the "information meetings" to tell
    us about the SES Future State plan, it's hard to believe that
    the core competency of IDC is management.  But pretty soon
    that's all we'll have left.

    I cannot confirm .207's numbers.  I've yet to see any numbers from
    this TFSO and, while our attrition rate is quite high (all the more
    power to those finding new jobs!), I haven't had any confirmation on
    those numbers (hear it's about 60 since July, but I know many have given
    notice recently, so it could be higher now).
    
    There are several errors in .207's message.  The first is that we had a
    July TFSO.  IDC did not have a downsizing in July.  At the end of May
    we had our downsizing, with a few "extras" in June.  That downsizing
    included two coaches (first level managers/supervisors).  One of those
    coaches had just stepped down from coaching, so was really an IC, but
    since his job code hadn't been changed yet, he was counted as a
    management cut.
    
    I have heard that two coaches were laid off this time, as well, with a
    similar situation for one (just changed to IC position).  I do not know
    if this (IC move) is true.  It's what I heard.  I also heard rumors of 
    two other coaches being TFSOd, but don't think those two are gone.
    
    In addition, I know of four coaches who have left recently, of their
    own accord, to pursue other jobs.  And I've heard that three or four
    others have stepped into IC positions (which, judging by the two most
    recent TFSOs, seems to place them at *higher* risk).
    
    No leaders have been TFSOd, to my knowledge.
    
    Our ratio is still not good, and we have lost many more ICs than
    managers.  But it's not true that no manager has been a victim of TFSO
    in IDC.
    
         
    Susan

    >>> NONE of them was a manager or coach TFSO.

        Susan's correct.  The statement above is completely wrong. 
        There definitely was one resource coach TFSO'd in May and one
        business coach TFSO'd this week.  In May, my former, "just
        stepped down to IC" coach bought the corporate farm.  (I
        don't know which of this week's casualties were "coaches 
        turned IC," but I'm willing to bet that Susan has that one 
        right too.  This does not seem a good time for coaches to be 
        stepping down.)

    We're all feeling enough discomfort with the way things really 
    are without having misinformation (disinformation?) like .207 
    showing up in Notes conferences.  I hope that future contributors 
    to this thread will keep their emotions in check long enough to 
    get their facts straight.

    Terry

    P.S.  Those of us who were part of IDC don't need to worry about 
          either IDC or SES anymore.  Check your entries in ELF boys 
          and girls.  We're in the Layered Products Group (or 
          something like that) now.  Ain't reorgs wonderful?   ;^)

    Terry and Susan, from what you're written it sounds like perhaps four
    coaches have been TFSOd in the last two IDC layoffs.  That would make
    the actual ratio of overhead reduction 4:234 or 1:58, right?
    
    I hate to see anyone laid off.  But toward the goal of reducing
    overhead costs, would you call this progress?
    
    If .207 is a reflection of what's happening, we are definitely getting
    meaner, but even if your information is correct, we are not, evidently,
    getting leaner.

      Like Susan, I can't confirm or deny .207's information regarding 
      the number of people lost by attrition.  Given the inaccurate and 
      misleading information about coach TFSOs, I must question all of 
      .207's numbers.

      I don't believe that SES has done too much to reduce overhead 
      costs yet.  I do know that a number of coaches are as nervous as 
      the rest of us ... if not more so.

      From what I've read and heard, I'm not even sure that reducing 
      overhead has much to do with the "SES Future State" planning.  I 
      get the impression that someone(s) above Sharon Keillor in the 
      corporate hierachy decreed "Thou shalt downsize n%."  

      Whether or not indiscriminate orders to reduce headcount makes any 
      sense is irrelevant.  (There are plenty notes elsewhere in this 
      conference on that subject.)  Whether or not SES/IDC leadership 
      questioned/fought the order is equally irrelevant.  How to survive 
      and continue to provide services in the context of that sort of 
      "blood letting" is relevant.  

      I haven't been able to come up with any viable alternative to 
      outsourcing and contracting.  I don't like what's happening, but I 
      can't see any other way.

      Terry

The latest "new word" for those voluntarily leaving is "attrit"
as in "She is an attrit."  To my surprize "attrited" is an acceptable
word.  Now, with the new word we can say, "contributors to attrition
are attrbuted to attrits that have attrited."

The current plan for those who don't "attrit" and those who don't 
get a package for leaving (TFSO), is to transfer employment to
a vendor company.  It is unclear whether this is some sort of
purchasing agreement, like Oracle buying Rdb, or a horse of a different
color.  We're not even sure who the vendor company or companies are,
except a place called SEI which ran a Globe Ad recently which sparked
an entry in the IDC notes conference wondering if we were going to 
have to "apply for our own jobs."  

What is clear is that those who do not accept the "choice" (also referred 
to by some others as an ultimatum) of transferred employment will be 
"terminated."  Termination has not yet been clearly defined as 
being with or without severance (TSFO).

The new documentation strategy ("Future State") may have the effect of
the tail wagging the dog.  Documentation is a service and support to
engineering.  Let me be quick to add that it is an integral part of
the product; coding software is a service and support of the product
-- the product is the sum of these things and more.  Engineering 
processes are being pressured to change and improve.  Indeed, we should
be looking for continual improvement.  Outsourcing documentation will
force a change in the way engineering provides the documentation piece
of the product.  Will this forced change be the improvement engineering
is looking for?  Apparently, the tail (IDC) is part of the "team" who
thinks it will be the improvement the dog (engineering) needs.

Some of the other "big" companies are trying outsourcing; some companies
are returning from this strategy because they are tired of seeing the
knowledge and training walk out the door at the end of the contract,
requiring retraining.  Oh, vendors these days are looking out for specific
tools and skill sets (using sophisticated computer screen tools that 
scan your resume for buzzwords).  One upshot of this was to have a
recruiter call someone I know from California asking him about a Visual Basic 
programmer's position.  He told him that he was a writer with VB familiarity
and not a programmer.  The recruiter was surprised because he hadn't read
the resume - the computer spit it out as a prospect based on the buzzword,
and the recruiter was trying hard to fill the niche requirements of the
client.

Some companies are trying the contracting route, test driving their 
employees before offering them a full time position.  Some companies
also realize that "permanent" employment is attracting many of the top
people who are looking for a sense of belonging.  Almost no one considers
"permanent" employment to mean anything more than a stint of 5 years or
fewer.

Digital documentation services in its various forms and functions will
be attempting a mix of these approaches with the bulk (it seems) of the
change being a transfer of employment to vendor companies.  Unless it 
means food on my family's table, I intend to work for Digital, or another 
employer of my choice (not ultimatum).

Mark

>The latest "new word" for those voluntarily leaving is "attrit"
>as in "She is an attrit."  To my surprize "attrited" is an acceptable
>word.
    
    Had she left involuntary, it would have been "She got OJed!".  :^]
    

>      I haven't been able to come up with any viable alternative to 
>      outsourcing and contracting.  I don't like what's happening, but I 
>      can't see any other way.

Terry,

  Some people have suggested that writers report to engineering managers 
directly.  It is >nearly< as simple as that, with (a) editing and graphics
support to be worked out, and (b) overhead being transferred to engineering
management instead of a documentation hierarchy.  Some writers require as
little or less handling than some developers.  The other thing that 
engineering would have to deal with is the trouble of replacing a writer
when they needed one.  Depending on the need and area of engineering, 
hiring contractors might be better, but for those who need and want to 
keep talent on their team, what are the reasons for a writer to not
work directly under an engineering manager?

Mark

    I'll have to be relatively quick with this reply, because I have a lot
    of work to do.
    
    In May, IDC downsized 91 people, 2 of whom were coaches, and 4 of whom
    were other overheard positions.  Our total number for that quarter was
    120, because we also counted the 29 people who had left since the end
    of Q2'FY94.  Of those 29, 2 were coaches and 1 was a leader, and one
    other was overhead.  In addition, IDC ended 24 contracts.  This is all
    from a published memo.
    
    We still have not been given any official numbers for Q1'FY95, I have
    heard that we 48 people to attrition (officially - that is, they gave
    notice and terminated employment before the *downsizing* occurred) and
    45 to downsizing.  It is rumored that 2 or 3 coaches were part of the
    downsizing, but we will not know until they come out with an official
    memo.  I think it took two weeks to get the memo following the May
    downsizing, so we'll probably get it next week.
    
    Again, the numbers are not good, our ratio (IC to manager) has not
    improved significantly, and the future looks dark.  I can see no
    careers here, but maybe I'm caught up in the gloom and doom of seeing
    long time friends and colleagues leave.  (Sigh)
    
    Then again, Enrico Pesatori promised the results of the Shared Services
    Task Force during the first week in October.  That's next week.  Maybe
    his team will have something different to say.
    
    Susan
    
    PS:  Mark, the problem with engineering hiring writers directly is
    related to the headcount issue.  If we just move people to other
    segments of Digital, then we haven't reduced headcount.  Like Terry, I
    believe that this is *really* a headcount reduction exercise, having
    little to do with finding a better way to do business.
    
    PPS: Terry, we have rolled up into Layered Software since Strecker
    announced that Sharon would report to Demmer.  They changed our ELF
    entries from Engineering Services to Layered Software in early August,
    I think.

re: .214 

hm, I see a circle here.

Our group once hired/maintained/etc our own documentation
group.

Then, in the name of standards, etc, they were taken
from our cost center and put in a documentation cost center.

If I'm not mistaken, at least one, if not more, of the people
were part of the original group that were once part of
our group...

Ain't politics wonderful!

Alice 

>Our group once hired/maintained/etc our own documentation
>group.
>
>Then, in the name of standards, etc, they were taken
>from our cost center and put in a documentation cost center.

Well, we've been learning "to team" and "to partner" with each other.
There is no reason that standards can't be kept through a less
structured committee of documentation folk across related products.
We have an existing corporate style guide, which is a document
that gets updated from time to time.  Also, we are adopting and
adapting to new strategies for documentation.  Where there is a
need for oversight of documentation across related products, this
is an issue that a manager, at a suitable level, can drive.

The idea of centralized documentation may have been a good one,
just as a business needs to adapt to different management structures
as it grows.  The danger in growth is bureaucracy, and SES/IDC is 
attempting to address the cost issue in the best way it knows how.
However, another problem with growth is that many people have their
opinions as to what is the best way of dealing with the bureaucracy.

Mark

>Ain't politics wonderful!

Nope.  Sigh.

I've been following this thread in a rather superficial way but there are many 
inter-related issues and I'm confused.

Can someone provide me a concise answer to the question, what problem is being 
solved here? 

Thanks,

	Richard.

>Can someone provide me a concise answer to the question, what problem is being 
>solved here? 

My answer, bearing in mind that I'm an individual contributor and my opinions
are my own and may have little or no bearing on what management may say about
the same subject:

The problem is that Digital wants to reduce costs.

 o Documentation is thought of (by many) as a cost separate from engineering,
   and the Cost Centers and segregation has helped this notion. (IMO)

 o Documentation is costing a significant chunk of change to engineering
   organizations who have documentation figured into their budget.

 o Documentation management has been trying to trim and justify costs for
   at least two years, beginning with reorganizations from Corporate
   User Publications (CUP) to CUIP to IDC to SES/IDC.  (This is since my
   tenure with Digital;  nearing 8 years)

   - the latest IDC push is to redefine the business (again) with an emphasis
     on "outsourcing."  The current plan is to transfer employment of most
     writers (and other documentation-related personnel) to outside "vendor
     companies."  These companies will then sell the writer services to
     Digital.  The savings to Digital, I guess, is that the vendor company
     pays the benefits of the writers, and in some cases, provides the
     workspace and/or equipment.  ("Have PC, will travel.")

   - objection to this plan is around questions about (a) the brain drain,
     (b) real cost savings, because it is thought that IDC management will
     perform the "managing" of getting and placing writers from the vendor
     company, and if the cost of a writer includes overhead for Digital 
     Management and for Vendor overhead, will there be a real cost savings,
     even in the long run, (c) is this a better plan than reducing the
     workforce, keeping valued writers and editors (etc.) and eliminating
     overhead from the documentation organization.  I.e. placing documentation
     ICs under engineering management.

  Naturally, it is easy to see where the lines get drawn.  I happen to think
  that some oversight of documentation standards (and like issues) should be
  maintained.  Some overhead is necessary in oversight, equipment, and
  evaluation.  However, I do not think this justifies the existence of a
  redundant management structure.

The problem is not necessarily being solved though it is certainly being 
addressed.  The contention is how it is getting addressed and whether it
solves problems or creates new and potentially bigger problems.

Mind you, I'm just an IC, so my interpretation of events may be rather
limited.  I know many of the ICs would welcome more communication from 
our management.  We get a little, but when questions are asked for 
clarification, there is little follow up (if any).

Well, that's pretty lengthy, but I hope it was concise enough to give you
an idea of what one person thinks is going on in SES/IDC.

Mark

So, if the problem requiring a solution, is simply to reduce cost then it ought 
to be possible to test various approaches (in-house, out-sourced, etc.) with 
relatively simple financial models. These would yield a range of cost structures 
which would have different implications for quality of output, responsiveness, 
time-to-market, etc. Those factors could then be optimised for cost.

I apologise for not reading back through the preceding 200+ replies, but - 
hasn't this been done?

	R.

>I know many of the ICs would welcome more communication from 
>our management.  We get a little, but when questions are asked for 
>clarification, there is little follow up (if any).

I need to retract this, now.  The following E-Bit was distributed
after (but not because of) my note (.219).

MM
===============================================================================
From:	CASDOC::META::EBIT_NEWS "27-Sep-1994 1234" 27-SEP-1994 12:46:28.78
To:	@EBIT
CC:	
Subj:	Ebit 1016, SES Future State Program


From:	VAXUUM::DONVAN::GAULT        27-SEP-1994 12:31:20.55


Subj:	SES Future State Program


                        SES FUTURE STATE PROGRAM


    INTRODUCTION AND BACKGROUND

    It is Bob Palmer's requirement that Digital focus and invest in those
    areas key to its core business.  To achieve this, Digital will 
    provide quality services and products driven to be Best in Class by 
    the very competitive nature of the supply base.  In addition, the 
    outsourcing of services will relieve Digital of a fixed cost of both 
    capital and human assets and move the expense to that of a variable model 
    capable of responding to capacity changes in a more effective manner.  
    This is the driving force behind SES' organizational design.

    The services that are being outsourced are likely to be but one component
    of the total deliverable for most projects.  This cost will be represented
    as an element of the total cost of the project.  The mix of resources used
    to deliver a complete project will be transparent to the client.  The
    effective use and tracking of the supply base will afford us the
    opportunity to see, and be assured of cost effective quality
    deliverables.  This has been our experience with the outsourcing of work
    accomplished in the area of Localization.
 

    PURPOSE OF THIS DOCUMENT

    The following is a Question and Answer format prepared by the SES   
    Communications Task Team.  The purpose of this document is to help 
    you, our clients and SES members, understand the impacts and benefits 
    of the changes that are occurring in our organization. 
    





    QUESTIONS & ANSWERS



Q:  Are parts of SES (such as IDC, ISE, ETS) being spun off or 
	outsourced?

A:  The SES organization is NOT being spun off.  While SES is
    implementing an outsourcing strategy, this does not mean that 
    all of the SES organization will be outsourced. This strategy 
    allows us to outsource commodity tasks and services that can be 
    provided to our clients more cost effectively through an external 
    supply base.  However, we do not intend to outsource key skill areas.     
    We will retain and develop internally those value-added skills and     
    knowledge areas which provide a competitive advantage to Digital's 
    products and services. 



Q:  Are clients going to lose the experienced individual contributors 
	(writers, editors, artists, etc.) in whom they have invested
	time, money, and energy?  Can clients hire these individuals 
	directly?

A:  SES will protect clients' investments by retaining and developing 
    its core technical competencies internally.  The potential of losing 
    individual contributors does, in fact, exist.  However, our commitment
    to provide our clients with services and products that meet their needs 
    will not change.

    While there is a very close link between the work of engineering and 
    the creation of information sets, information set design is not 
    the core work of an engineering group.  Therefore, given SES's 
    commitment to producing quality work on time and within budget, and 
    given the current headcount constraints within the company, there is 
    little advantage for engineering groups to hire their own writers, 
    editors, graphic artists, etc.  Engineering management and SES 
    management have both concluded that it is in the best financial 
    interest of engineering to focus their funding on engineering 
    development while using the expertise and resources of SES to provide 
    services in the most cost effective manner for Digital.

    We recognize that in some instances, clients may hire individuals 
    directly, but this is not advantageous for most client groups for 
    the reasons stated above.



Q:  Will clients continue to get their deliverables on time?

A:  Yes.  The SES goal is to continue to deliver high-quality products 
    and services while we reduce headcount and related costs.  The new 
    organization will have project and account managers responsible for 
    ensuring that all deliverables are on time and at the expected level 
    of quality.  



Q:  Will clients experience any disruption of service?

A:  No.  Our goal is to avoid disruption of service to our clients.
    Client satisfaction is the centerpiece of our organization.
    The people with whom our clients have worked in the past are still
    representing the needs of these clients.  



Q:  How will SES address quality?  Will clients' expectations for 
	quality be met?

A:  Quality is one of the three constraints we place on the work to be
    outsourced (the other two constraints are time and cost.)   We will 
    not lower our quality standards.  We will work with each client to 
    define the expected level of quality and work with vendors to ensure 
    that they deliver quality.



Q:  How will clients be charged for services/deliverables that are 
	outsourced?

A:  SES will continue to negotiate with clients for deliverables
    (online  help, system management, internationalization, etc.) and 
    will deliver on these commitments within time and budget.  That is, 
    we will continue to use the dollars for deliverables model that has 
    been used for several years.  Under this model, we will provide clients 
    with work at our cost.  SES is not a profit center.  



Q:  Will the SES outsourcing strategy cost clients more?

A:  We do not expect this outsourcing strategy to cost our clients more 
    money.  The SES outsourcing strategy will provide Digital and SES 
    clients with more flexible capacity.  Our goal is to lower costs while 
    maintaining, or increasing quality.  ISE has been using this model 
    for the past 2-3 years and has realized significant savings with 
    improved delivery time and quality.

    We have talked with a number of Digital's competitors who use an
    outsourcing model.  They have all experienced a reduction in costs
    through outsourcing.  



Q:  With whom will clients be dealing to ensure that their needs are 
	met?  Can clients request a specific SES interface?

A:  SES will assign an account manager to each client organization. 
    Each client will deal with the assigned account manager for all
    SES services needs. For some clients, this person will be the same 
    contact as in the past.  In other cases, it will be a new person. 
    The account manager will be a business partner to the client.

    The key difference is that in all cases the account manager will be
    the client's contact for all services. No longer will a client have 
    a different contact depending on the service required. The account 
    manager will be a single point of contact dedicated to delivering 
    any and all the SES-provided services needed by the client.  This 
    account manager will have the training to work with the client to 
    define a complete portfolio of services and the authority to get the 
    services when and how they are needed.



Q:  Will the account manager understand the clients' business and all 
   	the services currently offered by SES?

A:  Each account manager will be fully knowledgeable about all SES services.  
    The added value to the client is that the account manager will also 
    understand the clients' business to a level where (s)he can provide 
    the most appropriate set of services to meet the clients' needs.  
    All SES account managers will have ready access to technical resources 
    as a supplement to their service expertise.



Q:  Which SES resources will remain?

A:  While we are outsourcing commodity services, we are retaining and 
    developing our core competencies.  Resources related to the delivery of
    our stated core competencies will remain.



Q:  Do clients have the option of selecting the vendors for their 
	products/services/deliverables?

A:  In most cases, SES will take the responsibility for vendor 
    selection.  To insure economies of scale, SES will be working 
    with a select number of vendors who can best meet Digital's needs 
    to be cost effective, competitive, and profitable.  As part of this 
    process, we will work with selected vendors to establish efficient 
    processes and methods to develop and deliver products and services 
    according to our clients' specifications.

    An added benefit is that SES will be able to use the volume of 
    business we will manage to leverage discounts and other advantages 
    from vendors.  This strategy will allow us to ensure the highest 
    value at the lowest cost for our clients.  In situations where vendor 
    selection is critical because of unique client requirements, SES 
    account managers will work with the client to ensure that these needs 
    are addressed.



Q:  What if a client does not want to deal with SES?  Do clients have a 
	choice?

A:  Clients have always had a choice about whether they will do
    business with SES groups.  Most clients do not want to make the
    investment to maintain SES services as core competencies within their
    groups.  They have traditionally depended on SES groups to do that.

    SES's goal is to provide Best in Class services to Digital and to do so
    in the most cost effective manner.  We can provide the economies of scale
    and cost effective processes that will keep development costs low and
    eliminate redundancy, resulting in improved margins on Digital products.



Q:  What voice do clients have in all this?  Can clients exert any 
	influence?

A:  Yes, clients have influence.  Client satisfaction is paramount to 
    the SES organization design.  The account manager and the client are
    business partners.  The account manager will represent the client's
    needs in SES.  Checks and balances in our design, such as vendor 
    qualification, project approval, and project acceptance help ensure 
    satisfaction and influence for our clients.



Q:  How will engineering find out that their writers are being
	outsourced?

A:  The account manager will include engineering managers in our
    outsourcing plans.  This includes giving them an opportunity to
    provide input on what work will be outsourced as well as the schedule
    for reducing the permanent workforce.



Q:  Why will SES exist if Digital is moving away from matrix
	management?

A:  Groups within SES have never been matrix-managed.  Our relationship 
    is that of a service provider to a client.  In SES's case, we offer a
    service with the added advantage of knowing the processes and markets 
    of Digital and our clients.  That knowledge allows us to provide added 
    value over outside service providers and to be a better business partner 
    with our clients.



Q:  Isn't the SES reorganization causing people to leave Digital?

A:  SES's attrition is happening in the larger context of Digital,
    which is having a hard time at the moment.  We have tried to be clear
    and honest with people about the downsizing in Digital.  We also have
    been careful to communicate to people exactly what the key skills are
    that SES will retain. 



Q:  What does it mean to be part of the Systems Business Unit (SBU)?

A:  It means that we are part of a larger organization that will
    generate profit for Digital by selling hardware and software systems
    and software applications.

    It does not mean that our ability to provide services across Digital
    will be limited.  The notion of host management for various functions
    is a strong one in Digital.  The SBU will host manage SES while we
    provide services to clients across Digital.



Q:  One of the skills that IDC individual contributors have that is 
	highly valued by engineering is the ability to listen to an 
	engineer and turn an engineering orientation into a user 
	orientation.  Will engineering lose this valuable skills as 
 	work is outsourced?

A:  No, engineering will not lose access to that skill.  SES will
    provide it in two ways:

        - The individuals retained by SES will have the ability to
        listen and make the translation to user needs.  This is an
        important aspect of information design.

        - Individuals working for vendors will also have this skill and
        will have access to engineers for these discussions.

Effective Oct 3, all the IDC/SES writers within Digital 
Semiconductor are removed from IDC/SES and transferred as 
headcount to their respective engineering/working groups. 
Writers were given a choice either to stay in IDC/SES or transfer.
I believe all the approximately 15 writers involved chose to transfer.  

The transfer was initiated by Ed Caldwell, VP and head of Digital 
Semiconductor and a direct report to Bob Palmer. The action was taken 
after he had met with IDC/SES representatives and failed to be convinced 
of the advantages of the SES "future state" for Digital Semiconductor 
writers. I believe other factors in the transfer were to remove 
the writers from the environment of great uncertainty produced within SES 
and to stem the resignation of writers. So, if your relationship with 
your engineering/working groups warrants it and your management is 
willing to consider your situation and go to bat for you, it is possible 
to be transferred out of IDC/SES and to continue as Digital employees 
attached to the groups for whom you do writing.

I am a writer for SEG/CAD in Digital Semiconductor and one of those 
being transferred.  The transfer was one of the major factors in my 
staying with Digital and turning down an offer from another CAD company. 
I am personally grateful to Ed Caldwell and others in management who 
considered the writers' situation from both a humane and 
business perspective and, as far as I am concerned, did the 
right thing.

Jane

Just a few hours ago, the OpenVMS documentation group learned our fate.
This is what we were told:

o Engineering will not pick up the writers

o Harbert "believes in" outsourcing

o Writers are to be placed on one of two lists:
    (1) those who will remain in Digital
    (2) those who will be "moved to a vendor"

o Writers being moved to a vendor:
    (1) The Vendor has veto power over an IC: that IC
        will get a TFSO package from Digital 
    (2) The IC does not have veto power over the vendor:
        ICs refusing the move will be terminated without
        a TFSO package.  Basis for termination is "not doing
        your job" (to go to the vendor).
        (It seems the vendor will [inadvertently] determine 
         who gets the TFSO package.)

o Time frame: Q2; if not possible, then after Dragon/Zeta in Q3.

o The vendor(s) have not been identified (to ICs), although SEI (Globe Ad 
  a few Sundays ago) is one very likely candidate.

Mark

    NEW Orangebook section 2.11, issued 22-aug-1994, might be of interest...
    
    While I'm on the subject, another change that caught my eye...
    
         4.06     Group Medical Care Plan - Replaces pages 1 and 2 to
                  acknowledge pending policy changes, ...
    
    Dave

>    NEW Orangebook section 2.11, issued 22-aug-1994, might be of interest...

Can you post?  I don't have an (the) Orange book.

    VTX ORANGEBOOK
    Select New/Revised
    
    The topic in earlier replies probably falls under 'exclusions/exceptions'
    in 2.11 but the policy is interesting from the trend/direction it sets.
    
    Dave

--	ICs refusing the move will be terminated without
--      a TFSO package.  Basis for termination is "not doing
--      your job" (to go to the vendor).


Can they do this? Since when was being -required- to terminate one's
contract and accept employment with another company part of one's
job description? 

Surely if Digital no longer has a need to employ you people, then
you are "redundant" resources, and should be given the "redundancy"
package. I can see the justice in offering you a choice between
redundancy and this new employer, but not between getting fired and
this new employer. 

The way you describe the deal also indicates that only those writers
who are deemed to lack the requisite skills will actually get the
redundancy package. Anyone with the right skill profile will be denied
redundancy regardless of Digital's decision that they no longer need
to employ them to do their job. 

    
    Re .222:
    
    A hat tip to Ed Caldwell, who obviously still knows how to do the right
    thing.
    

.227>

Well, it was described in terms of a baseball player being traded to
another team.  You go, or you don't play.  I did happen to think of
George Herman Ruth being traded to New York earlier this century.
When was the last time the Red Sox won the World Series?

The bottom line is that it wouldn't have been everyone's solution
but it is IDCs solution.  And when you consider that self-preservation
is a natural instinct, it is probably very magnanimus to provide a
transition to continued employment.  Think of it.  (1) the people
making the decision stay at Digital (maybe), (2) Digital saves money
by not paying out TFSO money, (3) employees have continued paychecks
(it is not yet known how the salary and benefits will map to the
new job shop).  Can I see possible drawbacks for these reasons?
Sure I can; quite a few.  But from the perspective of a manager in 
charge of these decisions, I can also see myself as striking the best 
compromise, saving people's livelihoods, and saving Digital money in
the short term, etc.  The truth will likely be somewhere in between 
these perspectives.

Commodity #196796 
for the time being

How can someone be fired for not wanting to leave? 
How can not wanting to leave be construed as any form of disciplinary
transgression?
How can people who are no longer required by this organization, and
who do not have the option to stay with this organization be denied
redundancy payments? 

More generally, isn't it illegal to declare someone redundant
and then hire someone to do their work? 

Am I being misled by Mark's jaundiced way of summarising the note?

>Am I being misled by Mark's jaundiced way of summarising the note?

I certainly hope it wasn't jaundiced and perhaps some other VMS writer
can confirm if that's what they heard in the meeting.  I asked "on what
basis will a person be terminated?" (if they refuse to go to the vendor)
and the reply was "for not doing your job."  I added "my job to go to
the vendor?"  And there were nods of heads in the affirmative.

But please don't take my word for it.  Perhaps someone else at the meeting
will confirm or clarify this.

Mark

    As an about-to-be-Quantum employee, I have seen the wording in our case
    (which was the sale of a business, "all" employees included), and that
    wording went something like:
    
    1. Offers will be made by the new company
    2. Employees accepting the offers must voluntarily resign from Digital as 
       part of the accptance process (or retire, if they are eligible).
    3. Employees receiving offers, if neither accepting the offer nor retiring,
       "are presumed to have resigned voluntarily" (my quotes; also, my memory,
       sorry, too busy to dig up the original source).
    
Those of you with legal minds might have a field day with this.

    
    Re .232:
    
    But your situation is dictated by a business deal that DEC has struck
    with Quantum -- a deal that is well publicized (see note 3253) to
    contain an agreement on the transfer of certain employees as part of
    the business.
    
    If the IDC situation is in any way comparable, the following questions
    should have answers: Has a "vendor" (.223) been selected for IDC work?
    Who? Has a business deal been struck with that vendor? What were
    the terms of that deal -- was the vendor offered certain assets and
    employees, and a certain amount of future business, in return for cash
    money? Has the vendor described the salary and benefits it will offer
    to the affected employees?
    

    These sound like good questions to ask Sharon Keillor at tomorrow's
    SES meeting... is anyone going?
    
    

.233>

Yes, more answers are supposed to be forthcoming, such as who the vendor is
or the vendors are.  Apparently, there is still some negotiation to be 
done, which is why the whole thing isn't out in print.  Our meeting was
an appreciated effort to inform us (VMS writers) of the current situation.

.232> "are presumed to have resigned voluntarily" (my quotes, my memory)

Yes, and the quotes I gave were memory of the word-of-mouth answers
given at our meeting.

There are still enough questions to adopt a wait and see attitude with
this.  However, there was enough information to pass along.  Many of us
in documentation will be "moved" to a vendor company.  Some of us will
stay behind, still working under SES and not under engineering.
The lists are supposedly created from business needs and core skills
but there are other intangibles that go into the decision-making process.

MM

    >> "are presumed to have resigned voluntarily"
    
      Certainly could not be done under UK law, and I doubt that it is
    legal under US law, although employee protection seems to be less
    strong. Mr. Abrahams (reply .230) is, I believe, in the UK (like me),
    and I am sure he is also correct that an employer here cannot make someone
    involuntarily redundant, then hire someone else to do the same job; the
    situation may be different in the US. However, I would expect the matter
    of transferring your employment to be covered by contract law, and
    unless your contract states that you can be transferred to another
    employer, then I would be surprised if they can force you to go. You
    have an employment contract with Digital; unless the contract says they
    can, Digital cannot transfer it to another undertaking without your
    agreement. If you refuse to go, then they either have to fire you or keep
    you. It sounds as though somebody is trying to pull a fast one, hoping
    that most people will agree to go and stay employed rather than have to
    fight through the courts to get TFSO payments (aka redundancy money in
    the UK). Get any terms in writing, and have a lawyer look at it before
    signing anything, if in any doubt.
    
      I would be surprised if the baseball players do not have transfer
    terms written into their contracts, English football players certainly
    do. 10% of a million pound transfer fee is a very tidy sum. Their
    contracts are very different from yours and mine, and large amounts of
    money usually change hands when they are transferred.
    
    Ken          

    re: .320
    
> How can someone be fired for not wanting to leave? 
    
    Incompetence by reason of insanity?
    
    
    -MarkD

    So, how did the SES meetings go? The SES meeting for this afternoon
    has been rescheduled.  

At ZKO, presentations by Sharon Keillor and David Popp lasted for 55 minutes 
of 90.  The first respondant requested that the "front end be tightened up
for the following presentations to allow more Q & A."  Someone on the
LT agreed and thanked the respondant for the suggestion.  35 minutes
was not nearly enough time to address all the questions.

From the street view, nothing new or important was communicated, although
Sharon Keillor did emphasize that she was "holding these meetings because 
she deeply believes in and appreciates communication."  I'll not post the 
less favorable comments I've heard about the meeting.

What >I< heard:

The LT has done its best to respond to a changing industry and through
much effort they have come to believe that this is the best business
solution for us all.

Because this message was already received, I also thought that very little
new information was communicated.  Perhaps there were others in the
audience who had not heard what the "Future State" holds for most of us.

The Q&A (as I said) was way too short.  The Babbage conference room was
standing room only.  The one question that caught my attention went something
like this:

Q: Is there a process by which a vendor can get on the approved vendor list?

A:  "Succinctly, yes."  But we are not looking to deal with 47 vendors.

My interpretation:  We have a process, but it is a closed process.

How did it go in LKG?

Mark

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL


	    From:    Spoc

            To:      Captain Kirk,  Enterprise

            Subject: SES Meeting Report


            SES presented the following reasoning:

            o  The World is changing so we need to change. That's why 
	       we worked very hard to come up with this plan. [This 
	       point was made a repeatedly although I understood it 
	       the first time, Captain.]

            o  We can't afford to be good at everything, so we'll 
	       limit our efforts to being good managers. We know how 
	       to save money through buying Digital's product 
 	       documentation from vendors. This is a core competency. 
	       This is where we can add value.

            o  Vendors know how to make a profit creating documentation 
               for Digital and other companies. Vendors will hire some 
	       of our workers to do this.

	Analysis

            This Seems illogical, Captain. If a vendor can make profit 
	    using Digital workers, why can't SES? Do these vendors 
	    know how to run the business better? If they do, wouldn't 
	    it be logical to hire the managers from a vendor to 
            manage SES's workers, and make the profit at Digital? 
	    Then Digital could be a vendor to companies who want an 
	    outside source for their documentation. The only
            missing element is the management expertise.  And yet, 
	    Captain,  management expertise is presented as a compentency.

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------

       In the U.S., in the absence of a specific contract (for example,
       a union contract for a group of workers or a personal services
       contract for an individual), people are employed on an at-will
       basis.  Basically, this means that either the employer or
       employee can terminate the relationship at any time.

       State and/or federal laws do regulate layoffs, especially when
       the number of layoffs exceed a specific number (usually 50
       people).  These laws, part of the same statutes that goven
       unemployment compensation, are intended to ease the financial
       burden on someone who has been laid off.  The expectation is that
       the individual who has been laid off is looking for and will
       accept reasonable work -- that's one of the conditions of
       collecting unemployment compensation.  

       So, the legal theory would presumably be that an employee who
       does not accept a job with another company forfeits his/her
       rights to those benefits that are intended for those who have
       been laid off.

    

.241 Anonymous

>       The expectation is that
>       the individual who has been laid off is looking for and will
>       accept reasonable work -- that's one of the conditions of
>       collecting unemployment compensation.  

Okay.  Now I understand better.

So, some of the people who were looking for (wink wink) and accepted 
reasonable work (wink wink) shortly after receiving their TFSO money
(wink) were within proper expectations.  And we all know (wink) that
you cannot volunteer (wink wink).

Having never been on unemployment (before), I don't know what constitutes
the definition for "reasonable employment."  I suppose being sold to a
vendor company is reasonable.  It give new meaning to the axiom "You
can't fire me!  Slaves have to be sold!"

Mark

  On September 27, 1994, the OpenVMS documentation group was assembled in
  the Hustvedt conference room.  The summary of this meeting is posted in 
  3238.223.  Excerpts from this note and one other follows below:

3238.223 ==============================================================

o Writers being moved to a vendor:
    (1) The Vendor has veto power over an IC: that IC
        will get a TFSO package from Digital 
    (2) The IC does not have veto power over the vendor:
        ICs refusing the move will be terminated without
        a TFSO package.  Basis for termination is "not doing
        your job" (to go to the vendor).
        (It seems the vendor will [inadvertently] determine 
         who gets the TFSO package.)

3238.231 ==============================================================

  I certainly hope it wasn't jaundiced and perhaps some other VMS writer
  can confirm if that's what they heard in the meeting.  I asked "on what
  basis will a person be terminated?" (if they refuse to go to the
  vendor) and the reply was "for not doing your job."  I added "my job to
  go to the vendor?"  And there were nods of heads in the affirmative.

  But please don't take my word for it.  Perhaps someone else at the
  meeting will confirm or clarify this.
..........................................................................

  At this meeting, I was asked to seek clarification of the "termination"
  from Pat Fleming, of Human Resources.  I sent mail on September 30,
  1994 and received an AUTO-REPLY from WATCH_MAIL indicating that job
  related questions should be referred to Georgina (WECARE::GIRARD)
  Girard while Pat was out (until 11-OCT-1994).  So I forwarded the same
  question to Georgina.

  While I do not have permission to to post the entire replies, I'll 
  summarize it here to pass on the information I have to date.

  (1) Georgina provided a synopsis of what "SES is trying to manage with
      respect to [my] questions:"
     
      "employees...have the choice of accepting a transfer to a vendor 
      or resigning from Digital.  There is no TFSO given in these
      circumstances."

  (2) I asked why it was considered "resigning" if the "choice" to
      transfer is not made by the Digital employee?

  (3) She replied that transfer of employment "potentially holds more 
      benefits (in the large sense) than a TFSO package and no employment
      .....therefore the position of the company is resignation (not firing) 
      if the transfer is not chosen."

  (4) I responded that choosing to not to transfer does not imply choosing
      to resign from Digital, and that Digital will be forced "to determine 
      whether the employee is to remain [or be] severed. ...  The employee 
      declares the intent to continue as an employee."

  (5) I was advised to let my manager/coach know if I did "not want to be
      considered part of an outsourcing opportunity."

  (6) I affirmed that "I am not interested in getting the package. 
      However, if I choose not to go to a vendor, then I should be a Digital
      employee without work, hence requiring a financial assistance package."
      I declared my intent to summarize this information and asked if she 
      preferred me to keep her mail messages intact to ensure that I quote
      her properly.

  (7) She replied that public conversations at planned meetings are scheduled 
      for next week.  "Having a verbal conversation may be better."

  (8) I replied, "Why is it part of the future state plan to force a 
      resignation, if a Digital employee chooses not to move to a vendor?  
      Isn't there a simple answer to this question?"

[ End of correspondence as of this posting; awaiting further clarification
  or the planned meetings at which I hope to get an answer to report. ]
............................................................................

re: .243

>  (7) She replied that public conversations at planned meetings are scheduled 
>      for next week.  "Having a verbal conversation may be better."

Yeah, so there isn't any record of what they may tell you:-(

Bob

          SES is making fundamental changes in the way it accomplishes
          work for our clients throughout Digital. Whenever aggressive
          change occurs, there is a period of time in which we work with
          our clients to help them understand what is happening and how it
          will benefit them. This was true when CUIP/DCD became IDC, and
          it is true as we move to the SES Future State.

          The business leaders and coaches in IDC, with strong support
          from others within SES, have been working with our clients over
          the last few months to help them understand how we will work
          with both clients and vendors in the new state, what SES's added
          value is, and how it will benefit our clients. As a result of
          this work, the vast majority of our clients have endorsed our
          new model and plan to continue our business relationships. SCO
    	  chose a different route.
           
          Our clients are interested in obtaining data on the effective-
          ness of our plans. As we gather that information, we will share
          it with clients, the SES organization, other organizations (like
          the PCBU) that are outsourcing work, and the management of Digi-
          tal.

My question has nothing to do with endorsement, Sue.

Outsourcing may be a wonderful thing... for some people, as well as 
for clients.  Individual successes will determine this.  My question
has to do with an employee who declares that he will not "resign"
from Digital but also chooses not to be transferred to a vendor because
the Digital employee feels that the "fit" isn't right.

I'll provide the mail I posted in IDC regarding just this issue.  It
sounds like hyperbole, but this actually happened to me this past summer.
==============================================================================
From:	TOKNOW::METCALFE "I am a task force.  06-Oct-1994 0913"  6-OCT-1994 09:13:52.63
To:	WECARE::GIRARD
CC:	METCALFE
Subj:	RE: Please clarify in Pat's stead

  Georgina,

  Before I post a summary of the information you have provided for me,  I
  want to explain why this issue is so important to the welfare and
  dignity of people at Digital.

  Last summer, I interviewed with a small company in Georgia and by all
  indications, I was a lock for the position, including relocation, and
  other things.  However, I interviewed in a place that looked like a
  poorly renovated U-Haul storage facility.  I interviewed with a man
  who kept a Rottweiler in his office.  The man told me that the company
  used their own employees in their advertisements.  Then he pointed out
  a picture of one the female employees whose bust size was enhanced for
  the picture because her natural size was considered too small for the
  ad.

  Now, as I said, I could have gone to work for this company.  But what
  if I was forced to go to work for this company?  How would you feel if
  you were given the choice to work for this company, or be "terminated"
  or "forced to resign?"

  And it does not matter whether any of the vendor companies have
  Rottweilers or enhance their employee's "inadequate" body parts for
  advertisement photos. The point is that there are companies that do not
  provide a good "fit" for some people - whatever the reason.

  I still want to know why SES says a Digital employee is not entitled to
  a severance package if this person chooses not to work with a vendor
  and this same person declares his intent to continue with Digital (i.e.
  does not resign).

  Mark Metcalfe
===========================================================================

The vendor companies may be WONDERFUL.  And SES may think it is doing the
best thing for its employees, even if they don't know what the best thing
is for themselves.  If this is the case, it is highly presumptious.

The point is that people are given an ultimatum, not a choice.
Forcing a "choice" (no matter how beneficial it may seem to some),
is no choice at all.

Perhaps if given the choice between going to the vendor or accepting 
the severance package was offered, most people would "endorse" going to
the vendor.  But the current plan is to terminate without severance 
those people identified for the vendor who choose not to go without
regard to the reason.  It is a matter of welfare and dignity of those
people who have given their talent to Digital.

Mark

    sort of like...

    "You have the choice of accepting the new position, or of
    voluntary resignation without a Transition Package."

    Nuts and Bolts...

    	The company determines what you ultimately do!

Didn't some large company just lose a class action suit by former employees
over this issue (mandatory transfer, no severance package)?

								- paul

    Yes.  Former Blue Cross and Blue Shield data processing people. 
    Apparently BC&BS decided to outsource its data processing work to EDS.  
    The employees were told that if they didn't take the jobs (which
    happened to be in the Boston area), the company considered them to be
    voluntarily resigned.  
    
    Some of the people filed a class action suit which they won.  The
    judge basically ruled that a company must offer severance if the jobs
    go outside the company, but does not have to offer severance if the job
    is an internal transfer.  As a side note, BC&BS appealed this
    ruling...they lost the appeal.

    re: 
>>    			but does not have to offer severance if the job
>>    is an internal transfer.  
    
    I am puzzled by the logic in the above, but perhaps it explains the 
    creation of new Orangebook policy #2.11, "Change of Job Requirements"
    
    Dave

>          Our clients are interested in obtaining data on the effective-
>          ness of our plans. As we gather that information, we will share
>          it with clients, the SES organization, other organizations (like
>          the PCBU) that are outsourcing work, and the management of Digi-
>          tal.

Isn't this being done pretty much en masse?  If the plan turns out to be
ineffective, won't it be too late for the clients to do anything?

    Anent .249: If it's illegal for Blue Cross/Blue Shield, how is it legal
    for Digital?

    
.251> Isn't this being done pretty much en masse?  If the plan turns out to be
.251> ineffective, won't it be too late for the clients to do anything?
    
    Sure seems that way. Perhaps that's one factor that caused Ed Caldwell
    (VP, Digital Semiconductor) to express a lack of confidence in the
    "future state" by hiring doc people into his development organization.
    (See .222)
    
    I sure wish other managers would see what's coming and do likewise.
    

    It isn't.  It's called intimidation.  Which is one reason why some are
    not getting a straight answer.
    
    charlie

What would happen to a writer who was asked to be transferred to a vendor
and refused to be transferred and refused to resign?

Chuck

    According to what Mark reported from the OpenVMS Doc meeting in .243, you 
    will be terminated (a.k.a. fired) if you refuse to be transferred.  
    
    If we know that Digital is about to do something illegal, what's the
    proper channel to go through to alert someone responsible who can stop
    it?  According to VTX LAW, maybe it should be: 
     
    SEC & Corporations Law:
    Gail Mann
    DTN 223-2206
    
    I'd hate to see more bad press for Digital!  Let's stop this now 
    before it becomes some big NLRB issue.  We already know from the Blue
    Cross decision mentioned in .249 what the outcome will be.
    
    
    Aren't there cases where if a company knows something is wrong and does
    it anyway that it then becomes liable for triple damages??  Gee Mark, 
    maybe you shouldn't say anything and then get a triple package!  
    
    It's too bad that we couldn't stop this just because it's a bad 
    business idea.  <sigh> Why do things always have to crash before 
    someone just does the right thing?  
    
    
    Me, I'm a writer on my way over to Oracle as part of the database deal.  
    I'll be a valued member of the development team reporting to an engineering
    manager.  It's interesting that at our first meeting of all the individual 
    contributors (engineering, doc, support, etc.) the Oracle V.P. said that 
    documentation was an integral part of the product set and of course they 
    wanted us too!  We told her that we were all slated to be replaced by 
    contractors and vendors, possibly before this deal was consumated.  She 
    sure seemed surprised!  She said, "we do not want that."  She looked at 
    Bill Strecker, who looked at Chuck Rozwat, and Chuck said he'd take care 
    of us.
    
    So while we're commending Ed Caldwell for having the foresight to hire
    writers directly to protect his business, also throw in some kudos for 
    Beatriz Infante, VP Oracle Corporation: Open Systems Division, and Chuck 
    Rozwat, new VP of Oracle's Rdb Products Division.  To answer the original 
    question posed in this stream, they all value tech writing (and graphics 
    artists, and editors, and application specialists, and secretaries, and 
    everyone else who contributes to putting a product on the shelf.)
    
    Sad that everyone values us except our own IDC/SES "leaders."
    
    
     -- Jeff H.
     "Information Engineer"

Here is this engineer's answer to the original question asked by the 
title of this topic:

	Technical writing is valuable.  The technical writing
	*orginzation* (SES) is not only not valuable, it is a
	downright hinderance to getting the job done properly.

--PSW

re: .243
    
>  (7) She replied that public conversations at planned meetings are scheduled 
>      for next week.  "Having a verbal conversation may be better."
    
    To misquote Forrest Gump:
    
    When someone says "Having a verbal conversation may be better", hold
    onto your pocket book.

	A couple of years back, my group (InfoServer Engineering) was happy
with our tech writer but we were afraid he'd be swapped out by his
management so we did the only sensible thing.  We hired him.  We gave him
management responsibility for a couple of the smaller projects in the
group.  When he expressed an interest in learning C, we helped him learn
and assigned him a bunch of the low priority bugs in the system so he could
get his feet wet on real code. 

						--Doug

>  (7) She replied that public conversations at planned meetings are scheduled 
>      for next week.  "Having a verbal conversation may be better."

I suggest that each group takes minutes.  Perhaps even more than one
writer can take minutes to ensure accuracy of what is said.  Get clear
definitions and definitive answers.  Why should these be difficult to 
get?  It shouldn't.  

And as technical writers, you should be able to discern unclear statements
that do not say only one thing.  Tacit approval of implied meaning is
as binding as agreeing to something in the open.

A resignation is an action YOU bring about, by (silent) AGREEING that you 
resign or by actually resigning verbally.  If they have a different definition,
then they should be able to make it clear and to make it legal.

It matters who initiates an action.  And it matters what is said, and
left unsaid because people then assume by certain actions or statements
what you mean.  There is an old axiom that says, "if it isn't written
down, it hasn't been said."

What happens if a person does not tranfer and does not resign?
The answer I have gotten so far is, "he resigns" and "I believe
I've answered your question."  I have responded, "no, you haven't.  If 
a person does not resign how does the company say he resigns?"

o Firing requires company action for "cause" and is initiated by the company.

o TFSO requires company action because your job is going away and is initiated
  by the company.

o Resigning requires an individual's action and is not precipitated by 
  a cause of another (unrelated) action.  It is initiated by the individual.

Mark

re Note 3238.246 by TOKNOW::METCALFE:

>   The point is that there are companies that do not
>   provide a good "fit" for some people - whatever the reason.

        Mark,

        I am entirely supportive of your position;  however, I just
        want to point out that there are never any guarantees that
        even if you stay in a given position in a given company that
        that company will continue to be the kind of place at which
        you would choose to work.

        I'm sure that for many Digital itself has become a very
        different kind of company and a very different place to work
        (no Rottweilers or employee body part upsizing in ads just
        yet :-).

        Bob

    Mark, I presume that if you do not accept the outsourced position
    and state that you do not resign, the next logical step would be to 
    fire you for insubordination.

> I suggest that each group takes minutes.  Perhaps even more than one
> writer can take minutes to ensure accuracy of what is said.  Get clear
> definitions and definitive answers.  Why should these be difficult to 
> get?  It shouldn't.  
    
    How about audio or video recorders at the meetings? I wonder if they
    would object?
    
    

>    Mark, I presume that if you do not accept the outsourced position
>    and state that you do not resign, the next logical step would be to 
>    fire you for insubordination.

For starters, I don't intend to be a test case and never had.  This is
not what prompted my question.  What prompted my question is how SES could
force me to resign?  I can only resign of my own volition.  I can't imagine
many who would choose TFSO over outsourcing anyway, but that isn't the
point either.

Again, it is a matter of dignity and welfare.

Dignity for people to trust them to make the right decision for themselves
  instead of attempting to force a "choice."  A forced choice is no choice.
  It demeans people and makes them chattle.  Grant us respect to make 
  intelligent choices for ourselves.

Welfare for those people who find that the vendor is not a suitable
  place for them to work and so take their chances finding a job on
  the outside.  People who no longer have work at Digital are given
  a financial severance package to assist them in finding a suitable
  job; to tide them over while looking.  They are not "considered
  to have resigned" (which I don't think they can MAKE you do).  They
  are Digital employees, and more importantly adult human beings with
  skill and talent.

Ask the question when Pat Fleming or Georgina Girard comes to your meeting.
Record the answer.  Make sure its a straight and clear answer.  If it isn't,
consider why.  If someone finds themselves to be a "test" case, they can
know that people have been over this road before.

There SHOULD NOT be an adversarial relationship between management and
individual contributors.  I warned about this more than a year ago, and
the chasm has gotten wider and worse.  Have we lost the integrity of
honesty and clarity?  Have we lost the respect of people?  Have we lost
the trust and togetherness of being Digital employees?

I find it very troubling.

Mark

From:	META::EBIT_NEWS "07-Oct-1994 0911"  7-OCT-1994 09:48:24.65
To:	@EBIT 
CC:	
Subj:	Ebit 1021, SES Communication Meetings

From:	VAXUUM::DONVAN::GAULT         6-OCT-1994 16:04:53.73


Subj:	SES Commuication Meetings



As a followup to the SES Communication Meetings, Human Resource 
representatives Pat Fleming and Georgina Girard will hold separate 
Q&A sessions about the outsourcing plans. Specifically, they will address 
questions that people may have about transfer of employment to a vendor. 
The sessions will be held at the following times and locations:

Wednesday, Oct. 12, 1-2:30 in the Babbage Auditorium at ZKO1

Thursday, Oct. 13, 9-10:30 in the Julia Ward Howe CR in LKG1-1/G07

Monday, Oct. 17, 9-10:30 in the amphitheater in MRO1-3/D8

If you have questions or topics that you'd like to see addressed, you can
send them in advance to Georgina Girard (WECARE::GIRARD).

>    How about audio or video recorders at the meetings? I wonder if they
>    would object?
    
I think minutes would be sufficient.  I once had an engineering manager
grill me in a meeting some years back.  She brought in a tape recorder
and plopped down on the conference table (the whole engineering group
was there), and proceded to ask me many questions about a management
issue between documentation and engineering.  After the grilling, which
lasted at least 20 minutes, she got up and checked her tape recorder.
She commented that the batteries didn't seem to be working and that
she'd miss the code review (scheduled next on the agenda) which she 
claimed to intend to record.  She had never brought a recorder before
for any code review before (or since to my knowledge).  Some of the
engineers are still around and some of you know the story behind it all.
There may be legal ramifications regarding recorders.

Another quick note.  A friend of mine in public schools had a tape
recorder brought into a meeting.  She immediately stopped the meeting
from being started until the school *also* got a tape recorder...
for the record.

Again, I don't think we need to become paranoid, just AWARE.  I'm willing
to grant the benefit of the doubt and report the findings.  Sometimes,
I will offer an opinion on this, but when information is lacking, we're
often left to speculate.

Mark

    Once you've written up your notes/minutes send them to management with
    a note saying:
    
    "This is the record of information, decisions and agreed actions that
    we have made.  If the record differs from your understanding of the
    meeting will you please advise what changes should be made."
    
    The object being to get to an undisputed statement of record.

+-----------------------------------------------------+-----------------------+
| Termination                                         | Effective: 22-AUG-94  |
|                                                     | Section: 6.01         |
+-----------------------------------------------------+-----------------------+
                                                        Screen  2 of 38
 PRACTICES

  DEFINITIONS 

   There are six types of terminations:

     o  Voluntary Resignation - A termination initiated by an
        employee for his or her own reasons.

     o  Retirement - Termination when an active employee retires
        from the Company.  (Age 65 or age 55 with 10 years of
        service.)

     o  Company Release - A termination by the Company due to the
        employee's poor job performance occurring after completion
        of procedures outlined in the Personnel Policy 6.21,
        Corrective Action and Discipline, poor attendance, end of
        a temporary assignment, refusal to accept another
        comparable job, etc.

     o  Company Discharge - A termination initiated by the Company
        when an employee violates a work rule, is guilty of
        serious misconduct including performance on site of any
        act which is illegal, absence for three consecutive work
        days without notifying supervisor, failure to return from
        an approved leave of absence/disability, etc.

     o  Company Separation -  A termination initiated by the
        Company as a result of an approved Workforce Reduction or
        Plant Closing Program.   This also applies to terminations
        that result from the lack of a regular assignment when the
        employee returns to work from disability or the employees
        decision to refuse a change in employment status (see
        Personnel Policies 4.09, Disability, Absence and Return to
        Work and 2.06, Employment Status).

Note: also see policy 2.11
	Dave
    

Before I go off on my long weekend to Maine, a story:

A scientist was performing an experiement on a frog that jumped when 
commanded.
"Jump!" said the scientist and the frog jumped.
"1. Frog jumped 8 feet."

The scientist performed surgery on the frog cutting off its front right leg.
"Jump!" said the scientist and the frog jumped.
"2. Frog jumped 5 feet."

The scientist performed surgery on the frog cutting off its front left leg.
"Jump!" said the scientist and the frog jumped.
"3. Frog jumped 2 feet."

The scientist performed surgery on the frog cutting off its rear left leg.
"Jump!" said the scientist and the frog jumped.
"4. Frog jumped 3 inches."

The scientist performed surgery on the frog cutting off its rear right leg.
"Jump!" said the scientist and the frog did not jump.
"JUMP!" shouted the scientist several times, but still the frog did not
jump.  So the scientist faithfully recorded the following:
"5. Frog went deaf."
===========================================================================

We've gone from CUP to CUIP to IDC and to SES.  We've lost a supervisory 
staff that knew our day-to-day operations, knew what "the client" needed, and
knew what Documentation needed to get the job done.  We've lost our ability
to compete because a "loaded" writer cost over $59/hour. (I'd like to see
a pie chart on this number, wouldn't you?)  We've lost some of our dignity 
to make decisions through an "empowerment" that is little different
than putting a dog on a leash and telling it to run as far as it can.
We've lost our respect from (and for) people who treat us like children 
or mental incompetents telling us that "it is going to happen anyway" and that 
detracters and naysayers are in "denial."  And I've come to the point
where I believe that when an analysis is done, the scriptwriters won't
say that the frog can't jump because it no longer has legs with which to 
jump. 

Mark
Just my opinion/your mileage may vary

    I wish I could say that this string surprized me.  Sadly, I've seen
    far too many verbal gymnastics used to sugar coat other unpalatable
    actions.
    
    Asking them what they mean by "resignation" misses the point.  I
    think it was the caterpillar in "Alice in Wonderland" who said
    "Words mean whatever I want them to mean", and so it is in a case
    like this.  Remember, we're dealing with a management that chooses
    to fire people for "solicitation" but who aren't willing to tell
    anyone what they mean by "solicitation".  Watching whom they fire
    for it doesn't seem to lead to a consistent definition, either.
    But I digress.
    
    I suspect the real point of all this is humanitarian.  :-)
    After all, the more this behavior goes on, the better all of
    the outside vendors will look compared to staying, right?
    
    Sigh.  I wish that were really a joke.  What I really think is
    that someone decided that it's essential to reduce this headcount
    and are carrying it out as effectively as they can.  I don't have
    the facts to judge the decision to cut headcout.  But bad means are 
    not justified even by a good end.  Honest communication and a wee
    bit of flexibility would make this a lot less unpleasant all around.
    	
    	Luck,
    	Larry
    
    PS -- So why am I still here?  Good co-workers and a local management
    that values us.  Such things still exist at Digital!  LS

>     I think it was the caterpillar in "Alice in Wonderland" who said
>    "Words mean whatever I want them to mean"

It was Humpty Dumpty.

                  <<< VAXUUM::W7_:[NOTES$LIBRARY]IDC.NOTE;3 >>>
                                    -< IDC >-
================================================================================
Note 263.103              SES Future State Information                103 of 103
GUESS::CARRASCO "I'll worry about that `just in time'"  17 lines  11-OCT-1994
12:51:07.31
                       -< National Labor Relations Act >-
--------------------------------------------------------------------------------
re .93, .97:

I talked to my uncle about this last night -- he's a lawyer who specializes in
labor-management relations.  I described our management's position that a worker
who refuses a "transfer" to a "vendor" has "voluntarily" resigned and is not
eligible for severance pay.  He said this would be legal only if the "vendor"
were owned by Digital.  He said anybody this happened to should immediately
apply for unemployment benefits, and would have a he** of a case for a
class-action suit for unfair labor practices under the National Labor Relations
Act.  Finally, he said we have rights under the NLRA to "protected concerted
activity" just as if we had a union.  Protected activities incluce picketing in
parking lots, passing out leaflets in the cafeteria, talking to each other, and
posting notices on company bulletin boards, as long as we do it on our own time
(e.g. lunch hour).


Pilar.

As a followup to the SES Communication Meetings, Human Resource 
representatives Pat Fleming and Georgina Girard will hold separate 
Q&A sessions about the outsourcing plans. Specifically, they will address 
questions that people may have about transfer of employment to a vendor. 
The sessions will be held at the following times and locations:

Wednesday, Oct. 12, 1-2:30 in the Babbage Auditorium at ZKO1


Minutes will be taken at the meeting.

>> The sessions will be held at the following times and locations:

>> Wednesday, Oct. 12, 1-2:30 in the Babbage Auditorium at ZKO1

    
    ZK-Centrism!!! 
    Also, the following times and locations:
    
    "Thursday, Oct. 13, 9-10:30 in the Julia Ward Howe CR in LKG1-1/G07
    
    Monday, Oct. 17, 9-10:30 in the amphitheater in MRO1-3/D8
    
    If you have questions or topics that you'd like to see addressed, you
    can send them in advance to Georgina Girard (WECARE::GIRARD)."
    
    
    [Above excerpted from Ebit 1021]

>   Wednesday, Oct. 12, 1-2:30 in the Babbage Auditorium at ZKO1
    
    Babbage is too small for this meeting. The last SES meeting held in
    Babbage was overfull, with people sitting on the floor and standing 
    in the stairway.
    
    The meeting should be held in the Cauchy conf room instead.
    

>    The meeting should be held in the Cauchy conf room instead.

I agree.  I had to stand on tip-toes and peer between people
at the last Babbleage meeting.  Let's move it to Cauchy and
accomodate all who want to attend.

Mark

    I agree, too.  Yesterday, I called and reserved the Cauchy conference
    room for this meeting and immediately sent mail to Georgina Girard and
    Pat Fleming suggesting that we move the meeting to that room because
    they should expect a lot of people.  No response.  --S

If Babbage fills up, we'll propose to move the meeting to Cauchy.
I'll bring a sign, in case we move.

Mark

Sounds like Empowerment, to me. Isn't this what we're supposed to do?

Art

Well, I didn't need my sign.  There was enough room in Babbage, some
standing in the back, but also some empty seats.  The meeting lasted 
until just after 3.  Pat and Georgina stayed as long as there were
questions.  Minutes were taken.  I'll bring out the issue about
"resignation" but hope to get a more complete report posted here later
by someone who took more copious notes.

It is "the practice of the company when employment is refused" to 
terminate the employee.  It is "standard practice" checked out by
the lawyers.

Many people asked numerous questions surrounding this question, but
responses were on the order of "I guess so; I don't know."  and "I'll have 
to find out."

At the end of the meeting, we asked for the name of a person who has the
decision-making power over the "standard practice" and to have the "standard
practice" put into writing for us to see, and verify.

We were advised that if you felt that "over my dead body would I go to 
a vendor" you should let your coach know.

When asked how many people would rather be TFSOed or transferred, the
response was that we have no information on which to base that judgment;
we know what TFSO means, but we do not know what going to the vendor means.

We were told that the vendor does not have the right to refuse a POD
("Planfully Outsourced Digit"), just as an employee does not have the
right to refuse employement from the vendor and get a TFSO package.
However, if there was a case where the vendor and the employee just really
didn't hit it off ("*really hated each other*"), they would try to "work 
something out."

Vendor selection will likely be done "within two weeks" "by the end of 
next week" and "completed by mid-November."  "Nobody gets moved to Kansas."

It is not possible for a person to be chosen by more than one vendor.
-------------------------------------------------------------------------
There were other questions and other answers.  These were the issues dealing
with the Vendor and the Individual Contributor as it relates to the vendor.

I hope someone will also post more of what happened at the meeting.

Mark

>It is not possible for a person to be chosen by more than one vendor.

"OK, everybody whose last name begins with A through M get in the line to
my left..."

>>It is not possible for a person to be chosen by more than one vendor.
>
>"OK, everybody whose last name begins with A through M get in the line to
>my left..."

Vendor placement is based on "product" or "project" and not alphabetical
order.  Although, my name does begin with the letter M.

>    "Did someone in Legal specifically approve the plan to terminate, without 
>    TSFO, those employees who declined to go to work for a vendor? And if so, 
>    what was their name?"

Contributed to me by a Digital employee and stock holder who is NOT in SES.
Pat or Georgina?

Mark

    It's not clear to me that all folks will be permanent hires of the
    vendor with benefits etc.  What happens when a writer becomes a 
    contractor to the vendor? Will all folks transferred to a vendor have
    to be permanent hires or is SES arranging contract opportunities as
    well?
    
    Darlene

[THIS IS CROSS POSTED IN THE IDC CONFERENCE]
    
10/12/94

SES Communications Meeting Follow-up

[NOTES: Most questions and answers are paraphrased.  I no longer take 
shorthand! ;-)  Where I was able to actually capture words, I have used 
quotes.  In some cases, questions will not have the intensity in writing 
that they had when asked at the meeting.

Also, there were many questions that I didn't get down, and in some cases I 
got the question, but not the answer.  This is not a comprehensive record of 
the meeting.]

Georgina Girard and Pat Fleming met with NH area SES employees to talk about
what it means to have employment transferred to another company and what 
work will look like in the future state.  They agreed to answer all questions
that they can, and try to get answers to questions for which they don't have 
answers.

The group seemed most concerned with the vendor situation, and Georgina and 
Pat seemed to have more information about this topic, so this is where we
started.

Vendor selection will be in the next two weeks, "give or take a few days;" 
probably the end of next week.  At that time, Requests for Proposals will 
be submitted to those vendors.  It is hoped that selection of the "approved"
vendors will be in mid-November.

Q: What does "transfer of employment" mean?

Before answering this question, Pat announced that "ground rules" had to be 
set:  there are no promises.  They would like to place a lot of people with 
vendors, but it may not be possible.  Downsizing will also occur.  "Sharon 
has been working hard at putting it [downsizing] off so they can transfer 
people."

It was stated that no one will be moved.  Vendors are expected to look for/
set up office locations close to the work.  They will be getting a "ready 
made workforce" and are expected to set up operation here (New Hampshire 
and Massachusetts).

A: SES/HR looked for viable vendor candidates by investigating the vendor's 
capabilities, plans, balance sheet, etc.  Is Digital doing work that meshes
with the vendor's current work?  Will they have something to gain by having 
the skills of current Digital employees?  And they look at vendors who can 
provide comparable compensation.

Comparable compensation is not just salary (and salary can be, and sometimes 
is, reduced in transfers of employment).  HR examines health benefits, services
(such as dependent care and medical reimbursement accounts), pension, 401K, 
etc. and decides if the vendor is "in the ball park."  Both companies review
benefits and salary to see if the match is viable.  In some cases, the 
transferred employee can end up with better benefits.

There are advantages to a transfer of employment over quitting and starting 
anew elsewhere.  In a transfer of employment, the service date is transferred
as well.  The employee is not starting at day one to accrue vacation and 
other benefits, and pre-existing medical conditions cannot be considered.
Since service dates are also transferred, anyone who is fully vested at 
Digital would be fully vested at the vendor company.  If the employee being 
transferred has less than $3500 (this was from Georgina's memory banks - she 
wasn't positive she had the right figure) in the pension plan, there is a 
"cash out" of the plan.  If the employee has more than $3500 in the pension 
plan, s/he must wait for retirement to get the pension dollars.

Digital's lawyers in MSO review every step of the plan.  If an employee should
"lose" benefits in the transfer of employment, there can be a "bridge 
payment."  Pat was quick to note that this bridge payment is never more than 
TFSO.  [NOTE:  While no one asked, I think this would be in the case of a 
significant reduction in benefits, such as medical or dental.  Georgina and/or
Pat, can you clarify?]

Q: How do we know that we won't have our employment transferred only to find 
ourselves laid off by the vendor in a month or two?

A:  The contracts with the vendors specify a period of time for guaranteed 
employment.  The original premise was to ask for one year of guaranteed 
employment.  It may be for a shorter time than that in reality.  However, 
part of the agreement is that if the vendor has no work prior to that 
guaranteed time, the vendor will pay a severance package comparable to 
Digital's. [NOTE: Is this comparable to Digital's at the time of the 
transfer?  I didn't write it down, but that's the impression I have.]

Georgina stated that "it doesn't make sense" to transfer employment to 
someone who will just lay us off.  Someone in the audience commented that 
Digital would then not have to pay severance.  Georgina explained that a 
transfer of employment is very costly (all those lawyers, maybe! ;-) and 
it would actually be less expensive to just TFSO everyone.

Q: Will I have to interview with the vendors?

A: No, not really.  Some vendors want to "interview" or have conversations 
to ensure a proper match.  However, that is not encouraged.  This is a "deal."

[NOTE: This is when things started to get more emotional.]

Q: If, after talking to the vendor, the vendor doesn't want to hire me, then 
I get a TFSO package, right?  [Nods]  But if *I* don't like the vendor for 
some reason and decide that I don't want to work there, you're saying that 
I've resigned?  How can that legally be so?

A:  "Standard corporate practice" is that the person is requested to resign. 
If the person refuses to resign, then the person can be terminated with cause,
*they think.*  Georgina will go find out all she can about "standard 
corporate practice" and this issue.  However, they (SES/HR) have checked 
with Digital's lawyers, who repeatedly say this is "legal."  This has been 
done in Digital for 13 [I think] years.  It's nothing new.

Q: But this time there is no sale of product.  This time, you're selling 
people.  Has this been done before?

A: We are not selling people.  Yes, it has been done before.  We sell off 
services all the time.  Look at HR!  [NOTE:  I didn't ask this at the time, 
but now keep wondering about this.  When we sell a service, don't we usually 
sell all of the service and transfer most of the associated employees?  In this 
case, we are keeping some of each function in-house, so we can't really say 
that we selling off all writing or editing, or ...]

Q: Comparable salary and benefits are not everything.  What if a vendor you 
choose has a corporate ethic that I cannot subscribe to?  If I don't want to
work there, you're telling me that I do not get a package of any kind?  [Nods]
You can bet I'll hire a lawyer fast!  Are you aware that Blue Cross/Blue Shield
lost the class action suit against them for a similar situation?

A: HR ran the Blue Cross/Blue Shield class action suit note from the notes
conference by the lawyers and they still say this is legal because it is within
standard corporate practice.  "We don't have a set of options outside of
Digital's standard practices," said Pat.

A member of the audience commented that "standard acceptable practice" is 
not the *only* acceptable practice.  There are other options that are legal, 
and those should be considered.  At this point, we were starting to go nowhere 
fast.  Arguing ensued, and it was clear that Pat and Georgina had no answers 
to these questions - at least no answers that satisfied anyone.  We were 
asked if the issue is that we should get a package if we don't want to go 
to the vendor?  Yes!

Q: Will there be different vendors in Massachusetts and New Hampshire?  

A:  Not known.

Q: Is it possible for more than one vendor to want to hire me?

A: No.  

Q: Why not?

A: It will be done by product and work.

Q: What role will coaches play in who goes to a vendor, who gets TFSO, and 
who stays in SES?

A: Georgina and Pat told us to make our wishes known to our resource coaches 
and let them know what works for us.  We should be meeting with our resource
coaches, individually or in groups, *now*.  Resource coaches can tell us 
whether we have skills that are likely to be needed by SES in the future 
state, whether we're likely candidates for transfer of employment, or whether 
the product engineering group has requested that we be placed on a list to 
be kept because of technical abilities needed for their key projects.

At this point, Georgina and Pat informed us that only about 100 people will 
be outsourced in Q2.  This was news to most, if not all, of us!  We were 
under the impression that much greater outsourcing would take place this 
quarter.

Someone commented that some resource coaches are unwilling to have this kind 
of talk with individual contributors because of all the uncertainty.  They 
may be unemployed themselves, soon.  At this point, coaches started speaking 
up.  One resource coach commented that she knows what skills she believes 
SES will need, and she knows which of her team have those skills.  However, 
she has no idea how many people SES will need with those skills or how many 
people there are in SES who already have those skills!  So, what can she really
tell someone?  A business coach commented that he might know who should be 
kept for technical or project ability, but doesn't feel that his word carries
any weight with resource coaches, so what can he do to help people?  Another 
resource coach commented that the coaches all really want to help, but there
is only so much they can do with so little information.

There were comments about this being a headcount reduction exercise, to which 
Georgina replied, "Headcount reduction is *not* the primary drive for this 
model."  Pat commented that our fate is tied to the financial viability of 
Digital.  IN PAT'S OPINION, there will be at least two more years of pressure 
to downsize.  SHE BELIEVES that the business unit will continue to pressure 
the segments of that unit to cut costs and reduce headcount.  Therefore, 
SHE BELIEVES that outsourcing and downsizing will continue each quarter for 
some time to come.  She does not think that things will stabilize any time in 
the near future.  [NOTE: Since she said, "business unit," does this mean 
CSD or the SBU only? Or does she think this will happen in every business 
unit? Pat?]

Q: Is it possible that we'll have our employment transferred prior to the 
December 1 Employee Stock Purchase?

A: Given that the vendors will be selected in mid-November, it is *possible*, 
but doesn't seem probable.

The principle behind the vendor strategy is the movement of products outside
of Digital.  Digital will have drastically fewer products in the future.
Because the products will go down, the work will go down.  It is anticipated
that the work will drastically change, as well.  The people who are kept at 
Digital will be expected to grow and change as the work changes; but in some 
cases, we might hire vendor expertise.

It is expected that at the end of the fiscal year, there will be about 600
people in SES, 20 of whom will be managers (25 tops; no supervisors under 
those managers).  SES hopes to have the managers in place by January 1.  For 
the Capability Centers, some managers will be appointed (4) and some hired (8).
The announcement should be next week.  Then in the following few weeks, they 
(new managers) will go off and "sort the remaining people."

There will be virtual teams in the new model, which is expected to be 
"relatively stable within the bounds of the work."  [NOTE: I'm not really sure
what that means.]  The team will have technical people and a project manager.
The project manager will work with vendors and clients.  Performance will be 
tied to deliverables rather than relationships.  Those remaining will be 
expanding their base of colleagues (i.e., internal Digital and external).
The project manager position will be a great opportunity for someone who is 
good at it and also like to help people develop skills. [NOTE: Sounds 
suspiciously like supervision - with all of the responsibility and none of the 
authority.]

Talk returned to the vendors.  Georgina and Pat talked about attempting a 
"culture match" along with comparable salaries and benefits.

A coach talked about a "crisis in faith" in SES.  There has been a great 
lack of communication and lots of panic.  An plan was announced to outsource, 
then we were left in the dark.  Then were were told that if you refuse to 
go to the vendor, you just quit.  And only 100 people will be affected in Q2?
Out of the 900 still in SES?  There is a *perception* that there is more 
information available that is being withheld.

Regular communication is required, but upper management fears that 
communication will be interpreted as promises.  It was commented by several 
that we are not looking for promises.  We are looking for information.  What
is the *plan*?  Please treat us like adults!

Georgina and Pat wanted to know what would make us "happy" [NOTE: my word, not
theirs] in terms of communication.  Why do we have these suspicions?  It was
commented by a member of the audience that this was not a headcount reduction 
exercise.  "Well, of course it is," HR replied.  The earlier quote about 
headcount not being the driving factor for this model was read back to them.
This is the "crisis in faith."  Had we been told back in June, "Hey, we have
to reduce headcount by 50% and this is the only model we can come up with 
that has a chance of working," the SES management team would have had a 
great deal more cooperation, trust, and perhaps creativity from individual 
contributors and coaches.

Georgina and Pat encouraged us to participate in the future state plans, to 
get involved.  Our help is needed and appreciated.  If we have ideas or issues, 
we should send them to Georgina or Pat, or directly to the Future State 
Implementation Teams.

Q: To my knowledge, we are still being measured on billable time.  Work on the
future state is not billable.  Is that changing? 

A: No.  It would have to be on your own time. [NOTE: That is, over and above
the typical work week.  Since future state work takes place during normal
working hours, this means project work would be done after hours.] 

Q: Some of us do that now and have been sending suggestions and concerns since 
June.  How do we know we're not just making ourselves targets for TFSO?  We've
certainly had no feedback that our efforts are useful or appreciated.

A: Your efforts are useful and appreciated.  We should be acknowledging your
contributions.

List of items/questions for Georgina and Pat:

* What are the SES Implementation Teams doing?  We know the leaders and names
of the teams, but don't know what the titles really mean?  What is the team
purpose?  What are their responsibilities?  Who are the other members?  Can
they publish status reports in the SES conference? 

* We would like the name of someone (in a power position) who can affect change
to the "Standard Practice" on termination at transfer of employment. And we
would like the "Standard Practice" in writing, since it seems to conflict with
the Policies and Procedures Manual.  [NOTE: The question is around "voluntary
resignation" vs.  "forced resignation."  The whole question is around the part
where if you don't accept, you are "assumed to voluntarily resign." 

* With regard to vendors:  When (schedule)? Who?  Where?  List of vendors as
soon as it's available?  

* How does transfer of employment get done?  What is the process?  (How do we
know what skills the vendor is looking for? Do we need to prepare a portfolio
to represent our skills to the vendor?) 

* How much time will we have to "generate personal options?"  That is, will 
we get one or two months of notice that we will be transferred, so we can 
find other employment, if that is our decision?

* What, exactly, is SES's business in the new model?  Who will our customers
be?  Who will our clients be?

[NOTE: I meant to ask the following questions, but had to get to a 3:00
meeting.  Maybe they can be answered here. 

Pesatori announced that he had a task force off looking at Shared Services 
(no "engineering" in there!) and decide its fate.  The results were due in 
about now.  Are they available?  I heard that Sharon was not on the task 
force.  Who from SES was?  Is it possible that the task force's findings will 
be in conflict with the SES Future State Plan?

Evelyn McKay asked some pointed questions in the IDC conference about the 
fate of resource coaches.  Her questions have not been answered there.  Why 
not?]

>    "Thursday, Oct. 13, 9-10:30 in the Julia Ward Howe CR in LKG1-1/G07

Any report from LKG?

                  <<< VAXUUM::W7_:[NOTES$LIBRARY]IDC.NOTE;3 >>>
                                    -< IDC >-
================================================================================
Note 297.11     Clarification on "termination" and "resignation"        11 of 11
RAGMOP::FARINA                                       42 lines  14-OCT-1994 12:21
                          -< Addendum to my notes... >-
--------------------------------------------------------------------------------
    I received the following mail message from Julie Goonan.  Julie is
    correct in her recollection of this point from the meeting.  I apologize 
    for leaving out this very important point.  I had wondered why this was 
    in direct conflict with what we'd been told earlier, and what the VMS 
    writers were told (Mark's .0).  Julie was definitely not dreaming!
    
    
    Susan
    
    
From:	DRINKS::GOONAN       14-OCT-1994 11:47:19.41
To:	RAGMOP::FARINA
CC:	GOONAN
Subj:	Fine Point

Hi Susan,

Thank you for your excellent and informative writeup on the SES Pat Fleming
meeting.  I just want to clarify something I heard Pat Fleming say that I
thought was rather important, but wasn't included in this note.

When someone asked how the vendors would get to know the writers, and if there
would be interviews, portfolios, resumes, etc. passed to them, the answer from
Pat included this statement (and I am paraphrasing), "The vendor will not
really be able to reject a writer. The deal will be for a group of writers." 
This is different from earlier statements (or nods), for example, the earlier
statement made in this meeting:

"If after taking to the vendor, the vendor doesn't want to hire me, then I get
the TFSO package, right? (Nods)

My interpretation of this is that that the vendor will NOT have the opportunity
to reject a writer, thereby causing that writer to get TFSO'd. I think this
point has been one reason writers have lost faith with SES, and I would like to
clear it up if it needs to be. 

The reason I didn't put this message in the notes file is that I want to make
sure my understanding is right. I just wanted to ask if you remembered this
statement or if I was dreaming.

Thanks,
Julie       

	Is your feed back loop at little to tight today ????

I think this notesfile is under attack of the NEWTON-virus. Characteristics:

-Creates random notes in the DIGITAL notesfile
-Takes random words and binds them together in sentences and paragraphs
-Talks frequently about loops, but seems to be stuck in a loop itself.
-Randomly capatalizes words
-Fortunately harmless
-Generated output can be compressed in 0 bytes.

:):)

Timo

    
     Fortunately people who can come up with this stuff still work at
    digital, er DEC, er digital, err with us. Whatever. In any case one
    must appreciate the social impacts of sporks, resTRAUNT TM, the 3G's,
    nasserisum, quarterly results, the greyhawk, the peddlers, those poor
    souls in the CSC's, those lost souls in digital consulting, the
    complete seperate but we are still digital MCS folks, and BP. What a
    company. What a media, this notes. Good thing it is just type only.
    
     Can you imageine this impact of a real meida on this company?
    
    I be harmless.
    -Mike Z.

    Back to the topic in question:

    During this morning's commute, it dawned on me why SES/IDC management
    is hell bent on reinstituting indentured servitude.

    Fairly soon, SES/IDC will attempt on a large scale to deliver
    documentation on complex technical products by contracting with a small
    set of selected companies who provide the actual writing capability.
    SES/IDC management realizes that if this is to succeed, the contracted
    companies must have writers who, along with their commodity writing
    skills, possess some level of knowledge about the products of which
    they will write. Currently, SES/IDC writers get this product knowledge
    from their close association with development groups. SES/IDC
    management will force the first wave of documentation outsourcing to
    succeed by providing a wealth of product-specific knowledge to the
    contracting companies.

    Quite simply, SES/IDC management knows that a concentration of very
    specific product knowledge, combined with commodity writing skills,
    is necessary to deliver product documentation. It realizes that simply
    laying off writers will dilute this concentration to the point where the
    success of the organization is jeopardized. There would seem to be only
    two alternatives for preserving this enormously valuable resource:

      o  Buck upper management and fight to keep the resource within DEC.

      o  Intimidate the resource into preserving itself within the
         selected contracting companies.

    
    See also note 3447 for the continuing discussion.
    
    Cindy

    Bill, that's just dawning on you?  It dawned on me last May, when they
    claimed that they were not headed in this direction.  Of course, my
    theory then was that we'd be a spin-off company a la Quantic, so they
    could honestly say, "We're not headed in that direction."  --S

    A long time ago, in a land near away, DIGITAL started hiring writers,
    since contracting out documentation didn't work very well.
    
    Other corps have tried contract writing, and started hiring writers.
    
    Hmmm.....
    

RE: .292

As far as I can tell, SES/IDC management isn't hell-bent on anything 
other than keeping the jobs of SES/IDC management.  Their main 
priority is the preservation of their organization's existence.  
Sorry, but empire-building is a luxury we can't afford any more.

--PSW

>>Sorry, but empire-building is a luxury we can't afford any more.

I agree. But I think we need a new term for this since, the simpliest way I
have heard empire-building described was 

	"The manager with the most people under him/her wins."

Now <USE-WHAT-EVER-TODAY'S-NAME-IS> management is removing all the power that
headcount gets you and has turned itself into, well, a secure gateway that
engineering must pass through to get documents written (if they get their way
their is).

bjm

	re .288

	Yo, Tom.  Have you run a Monte Carlo simulation of this?
	Let me know how it goes.

	Yes, folks, Tom and I know each other from the days when
	PMF and DECplan had a last desperate fling in Commercial 
	Languages and Tools.

	&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&

	Now, back to the topic...

	One of the things I see happening recently is an increased
	involvement of SES clients in the fate of their writers.
	Clients are negotiating with SES for a level of stability
	and predictability, even if it's only for the next quarter.

	One of the classic risks to any project is staffing changes.
	With a reduced base of writers, either from TFSO or attrition,
	it is harder to quickly obtain replacements with the right
	skills.  As projects use various forms of leverage to keep
	their current writers, there is a crystalization of product
	groups.  

	I suspect that the next phase may be a cleavage along the 
	lines of products and technologies that will leave the 
	divisions more in control of their own destinies.

	Why have a centralized, shared group resident within one 
	of many divisions?  Why not let the divisions determine 
	their own optimum staffing level based on their revenues 
	and operating costs?  Do the economies of scale of the
	matrix organization outweigh the efficiencies of local
	control?

	Ron
	 

My group ( GKS/PHIGS graphics ) is now finishing up our third week with a
contract writer under the new SES plan.

Back in September we lost our only writer who had 6 1/2 years of experience
with the project.  We have a very complex documentation set with over 7000
pages.   5000 pages were under revision.  Our previous writer had no confidence
in SES management nor the prospects for continued employment so she found
another job with another company.  She was even such a good employee that
she raced to finish the 5000 pages (8 books) and submit them before she
left - all while some SES managers who rarely had talked to her or knew
much of anything about what she did now wanted lengthly "debriefing" meetings.
(She did do a debriefing with me and I even understand Document so the 
"information" was safe.)

We thought we were in deep trouble for our next releases - that we couldn't
possibly find somebody quickly that could come up to speed in time for
the next set of deliverables.

We were wrong and we got lucky.

SES found 3 people, interviewed them, and passed 2 along for the
engineering team to interview.  Note that in 9 years at Digital,  I've
NEVER seen engineering have *ANY* input as to which writer they would get.
This was TRUELY something new to be able to decide the actual writer
that would be critical to our success.

Of the 2,  1 was outstanding.  She didn't know VAX document explicitly
but only something just like it (IBM).   She does know graphics though which
we thought would be impossible. She has excellent general writing skills.  
She was *AT WORK* 3 days after we interviewed her and we were only without a 
writer for about 2 weeks.

The bottom line is that we lost a excellent long-term valued employee
who had VERY low moral and got an excellent and ENERGETIC new writer who
can be easily trained.

So from the engineering perspective,  this new system may not be all that
bad.  Our previous writer was the only one who really got screwed but at
least she got out when she could still get another job.

Garry

Garry,
  Thank you for sharing your experience.  Please also share the cost 
comparison, if you would.  Was it cheaper in the long run?

>Our previous writer was the only one who really got screwed but at
>least she got out when she could still get another job.

Yep.  At least she got out because she lost confidence in SES management,
her future at Digital, felt threatened...

What would you estimate the cost of keeping this writer if she had confidence
in her management (not necessarily SES and accompanying overhead), felt
she had a stake in the direction of the corporation, and didn't feel as if
she had no say?

For Digital, I am glad your project wasn't impacted.  And maybe only
one person "got screwed" in the process.  Success, eh?

Mark

How well do you think your energetic new employee would have done
if your low "moral" ex-writer had not finished those 8000+ pages before
she left?  Just how fast do you think IDC/SES would have hustled to
offer you your new prospects if this 300-page note were not in
existence??

I guess she thought well enough of you and/or DEC to finish her work.
It would seem her trust was certainly justified.

Your testimony speaks volumes.  Congrats!

    Carolyn    

   
   Re.299
    
   Garry,

   Some points on your note...

   >Our previous writer had no confidence
   >in SES management nor the prospects for continued employment so she found
   >another job with another company.  She was even such a good employee that
   >she raced to finish the 5000 pages (8 books) and submit them before she
   >left - all while some SES managers who rarely had talked to her or knew
   >much of anything about what she did now wanted lengthly "debriefing" meetings.

   It's very unfortunate that you lost such a good employee - a person who,
   even with such low morale, would do such a conscientious thing as to get
   all that work done before she left, especially given the circumstances.

   That was truly one dedicated, professional person you had working for you.
   The company she is now with, I'm sure, is pleased to have her...especially 
   if the company is one of our competitors.


   >The bottom line is that we lost a excellent long-term valued employee
   >who had VERY low moral(e) and got an excellent and ENERGETIC new writer who
   >can be easily trained.

   The bottom line also includes the costs you have incurred as a result of 
   the organization that created the low morale to begin with.  This 
   includes the time that our former technical writing colleague spent in 
   looking for employment elsewhere, when perhaps that person really didn't 
   want to do so anyway and would rather have stayed at Digital and in your
   group.  

   Then there are costs that were involved in finding and hiring a contract 
   writer to take that person's place.  


   >We were wrong and we got lucky.

   It seems only fitting that the cause of the problem to begin with, 
   should now provide the solution to the problem they caused.


   >Our previous writer was the only one who really got screwed but at
   >least she got out when she could still get another job.

   And then there are the rest of us writers and our clients who are still 
   here...waiting...wondering...concerned that we all may not be quite as 
   'lucky'.

   Cindy

   >We were wrong and we got lucky.

I certainly hope we're not a business that is driven by luck.

This time, it worked out okay, meaning the product shipped.  Why?  How?
Is this repeatable?  Is it good?  Is it *better*?  Is it more expensive?
What are the human costs?  

How does this scenario compare to other scenarios?

The facts:

(1) writer had low morale caused by lack of management support, feeling
    of having no future at Digital, no goals, no vision

(2) writer engages in job search, finds employment outside Digital

(3) writer works hard to leave the project tidy (despite indication of 
    low morale which must not be linked to her work, but her management
    and the "state" they've caused.

(4) engineer notices low morale

(5) engineer find himself without a writer

(6) SES management offers choice of contract writers

(7) project (that was left tidy) is continued after two week down time
    (little to no loss to project)

From a business standpoint, perhaps the only thing that matters in the
world of commodities is #7.  Even cost is secondary, and people (commodities)
are given the least consideration?  But do you know what has changed from
former times?   Not much.  If an employee didn't find that Digital suited
them, and left, Documentation would find a replacement.  Maybe without a 
choice, but maybe with a suitable (or better) replacement.  You could
get lucky.  The difference today is the volume of #1 causing #s 2-5.

What is the cost of getting the work done, if things are not too different,
except in the way documentation is delivered and in the way the documentation
specialists are treated?

Mark

RE: .299

Are the "low moral" writers the persons responsible for the employee 
thefts discussed in another topic in this conference?  :-)

--PSW

    Re: .304
    
    No, they're the ones who "loose" things and refer to the "add" they
    saw in a magazine.
    
    					Steve

RE: .305

Presumably they also form the plural's of word's by adding 
apostrophe's to the end's.

--PSW

    They show up in Carbuffs with bad "breaks" and cars that "brake" down
    all the time. ;-)
    
    Harry
    

    I have no idea where to put this request (suggestions welcome), but
    this seems somewhat reasonable.
    
    I just spent two weeks consulting for a customer in Saudi Arabia (not
    ARAMCO). The customer is looking for someone to upgrade (ongoing) their
    technical documentation and seems to have a high respect for our
    documentation people - and knows we are letting some of them "go". If
    anyone knows someone who has left Digital and might be interested,
    please have them send email (if possible) to me.
    
    Thanks,
    Peter

re.-2

I recently read (in a section on break-ins, in a book on
computer ethics) about "logical breeches".

Sounds like a handy pair of trousers to have for work ...

In a recent Organizational Announcement from SES, one of the new groups was
announced as Client Information Management:

  "Key to effective best-in-class user information is a proactive partnership
  with our internal clients. Client Information Management is the lynch pin..."

Maybe some internal client will be proactive by showing up at some meeting with
a noose.

Vicki Meagher

RE: .299 by FREBRD::POEGEL "Garry Poegel: "success under the new plan"


Garry, are you sure your writer was obtained "under the new plan" or are you
making this assumption?  Could it be that in a scramble to replace your
writer who quit, they used a contractor to finish the job? 

Several things in your note make me wonder if this was really done under the
new plan, or if your situation just happened to coincide with the
announcement of the new SES plans.  Is GKS/PHIGS one of the official "pilot
projects"?

First, you mention SES found you a contract writer.  The new plan
specifically disallows contract writers - the new plan calls for entire
books to be vended out to external companies.

You also mention she was at work 3 days after you interviewed her.  Do you
mean she was at work sitting here at Digital? Or elsewhere? Vendors are
external companies of their own.  The vendor-writer would not sit here at
Digital.

Also, the SES Future state plan does not call for bringing in writers to be
interviewed by engineering.  SES makes the work contract with the vendor
company, SES' account and vendor managers work with the vendor to manage the
work, supposedly "freeing" you, the engineers from the process of having to
interview and manage the writer.

Lastly, you mention she didn't know VAX document explicitly, which implies
that's what your documentation is written in.  What vendor company is this
(if it really is one) that had VAX DOCUMENT already up and running?


Glad to hear things worked out for you but I'm curious whether your case can
really be viewed as a model of the SES future state in operation.

Thanks,
-Mike

>>                     <<< Note 3238.311 by AIRBAG::SWATKO >>>
>>             -< success, but was it really 'under the new plan'? >-

>>Garry, are you sure your writer was obtained "under the new plan" or are you
>>making this assumption?  Could it be that in a scramble to replace your
>>writer who quit, they used a contractor to finish the job? 

No I'm not sure she is really part of the "new plan",  but since we have
her on a many month contract,  I suspect that the way we did it is really one
of the possibilities under the new plan.

>>Several things in your note make me wonder if this was really done under the
>>new plan, or if your situation just happened to coincide with the
>>>announcement of the new SES plans.  Is GKS/PHIGS one of the official "pilot
>>projects"?

We're not one of the official pilots.  We lost our writer,  my manager
screamed very LOUDLY, and SES moved in with a replacement.

>>First, you mention SES found you a contract writer.  The new plan
>>specifically disallows contract writers - the new plan calls for entire
>>books to be vended out to external companies.

SES did find the writer. That is they did all the leg work in contacting the
contract agency and THEY actually hired her.  We still contract with
SES for "services".

>>You also mention she was at work 3 days after you interviewed her.  Do you
>>mean she was at work sitting here at Digital? Or elsewhere? Vendors are
>>external companies of their own.  The vendor-writer would not sit here at
>>Digital.

She works right here at Digital, sitting with the engineering group.

>>Also, the SES Future state plan does not call for bringing in writers to be
>>interviewed by engineering.  SES makes the work contract with the vendor
>>company, SES' account and vendor managers work with the vendor to manage the
>>work, supposedly "freeing" you, the engineers from the process of having to
>>interview and manage the writer.

We might have gotten special treatment, but we got it.

>>Lastly, you mention she didn't know VAX document explicitly, which implies
>>that's what your documentation is written in.  What vendor company is this
>>(if it really is one) that had VAX DOCUMENT already up and running?

Since she works at Digital,  she's using our equipment.  She only had to
be trained a little.

>>Glad to hear things worked out for you but I'm curious whether your case can
>>really be viewed as a model of the SES future state in operation.

Maybe not,  but if engineering requests it to be done this way,  it looks
like it can be done.  At least in this case SES did find a way to provide
us the service we need.

Garry

    Garry, thanks for responding with those facts.  I hope the project goes
    smoothly.
    
    Reading these replies, one might easily get the impression that those
    of us who are currently employed full-time as technical communicators
    are gunning for contractors.  Speaking for myself, that is not my
    intent.  My father was a free-lance writer, and I have been a
    contractor (albeit briefly).  Contracting is an honorable profession,
    once which has been called upon by almost all publications groups in my
    experience of nearly twenty years.
    
    I hope that we will continue to treat everyone with whom we come into
    contact with the same decency, respect, and professionalism that we ask
    for ourselves.

Garry,

>  Thank you for sharing your experience.  Please also share the cost 
>comparison, if you would.  Was it cheaper in the long run?

>What would you estimate the cost of keeping this writer if she had confidence
>in her management (not necessarily SES and accompanying overhead), felt
>she had a stake in the direction of the corporation, and didn't feel as if
>she had no say?

Mark

Garry,

This confirms what I thought - your experience does not fall under the SES
future plans.  Rather it's just the way IDC works today.

Under the SES Future State plans, what happened to you would specifically be
disallowed.  It explicitly says in the plans that SES will not use
contractors.

So, how would it be different under the Future State?

- You would not receive a replacement writer.  Rather, the job would be
vended out to an external commpany.

- Neither you or your management would have a say in who got to do the job.
SES vendor management would negotiate with your management regarding costs,
requirements, schedule, etc.  Then SES vendor management turns to the
vendors and negotiates with the vendor companies for the project contract.
Then they write up the contract and go on to the next step.

- Your new, anonymous writer(s), sitting at some other site, using some
other machines, would do the work at their place from the specs that you
provided to them.  (You *do* already have specs detailed enough to write the
documentation from, don't you?)

- To interface with your writer, you contact SES vendor management, SES
vendor mgmt contacts the vendor, and the vendor interfaces with the writer.

- Occasionally the writer might call you directly with questions or travel
to your site for meetings from time to time.  But you would not see them all
too often.  They would write from the specs you provided.


Now ask yourself, if this was the situation, do you believe you still would
have gotten the job done in the same time, at the same cost, with the same
quality? This is exactly what the SES Future State plans describe.  How
happy are you with this prospect? What happened to you this time is that you
lucked out.

Sure, under the Future State, maybe you can scream loud enough to have an
exception granted and get a contract writer assigned to you.  But do you
think you should have to scream to get your work done? Is that the way you
want to operate on a regular basis?


>I suspect that the way we did it is really one
>of the possibilities under the new plan.

Bad assumption - I assure you that it is not.  Look into the "plan".


>Maybe not,  but if engineering requests it to be done this way,  it looks
>like it can be done.

Today, yes.  Tomorrow, probably not.  You are making a very risky
assumption.  NOW is the time to look at the words of the Future State plan,
not later when you realize the system is broken.

Please realize, I don't really have much of a stake in this.  I am not a
writer - I am an engineer, who happens to work for SES.  So what happens to
the writers will only affect me in an indirect way.  Since I'm in SES, I get
to see the Future State plan.  For the most part, you don't.

All I know is that, as an engineer, I can't imagine being able to get my
product out with similar costs, schedule, and quality when comparing this
Future State plan to the way things work now.  I am concerned, and I think
you ought to be too.  That's all.

-Mike

>>     <<< Note 3238.314 by TOKNOW::METCALFE "Eschew Obfuscatory Monikers" >>>

>>>  Thank you for sharing your experience.  Please also share the cost 
>>>comparison, if you would.  Was it cheaper in the long run?

My understanding is that the cost to my engineering is the same with our
contract writer.  I don't see how it could be cheaper to Digital though.

The best solution would have been to hire our old writer directly and remove
SES from the whole conversation but the time was too short to try pull that off.

Garry

>>                     <<< Note 3238.315 by AIRBAG::SWATKO >>>
>>                    -< the exception, rather than the rule >-

>>This confirms what I thought - your experience does not fall under the SES
>>future plans.  Rather it's just the way IDC works today.

I don't think we could produce a product in a timely manner under what 
you outlined.  

Garry

>The best solution would have been to hire our old writer directly and remove
>SES from the whole conversation  [...]

'Nuff said.

-Mike

RE: .310

SES Client Information Management as a lynch pin definitely wins 
bestt-in-class.

I'll bet the SES folks are all "principle engineers," too.  They 
certainly have been indulging in that activity.

--PSW

    
    Just saw a memo stating that the Network Product Business group will
    hire contractors directly to produce its technical documentation, instead
    of contracting through SES. Cost difference of ~$40/hr for direct cost,
    compared to $59/hr SES rate, was cited as the reason.
    

    Of course, once engineering adds in the fixed costs that we all pay
    (office space, network support, etc.), they'll probably end up paying
    approximately $59.00 per hour for their contractors, give or take about
    $5.00.
    
    Unless, of course, the contractors are providing their own equipment
    and office space, etc. then it's a pretty good deal.
    
    At least, that's how the cost structure was explained to me. Approx.
    $40 of the SES charge is for the worker bee. The rest are fixed charges
    that all Digital orgs. pay with about $3-5 for SES overhead.  Now, how
    accurate a description I was given about the cost structure is  not
    something I can verify.
    
    cheers,
    
    joan
    

RE: .320 - I suspect there's more to it than money.

Take your pick: do you want to deal with one person concerned with
project issues, or a matrixed committee with an agenda?

    RE: .320  - I'd like more details please.  Does this memo cover the
    entire Network Product Business Group or individual product groups?
    
    Can you get permission to place the memo in this note?
    
    Thanks

    
    The memo strongly implies that the entire Network Product Business
    Group is affected.
    
    Will work on permission-to-post; hold not your aspiration.
    

    Contractors are dedicated to the project; your SES rep may be
    only the project mgr for your doc needs and contracts out the
    pieces and does some writing as well. Either way, the days
    of slipping engineering release dates are over unless you
    like budget overruns.
    
    
    bk (been there, fiddled with the numbers, we're doing some
    doc work ourselves in engineering & turning it ocver to SES
    to save $s & schedule)

>>Either way, the days of slipping engineering release dates are over unless you
>> like budget overruns.

And this could be a benefit to the company overall.

joan

    
    outsourcing really helps me KEEP projects on budget.
    
    In the past five years I had only ONE project go over 
    budget.  If a project does slip significantly I put a hold
    on its doc activity and redirect resources to another project
    in the work que.
    
    Gary Beaudreau
    PCBU Eng Doc Mgr
    

			Bye.  I've been traded to a vendor and although 
		I expect to be working with DEC,  I won't be working for 
		DEC after Dec. 31.

			I've worked here for almost eight years,  first as 
		a technician and then as a technical writer.  It's been a 
		great place to work because of the many helpful and 
		knowledgeable people here.  I'll miss this.  And I'll miss
		being a part of the engineering teams I've worked with.
		(Oh, I know.  I shouldn't be ending a sentence with a 
		preposition but it's my last week and I guess I'm just
		a little crazy.)

		John MacNeil, the guy who entered the base note
				

Tnank *you* John.

    The following topic has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to HUMANE::MODERATOR, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    ---------------------------------------------------------------------

The VMS engineering group recently hired the remaining VMS writers
directly into engineering.  Some work will still be outsourced because
there aren't enough writers left to cover the work.

But, the writers who survived now report to engineering and are no longer 
candidates for outsourcing.  

 
    

.330>But, the writers who survived now report to engineering and are no longer 
.330>candidates for outsourcing.  

At least, not by SES...  :-)

-- Nina

P.S. I wonder why the author of .330 submitted it anonymously? It's not a
Big Secret or anything (as far as I know).

P.S.S. In another group, SES is actually hiring writers from outside DEC
because the group lost so many writers due to (a) layoffs, (b) outsourcing,
(c) attrition.  Apparently the Approved Vendors can't supply enough people
with the appropriate skills.  And the writers who were outsourced and now
working as contractors in that group can't be hired back by DEC (at least,
not for six months, I believe, due to the vendor's practice).  They've hired
at least one writer from outside so far, I hear (from quite reliable sources).

What's wrong with this picture...?!?!

    
    Re: -1
    
    >>P.S. I wonder why the author of .330 submitted it anonymously? It's not a
    >>Big Secret or anything (as far as I know).
    
    They learn from experience ( of others ) what happens when things 
    are written in a notesfile. 
    
    jc  

    We had trouble getting my local writing uh, uh, uh (they aren't
    coaches anymore, what is their title?  puppet?) whatever getting
    resumes from an agency because somebody said their group has hiring
    too many contractors!  Yeesh!
    
    				-John

    
    You will be interested to know that contractors (of whom I am one) are
    being outsourced.  
    
    Ever since they told me that I've had trouble working, can't seem to
    get my eyes uncrossed.
    

VMS is not the only Digital engineering group that has evaluated the
situation and decided to hire their (existing) writers directly.

For various reasons, some writers have voiced discomfort with the
prospect of reporting to an engineering supervisor. In the case of VMS,
they hired the writing manager, editors, artists, writing system manager,
and production people. The doc group will report to a doc manager, who
will report in to engineering. This is an excellent structure, and was
welcomed by the doc folks (most of whom accepted their offers within
minutes).

What did this structure represent to the doc people? 

        Stability
        Recognition of contribution to product set
        Recognition of contribution to company success
        
...all of which were -um- not evident in their previous organization.

And yes, many doc people have been intimidated or angered into silence
(hence the anonymous entries here and lack of activity in other
conferences). Some have left for other jobs, some are actively (and quietly)
seeking employment elsewhere. Silence does not equal acceptance and
submissiveness in all cases.

Art

    A friend of mine who owns a consulting firm in Dallas is looking for
    people with VAX document experience and SKADA experience, if possible.
    If anyone knows of an ex-Digit or someone else with this kind of
    experience looking for a contract, please have 'em call/e-mail me and
    I'll pass the contact info on.
    
    								Tex

	... or System Control and Data Acquisition.  
	       ^      ^       ^   ^    ^

    Well, yeah, I knew it was somethin' like that...  Thanks for the
    correction, compadre, it's appreciated.  People mighta thought my
    friend was lookin' for someone with 
    
    		Some Kinda Awful Digital Aversion
    		^    ^     ^     ^       ^
    
    then our hardware sales woulda plummeted and it woulda been *my* fault!
    
    								Tex  :^]

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL



			Sharon Keillor to Leave Digital

		Sharon Keillor is leaving Digital to go to another
		company.

		During her stint as head of SES,  Sharon 
		reorganized her department from the top down
		and instituted an outsourcing program,  outplacing
		employees and then leasing them back.

    re: .339
    
    Is her new employer renting her back to Digital?
    
    
    Robin
    

    
    I heard she's going to work for a company on the Atlantic seaboard that
    launches satellites.
    
    Sort of the ultimate expression of outsourcing a resource and then
    leasing back the services.
    

The headcount of SES is down to about 540 people, and possibly not big
enough to warrant a VP.

We were told that Sharon was asked (last week) to present three options
for the future disposition of SES. I found one of her options (to Mr.
Demmer) particularly intriguing: break up SES, and place the various
groups under their respective (logical) business units (C&P, Networking,
Systems, MCS).

Why did that catch my eye? Because, back around March of 1994 Sharon
asked for "radical ideas" to help SES (which was then mostly IDC). I
responded, and sent:


Sharon, you're looking for "radical" ideas. Here's one that's probably
not so radical:  
                 SEPARATE IDC FROM WRITING AND TRAINING

Separate information design and consulting (IDC) from a Traditional
Products Publications group (TPP) and a Traditional Products Training
(TPT) group. IDC, still a part of SES, would be responsible for the
advance development efforts for training and documentation. Radically
progressive strategies for information delivery would be the realm of
this group. All the best ideas for book design and courseware design
would come together in this group, to be the basis of a consistent look
and feel for Digital information packages of all types.  Concentrated
technical efforts would yield a uniform authoring tools strategy. 


TRADITIONAL PRODUCTS PUBLICATIONS

Traditional products such as programming languages and environments,
software engineering tools, database products, network operating systems
and pure operating systems would be the responsibility of TPP.

TPP would consist of teams of writers supporting the existing and
emerging products using stable authoring tools and efficient productivity
techniques and environments.

Writers, encouraged to work and identify as members of their respective
product engineering teams, would also have a team relationship with their
fellow writers on similar products.  This structure would support the
sharing of techniques and strategies across products while writers
concentrate on their particular project. Movitation would soar because
the individual contributors would feel a part of the overall success of
"their" products. They'd identify more with their audience, the product
consumers.

TPP would look to IDC for technical consultation and long-range strategy
guidance, as well as information package production support. TPP would be
funded directly by engineering.


TPP First Level Management
=========================
A team of writers would report to a writing manager having responsibility
for the growth of writers in the group, while also being responsible and
accountable for the efficient management of project and production
details. The first level manager would relate to and identify with the
products in the space, and this relation and pride of ownership would
propagate through the group. 

Thus, leadership as well as knowledge of the product space would be the
realm of the first level manager. 

A reasonable span of control of 10 to 15 writers, all at one location, is
best. This structure most closely matches that of the engineering groups,
thus facilitating intergroup relations.

TPP Second Level Management
=========================
First level managers would report to a second level manager with
responsibility for a site, or having a focus on a specific segment of a
business unit (in other words, the business units for: Database;
Operating Systems; Languages and Environments; Networking; End User
Applications...).  A reasonable span of control, as well as the ability to
build and apply expertise within a business's market space would be the
area of responsibility and accountability of the second level manager.

Second level managers would have a dual reporting path, to SES and to
Engineering management.

The TPP, under this suggested organization, will be fully and directly
accountable to the success/failure of the client projects.  It will be
easy for TPP management to discriminate between activities that support
the client projects and those that do not.


TRADITIONAL PRODUCTS TRAINING

Training and courseware would be produced by Traditional Products
Training (TPT). The structure of this group would be similar but not
identical to TPP. For example, reuse of training modules is very
effective; hence, identity of a trainer with a family of products is more
effective (and efficient) than limiting that focus to a single product.

Teams of trainers would concentrate on the products of business units as
shown above. Cross-team communication and strategy formulation would be
accomplished by either dotted line relationships with the second level
TPP manager, or by a site structure where TPP and TPT report to a common
second level manager. 

TPT would look to IDC for technical consultation and long-range strategy
guidance, as well as information package production support.

No discussion on this? I'm surprised. How about this:

The three options that Sharon presented to Mr. Demmer are:

        1. Status quo for SES
        2. Move SES under Marketing & Communications
        3. Break SES into functional units that move into their
           respective engineering organizations, with a nucleus 
           User Information [caps are mine - AH] group retained to manage
           styles, standards, artwork, production, editing, authoring
           and delivery tools development etc.
           
My vote is for number 3.

I believe it would achieve at least three things: make it fun to work
here again, increase productivity and enhance quality.

Art

it is clear from the string that the selection of options
for documentation is not part of a democratic process, else
the writers, Mr. Riebs, and others would have settled the
issue completely quite some time back.

I think they were rather eloquent, and can add nothing to
what was said.  It's a pity those options weren't available
before Ms. Keillor left.

   Carolyn

    
    From an engineering viewpoint, 3 is the right choice. I've been
    lobbying for it for years, and I've never spoken to an engineer
    or a writer who thought it wasn't the best approach.
    
    However, I predict that 1 will win out, for two reasons:
    
    1) For reasons totally unfathomable to me, Mr. Demmer unequivocally
       suppported the current SES status quo, to the extent that he stated
       that individual engineering groups would not be allowed to sidestep
       the SES "future state". There is no reason to believe that he will
       not support it now that Ms. Keillor is leaving, unless one assumes
       that the success of the "future state" was based entirely on Ms.
       Keillor's presence.
    
    2) The ever tightening constraints on engineering head count will
       prevent writers from being assimilated into engineering
       organizations. By some measurement also totally unfathomable to me,
       there is a difference between handing some percentage of an
       engineering budget over to SES year after year, and using that same
       percentage to hire writers into the engineering group. Head count,
       not budget, has been the constraint thrown back at mee every time
       I've broached this subject in the last year or so.
    

I keep hoping that common sense and truth will win out.

There is no evidence that *any* product group has realized a cost saving
by using "vended" writers. The experience has apparently been quite the
opposite.

Some talented writers who were pushed out to "vendors" have subsequently
left the vendors for jobs elsewhere. Their knowledge and skills are now
lost to us. The vendors are not having an easy time finding replacements.

Is all this a surprise?

         <<< HUMANE::DISK$CONFERENCES:[NOTES$LIBRARY]DIGITAL.NOTE;1 >>>
                        -< The Digital way of working >-
================================================================================
Note 3238.176  A Question for Engineering - Is Technical Writing Val  176 of 344
TALLIS::RIEBS                                        74 lines  17-AUG-1994 13:41
                              -< IDC is obsolete >-
--------------------------------------------------------------------------------
.
.
.
According to the rumors, IDC won't allow us to use learned and
productive people in the future. Instead, they propose (and I'm not
making this up) that I should commission them to commission a
contracting house to commission a writer who likely has not a clue
about the work that we do to get our writing done.  Somehow, by paying
IDC's overhead, and a contracting house's overhead, we'll spend less
than if we paid the writer directly -- Unbelievable!!
.
.
.

WRT the IDC overhead that Mr. Riebs predicted nearly a year ago, the
current figure (to be tacked onto vended writing services) is about 18%. 

So. We've reduced the pool of available skilled resources, and we've
raised the cost of those that *are* available. Startup costs? Ever see a
tax go away?

Sure sounds to me like a good time to try another approach. Like, #3.

Art

    The following reply has been contributed by a member of our community
    who wishes to remain anonymous.  If you wish to contact the author by
    mail, please send your message to ROWLET::AINSLEY, specifying the
    conference name and note number. Your message will be forwarded with
    your name attached  unless you request otherwise.

    Bob - Co-moderator DIGITAL
    
    ======================================================================
    


		How's this outsourcing strategy working out?

		Last Fall,  Shared Engineering Services (SES) began 
	putting their plan into action,  transferring about forty 
	writers to a vendor who contracted them back to Digital.  
	Shortly after putting this plan into effect,  the top SES 
	management, Sharon Keilor and Sue Gault, left Digital.
	I've heard of some instances of tech writers now being hired 
	directly by Digital.  Has the strategy been changed?