Conference 7.286::digital

    re .0:
    
    I'd suggest you have any group you meet with view the short film
    "Meetings, Bloody Meetings", starring John Cleese.  It's funny
    and very informative about the proper way to *plan* and run a
    meeting.
    
    /Dave

Re .0:

I agree with the advice in .1.  The company has at least one copy of the
videotape.  I'd try getting it via the site library.
				/AHM

    Re .2
    I'd suggest calling a meeting to discuss the possibility ...
    
    MikeDay
    

    I suggest you schedule all your meetings in the morning.  That way you
    know you're going to get out.  Everyone wants to go to lunch.

	I've worked for several people who don't eat lunch. Yes, meetings
	did sometimes go into lunch hour.

	I once heard a story, true or not I don't know, that they did a
	CMS report of activity in one group. One week showed a *much* higher
	than average amount of activity. Lots more modules moving in and
	out of the CMS library. Wow, the managers said, what caused that
	sharp increase in productivity? Turns out it was the week between
	Christmas and New Years. All the managers took the week off and there
	were no meetings. There may be a lessen there somewhere.

			Alfred

Some meeting activities can be replaced by the computer conference.
You can reference my thesis in the Maynard library BRAKO, HF5718.B72, 
CID #61244).  As my survey indicated, attendees of Digital meetings find 
them dull and a time-waster.  Computer conferences were found to be a more
effective solution in some cases.

					-- Anne Marie

    Sorry, I - I must've dozed off...
        
         what time did we schedule the meeting for ???

    But wait -  how could we get "buy-in and consensus" without a meeting
    of the parties?
    
    	-Barry-
    

    Re: .8
    
    The "buy-in and consensus" can be determined by using VAXnotes as well.
    Have the participants post their agreement (or what would have to be
    changed in order to get their agreement). If the issue is merely
    complicated, as opposed to contentious, VAXnotes works fairly well. For
    contentious issues, even meetings have problems. Very small groups, or
    1-on-1 meetings works best for those cases.
    
    This actually does work if the participants want it to work. I've used
    it successfully many times dealing with VAX architecture issues.

Regarding the idea of substituting VAXnotes for physical meetings, well this 
sounds like a good suggestion on the surface but there's a liability in it.  
This is that I think that we spend far too much timne staring into tubes and
although I'm very pro VAXnotes, I'd like to find a way to cut down the tube-
watching.

I do agree that there are too many bloddy meetings in this company, however I'm
all for meetings as long as they get something accomplished.  One advantage
of a physical meeting is that you get to speak to people face-to-face which is
far more advantageous than keystroking to nodex::somebody, etc.

David

    Re: .10
    
    Yes, a face-to-face meeting is a real advantage for some types of
    problems. VAXnotes works well when you already have a good working
    relationship with the people involved, but it can't substitute for
    face-to-face meetings when the problems get difficult or there is no
    working relationship. The occasional face-to-face meeting is also
    necessary to KEEP a good working relationship. 

There is no substitute for a *WELL ORGANIZED* meeting...

... there are also very few meetings that are *WELL ORGANIZED*!

                                         Bob

>    ... there are also very few meetings that are *WELL ORGANIZED*!
 
    OR have a clearly defined *PURPOSE*!
    
    -paul

Re:. 13

It's the weekly meeting, of course!

				-- Bob

Robert Townsend, in his book UP THE ORGANIZATION, said he gave the following
advice to employees when he was CEO at Avis:

(This is not the exact quote)
If you're at a meeting that seems unfocused or is irrelevant to you I expect 
you to get up and leave.  A meeting very rarely needs to be longer than 30 
minutes.

Apparently people at Avis took this advice to heart.  I'm told it made an
enormous difference.  It certainly put the burden on the person calling the
meeting to keep it relevant and keep it moving.

I'm told Townsend had a standing desk (no chair) in his office.  He said he
didn't want too get comfortable sitting in a chair behind a big desk.  Maybe
we should have "standing" meetings.

Mark

    We have this neat little policy within our group that says you don't
    have to go to a meeting if the agenda hasn't been published and
    distributed before the meeting.  Though it doesn't totally prevent
    wasting of time, it sure makes the person calling the meeting get their
    act together, and have some sort of structure and purpose.
    
    I'd also agree that VAXnotes can serve a very useful purpose in
    reducing the number of meetings required for any given project, but
    there comes a point where you do have to get together face-to-face. Our
    group also makes a great deal of use of conference-calls, as the people
    working on our projects are scatered around, and a face-to-face meeting
    costs bucks as people have to fly in.  (we're talking thousands of
    kilometers, here! :-)  A one-hour conference call can save a day of
    travel for a face-to-face meeting. 

    
    	Re: (-.1)
    
    	Some excellent ideas .... I like the no agenda, no required
    meetings. Too many meetings are called to reinforce personal power of
    middle level managers.
    
    	Rgds
    	/john

The following is an internal prototype of a system that uses Notes before,
during, and after face-to-face meetings in order to facilitate making agendas,
taking minutes, and conducting follow-on discussions:

                      <<< TWILIT::JABBERWOCKY.NOTE;2 >>>
                 -< Feedback on Jabberwocky User Environment >-
================================================================================
Note 53.0                        Meeting manager                      No replies
TWILIT::BROOKE "Justice Ongar Twilight"              38 lines  17-JUN-1988 20:43
--------------------------------------------------------------------------------
    Meeting manager: if anybody's interested, I've built a prototype
    meeting manager using DB. It lets you set up an agenda for a meeting,
    and creates a notesfile containing the agenda. Once you start the
    meeting by pressing a function key bound to the "start agenda"
    function, it informs you of which agenda item is next, then uses
    a Notes reply to allow you to keep minutes for that agenda item.
    
    A second function key is wired to allow you to record any action
    items raised during the discussion. These are collected together
    and when the agenda item is completed, a further reply to the note
    is written containing all the action items.
    
    A third function key allows you to close any agenda item; the minutes
    are timestamped then it does the writing out of the action items,
    displays the next agenda topic and repeats the process already
    described. When there are no more agenda items to be processed,
    it timestamps the end of the meeting.
    
    This all runs on a dumb VTxxx type terminal, and only requires DB, DCL
    and Notes.
    
    The intention is that one output the screen image of the VT220 to
    a monitor that everybody in the meeting can see, then they'll all
    be aware of the activity in the meeting. At the end of the meeting,
    a copy of the minutes can be extracted from the notesfile and mailed
    to all the participants.
    
    This stuff bears a lot of resemblance to the sorts of things other
    people are doing (eg John Whiteside's co-creation work). I mention
    it here because we intend to try using it for managing our own meetings
    and I would be interested to hear from anybody else who might want
    to use it and tell me what requirements they have for managing their
    meetings.
    
    If you're interested in using the stuff, please send mail or post
    a reply to this note.
    
    John


================================================================================
Note 82.0                          DB_Meeting                         No replies
DUMPTY::BARRETT                                      25 lines  23-FEB-1989 10:14
--------------------------------------------------------------------------------

    We have now formalised the requirements for a meeting facilitation
    tool; DB_Meeting.
    
    <Extract of OVERVIEW from the requirements doc.>
     >DB_Meeting is primarily a collection of software tools integrated under
     >the Dialogue Bus and designed to run on several different hardware
     >platforms.  (See Section <tbd> for alternative hardware configurations).
     >Some of the features described below will be hardware dependant, only a
     >DECwindows workstation is expected to support all of the capabilities
     >described.
     >
     >Central to the design of DB_Meeting is the facility to have a large shared
     >display that is seen by all attendees during the meeting; throughout this
     >document this display is referred to as the 'public display'.

   The requirements document is now available for comments:-
    
    IE::UIA$PUBLIC:DB_MEETINGS_FORMAL_REQUIREMENTS.TERMINAL
    IE::UIA$PUBLIC:DB_MEETINGS_FORMAL_REQUIREMENTS.POST
    
    JonB

    .20 . That sounds saleable. Talked to Marketing about it ?
    

    	I have just sat down and read all of your replies. I have chuckled
    and am also surprised at some of your answers. The VAXnotes idea is
    ridiculous. That reinforces the "root" of the problem I think. The
    BASIC point is that meetings should be called only when neccessary, in
    order to accomplish SOMETHING. 
    
    	In order to accomplish something, people need to FULFILL their
    committments, and come prepared to the meeting. In this companym you
    don't have to do that.
    
    	Meetings are comprised of these type of people:
    
    1. "what I refer to as professional meetings goers". This type does 
       nothing EXCEPT go to meetings. They bring their own coffee, lounge
       slippers, etc. This type may also be refered to as "Mr. Rogers type"
       (isn't that special?) 
    
    2.  The second type are people that just want to get some info they
        thought they could get from the meeting. They don't last more that
        2 of the same meeting.
    
    3.  Third type is the type that may fall asleep during the meeting.
        They attend only to get some rest.
    
    There are probably more types that varies from week to week. The bottom
    line is that meetings around here don't accomplish anything, except to
    either postpone a decision, or to reschedule another one. 
    
    	I like the VAXnotes idea, except that the people using it NEED to
    want to. But what these people do if there weren't meetings. It's job
    security!
    
    Bob

     A corollary to the issue of useless meetings are the equally useless
     memos, design specs, project plans, phase something-or-other plans. I
     usually lump the two together - Meetings & Memos - with as much
     sarcasm as I can muster. A project that has useless meetings will
     often have an avalanche of paper as well.
     
     A few years ago, a project I worked on had a pile of paper associated
     with it that needed a pick-up with a plow blade just to keep a path
     into my office clear. Meetings would often have 50! or more people
     sitting around discussing the most recent paper blizzard. 50 people in
     one room will get very warm - and little else.
     
     And buried under all this was the simple fact that the project would
     require two Cray's welded together as a hardware platform.
     
     We don't make Crays so the project was canceled. I estimated the cost
     at 1 million plus. 
     
     Ultimately, the bean counters look at the financial parameters and
     conclude that we can buy the products we need from "third parties" at
     a fraction of what it costs to produce internally - because the 3rd
     party doesn't sit around munching M&M's.
     
     Which sends a tidal wave of engineers from the most recently canceled
     project out into the job market looking for other projects to cancel.
     
     This has got to stop.
     
     walt
 

    I liked the idea of using air heated in meetings for lifting balloons
    so much, I tried it!  Took me three months of meetings to gather enough
    results to get my Raven Rally off the ground....
    
    I had a meeting at 3500' AGL over Northwest Albuquerque to discuss the
    results.  All in attendance (pilot and passenger) approved....
    
    Gil
    HOTAIR::BALLOONING Moderator
    

    Re: .24
    
    Right. With Tom S. flying around you in an airplane, being heard at
    LONG distances. 

    Responding to .0
    
    Yay, there are too many meetings, and what's worse, they never start
    on time.  I once scheduled a 2:00 meeting at 1:45 so that it would
    start on time.  One suggestion that I have is to schedule one weekly
    meeting for the project (if there aren't too many attendees).  Everyone
    gets to shoot the S#!% at that one meeting.  You can schedule the
    time well in advance.  People can come and go as they need to. 
    That's the way we work it with a project that I'm working on and
    it works out OK.  All but *emergency* issues could be addressed
    at the weekly meeting.  Have someone take an action item to schedule
    the weekly meeting.  I think that you ought to call a meeting to
    see who will take that action item.  
    
    Re: .23    YEAH!   Seems to me that the bureaucracy which can shroud
    a project is overwhealming.  Documentation for the documentation,
    VAXDOCUMENT everything, phase review this, phase review that, PMF, 
    Schedules, Milestones, Risks, Deliverables, Dependencies, FS, DS,
    IP.... blah, blah, blah.....
    
    I mean JEEZE LOUISE!  seems like developing the system(s) is becomming
    a miniscule task in the shadow of all the overhead.  OK, this
    conference is supposed to be for giving opinions, right?  Well here
    goes....
    
      A Functional Spec's main function is to establish blame after
      it has been decided that a system is not doing what it is supposed
      to.  It doesn't fix the problem, it just takes time away from the
      developers who could fix the problem or who could have avoided
      the problem had he/she been working on the system and not the
      FS.
    
      A Design Spec should be written AFTER the system has been developed.
      It is a valuable document but, as we all know, nothing ever ends
      up being developed the way it was originally planned.  Design
      decisions made everyday alter the original plan.  Writting a design
      spec up front is like building a cross that you have to keep dragging
      around *updating* every step of the way. 
    
      Project plans almost inevitably have shcedules that are never
      originally correct.  Each project should assign someone who's
      daily task it is to update the project schedule, not work on the
      system to shorten the schedule, just update the schedule.  And
      heaven forbid if you are not on schedule.
    
      Phase Review has it's place but (I think) that it should be informal
      and adaptable.  Phases should be added/deleted AS NEEDED BY THE
      PROJECT.  And whatever you do, don't document the phases, that
      just compounds the problem.
    
    I could go on and on about this but I'll cut it short (soon).  I would
    just like to say one more thing.  DEC is reputed as being a company
    that doesn't "hold your hand' when you set out to do a job. That
    excites creativity and should be left alone.  Don't give a new project
    a skeleton of bureaucracy that it MUST fill.  A good project manager
    should be able to gauge what documents/phases are needed for a project
    without stiffling creativity and production.  I mean after all,
    the bureaucracy's only function is to SUPPORT the
    DEVELOPMENT/IMPLEMENTATION of the project, not be a project in itself.
    
    
    later
    

    re .26:
    
    Documentation can be a pain *if* people forget that it has a purpose,
    which is to either define or drive a project.  The document itself
    is not the purpose.  If you only have a small project, with a few
    people working closely together for a relatively short time, you don't 
    need much, if any.  If the project is at all sizable, geographically
    or organizationally distributed, or longer term, you need more.  I've 
    seen some absolutely wonderful foul-ups occur because somebody didn't 
    "put it in writing" and thought they had one agreement while the
    others involved had a completely different idea or never got the
    word.  This can be great when you are trying to put together any 
    complex piece of software and you find you've been working for months 
    on the WRONG INTERFACE! (^(*^*%*&)(*&*^&*&).  Or when you arrive at 
    phase exit all alone.  Or when everybody else arrives without YOU.
    
    It would be nice if managers could read minds so they knew what
    everybody was doing and could tell that people had defined goals
    and plans for reaching them.  They can't.  Hence project and
    development plans.  I wouldn't hand a pile of money to somebody
    who hadn't demonstrated the ability to put a coherent plan together,
    would you?  (And a lot of things sound better verbally than they
    do after they've been put down so you can think about them and see
    if they fit together.)
    
    It would be nice if everybody on a project could read each others
    minds and come to some sort of nice, self-aware, warm, collective 
    agreement on exactly what the goal of the project was, what it's 
    internal and external appearance would be, and when various pieces
    are needed.  Too bad.  Doesn't work that way reliably for groups
    bigger than two or three people or projects that take longer than a 
    few weeks, in my experience.  Again, the project plan, and hence
    design and interface documents.
    
    Meetings can be controlled and made useful with planning and
    discipline.  Don't hold meetings without purpose, don't deviate
    from the purpose without good reason, and don't let them run on.
    Documents are the same.  Don't create one without a purpose, don't
    indulge in extraneous information or verbal obfuscation, and don't
    run on.  This includes the review process.  Reviewers must be relevant
    to the product/project, agree to meet a cut-off date, and be
    disciplined in their comments and meeting the date.  Done properly,
    a well documented project can be a joy to be on.  But it definitely
    takes energy and discipline.
    
    /Dave

    RE .27
    
    Yes, I DO agree with what you have said.  For relatively large
    projects, planning and documentation IS important because it serves
    a controlling function.  But sometimes, as you inferred, it can
    get out of hand.  I'm a software engineer who most often works in
    a group of 1 (myself), but am still required to write the entire
    barrage of documents and pass through the Phase Review Process.  
    I can't read the minds of others either, but if I can't read my own 
    mind, I'm in big trouble.  I communicate well with my business
    partners, I trust them when we agree on an approach and I know what 
    needs to be done.  I just want to get off the pot and go do it.
    
    The documents do serve as a formal means of communication to management
    and other groups involved in a project but there are situations
    when informal written or verbal communications can serve the same
    purpose.  Maybe someday I'll be in a managerial position and see
    the error in this way of thinking, who knows?
    
    Please excuse the *ferocity* of my .26 response, but sometimes I
    get a litle frustrated.  I see THE major deliverable of a project
    being the running system and not the administrative support that
    was needed during the development phase.  I've seen projects that
    conform to every aspect of the Phase Review Process deliver wonderful
    systems which work perfectly but failed because they were over budget 
    and far too late in delivery.  "The operation was a sucess but the
    patient died".  I just don't want my patients to die, that's all.
    
    Thanks for the response, it was well worded.
    
    

    re .26;
    
    >> DEC is reputed as being a company that doesn't "hold your hand' when
    >> you set out to do a job. 

    Nah, we just appoint a 3-level management structure and 2
    cross-functional committees to look over your shoulder...
    
    -dave

    re .28:
    
    Ferocious?  Why I hardly noticed! -)
    
    Yeah, it can get smothering, although I tend to regard that as
    a management failure rather than an indictment of the concept and 
    purpose of documentation (or meetings), which is why I jumped in.  If 
    your management is requiring the full, awe-inspiring panoply of phase 
    documentation for single person projects, they may have too much time 
    on their hands.

    /Dave

    From another conference:
    
    
             <<< HYDRA::DISK$USERPACK02:[NOTES$LIBRARY]DAVE_BARRY.NOTE;1 >>>
                       -<  Dave Barry - Noted humorist  >-
================================================================================
Note 256.0                   How to Attend a Meeting                   8 replies
SQM::RAVAN                                          127 lines  26-AUG-1986 21:32
--------------------------------------------------------------------------------

    To really succeed in a business or organization, it is sometimes
    helpful to know what your job is, and whether it involves any duties.
    Ask around among your co-workers. "Hi," you should say. "I'm a new
    employee. What is the name of my job?" If they answer "long-range
    planner" or "lieutenant governor," you are pretty much free to lounge
    around and do crossword puzzles until retirement. Most other jobs,
    however, will involve some work. 

    There are two major kinds of work in modern organizations:

    1. Taking phone messages for people who are in meetings, and

    2. Going to meetings.

    Your ultimate career strategy will be to get to a job involving
    primarily No. 2, going to meetings, as soon as possible, because that's
    where the real prestige is. 

    It is all very well and good to be able to take phone messages, but you
    are never going to get to a position of power, a position where you can
    cost thousands of people their jobs with a single bonehead decision,
    unless you learn how to attend meetings. 

    The first meeting ever held was back in the Mezzanine Era. In those
    days Man's job was to slay his prey and bring it home to Woman, who had
    to figure out how to cook it. The problem was, Man was slow and
    basically naked, whereas the prey had warm fur and could run like an
    antelope. (In fact, it *was* an antelope, only back then nobody knew
    this.) 

    At last someone said, "Maybe if we just sat down and did some
    brainstorming we could come up with a *better way* to hunt our prey!"
    It went extremely well, plus it was much warmer sitting in a circle, so
    they agreed to meet again the next day, and the next. 

    But the women pointed out that, prey-wise, the men had not produced
    anything, and the human race was pretty much starving. The men agreed
    that was serious and said they would put it right near the top of their
    "agenda!" At that point the women, who were primitive but not stupid,
    started eating plants. And thus was modern agriculture born. It could
    never have happened without meetings. 

    The modern business meeting, however, might be better compared with a
    funeral, in the sense that you have a gathering of people who are
    wearing uncomfortable clothing and would rather be somewhere else. The
    major difference is that most funerals have a definite purpose. Also,
    nothing is ever really buried in a meeting. 

    An idea may *look* dead, but it will always reappear at another meeting
    later on. If you have ever seen the movie "Night of the Living Dead"
    you have a rough idea of how modern meetings operate, with projects and
    proposals that everybody thought were killed rising constantly from
    their graves to stagger back into meetings and eat the brains of the
    living. 

    There are two major kinds of meetings:

    1. Meetings that are held for basically the same reason that Arbor Day
    is observed - namely, tradition. For example, a lot of managerial
    people like to meet on Monday, because it is Monday. You'll get used to
    it. You'd better, because this kind accounts for 83 percent of all
    meetings held (based on a study in which I wrote down numbers until one
    of them looked about right). 

    This type of meeting operates the way "Show and Tell" does in nursery
    school, with everybody getting to say something, the difference being
    that in nursery school the kids actually have something new to say.
    When it's your turn, you should say you're still working on whatever it
    is you're supposed to be working on. This may seem pretty dumb, since
    *obviously* you'd be working on whatever you're supposed to be working
    on, and even if you weren't, you'd *claim* you were, but this is the
    traditional thing for everyone to say. It would be a lot faster if the
    persons running the meeting would just say, "Everybody who is still
    working on what he or she is supposed to be working on, raise your
    hand!" You'd all be out of there in five minutes, even allowing time
    for jokes. But this is not how we do it in America. My guess is, it's
    how they do it over in Japan. 

    2. Meetings where there is some alleged purpose. These are trickier,
    because what you do depends on what the purpose is. Sometimes the
    purpose is harmless, like somebody wants to show slides of pie charts
    and give everybody a copy of a big fat report. All you have to do in
    this kind of meeting is sit there and have elaborate fantasies, then
    take the report back to your office and throw it away, unless of course
    you're a vice president, in which case you write the name of a
    subordinate in the upper-right-hand corner, followed by a question
    mark, like this: "Norm?" Then you send it to Norm and forget all about
    it (although it will plague old Norm for the rest of his career). 

    But sometimes you go to meetings where the purpose is to get your
    "input" on something. This is very serious, because what it means is,
    they want to make sure that in case whatever it is turns out to be
    stupid or fatal, you'll get some of the blame. So you have to somehow
    escape from the meeting before they get around to asking you anything.
    One way is to set fire to your tie. 

    Another is to have an accomplice interrupt the meeting and announce
    that you have a phone call from somebody very important, such as the
    president of the company, or the pope. It should be either one or the
    other. It would sound fishy if the accomplice said, "You have a call
    from the president of the company. Or the pope." 

    You should know how to take notes at a meeting. Use a yellow legal pad.
    At the top, write the date and underline it twice. Now wait until an
    important person such as your boss starts talking. When he does, look
    at him with an expression of enraptured interest, as though he is
    revealing the secrets of life itself. Then write interlocking
    rectangles, like this: <Picture of doodled rectangles>. 

    If it is an especially lengthy meeting, you can try something like
    this: <Picture of more elaborate doodles and caricature of boss.> 

    If somebody falls asleep in a meeting, have everybody else leave the
    room. Then collect a group of total strangers, right off the street,
    and have them sit around the sleeping person until he wakes up. Then
    have one of them say to him, in a very somber voice, "Bob, your plan is
    very, very risky. However, you've given us no choice but to try it. I
    only hope, for your sake, that you know what you're getting yourself
    into." Then they should file quietly from the room. 

[Reproduced w/out permission from the September '86 issue of "Reader's
Digest". 

    Winner of either the Pulitzer Prize or the Pullet Surprise.