[MUD-Dev] Re: DevCore Project Management

[Darrin Hyrup]

At 03:57 PM 11/3/98 +0100, Ola Fosheim Gr=F8stad wrote:
>Jon Leonard wrote:
>> 1) Is there a better choice for "dictator" (project maintainer)?
>
>Who knows?

There is also no reason to automatically bundle the project leader
(benevolent dictator) with the project maintainer role.  In fact, in some
ways it is probably better that they be seperate so they can concentrate on
their 'jobs' more effectively.  But, either way could work if that person
has a lot of free time.

>First of all there are (at least) two ways to manage a project:
>
>1) a manager who gets to decide=20
>2) a coordinator who makes sure that questions get asked and decisions get
>   made(but doesn't neccessarily contribute to the decision)
>
>General american business management seems to go with 1. Modern flat
>organizations seems to go with 2.  2 is judged to be the better approach
>with "smart" people for a number of obvious reasons I shall not get into. I
>assume 2 would work best with volunteers, and is what "project maintainer"
>indicates.

I prefer #2 influenced by #1.  I suggested a more 'team oriented' approach
like this a week ago or so.  In this approach, each major area of the
project is broken up into groups which are connected together like spokes
in a wheel (or leaves of a tree), which may have other sub-teams within
them which specialize in particular elements of a project area. (i.e., the
team that handles i/o interfaces may have a sub-team which oversees telnet,
another one that deals with custom protocols and works with the UI group to
create a graphical FE, etc.)  Each group (team) has a lead who's job it is
to keep the team on target, and moderate discussions relating to their part
of the project.  When a team cannot make a decision, the team lead can
either make a spot decision, or the problem can be sent up one level to the
team which oversees them (which could be the top node, which means the
whole project) so it can be deliberated on.

I think something like that would be the ideal solution.  Each group could
elect their own lead (or it could rotate) to insure there was no ego=
 bruising.

>What are then the duties that follows being a coordinator?  This is
>something one should get to an agreement on.
>
>This is what I see as some duties:
>
>- control progress (and make sure changes are made if progress is low)
>- predicting and resolving upcoming conflicts among team members
>- sweet talking volunteers into doing the boring jobs
>- being able to redistribute jobs and making sure that the general attitude
>is "this is ours" rather than "this is mine". (why did you throw out MY
>superior code)
>- keeping track of the missing bits
>- making sure that the bigger picture is taken into account
>- quitting when one realize that coordinating takes too much time
>- keeping a record which ensures that somebody else can step in

I agree with this completely.

>Here are some properties which I think makes a good coordinator:
>
>- he has an interest in seeing the project done, but has no rigid opinions
>on it
>- he is prepared to spend most of his time doing coordination rather than
>coding
>- he is good at keeping people happy even when they have good reasons for
>not being happy
>- he is capable of making sure that the project doesn't suffer from keeping
>everybody happy
>- he is generally being a picky and annoying person, without being=
 perceived
>as one
>- he is not afraid of asking the stupid questions, and prefer asking rather
>than assuming "I think I understand/know".
>- he is not afraid of asking how things are going, when they are expected=
 to
>be done, and if somebody else perhaps should help out
>- he is more interested in organizing other people's opinions rather than
>stating his own
>- he is more inclined to make sure that people have what they need to be
>productive rather than to do things himself
>- he is willing to do the boring bits that nobody wants to do
>- he loves bookkeeping
>- he loves people
>- he knows a lot about groups of people...
>- he knows and admits that he doesn't know...
>- he is more concerned about progress and QA than becoming a leader

And with this as well. ;)

>Just to illustrate, here are some reasons for why I would make a lousy
>coordinator:
>- I am uneccessarily sarcastic
>- I get too many new ideas and loose interest too quickly
>- I find it easier to do everything myself than to get other people to do=
 it
>- I enjoy playing the game "defending my opinion"
>- I don't admit what I don't know
>- I don't communicate a love for everybody
>- I don't record and investigtate everybody's opinon
>- I prefer doing creative work
>- I don't have enough time

I also would not wish to be coordinator for many of the same reasons.  Plus
I really would like to code and I don't want to get bogged down with
administrative work.  I already manage 2 design teams and just took over as
technical manager for another huge project, so I think that is enough
management work for me. :)  But, as I said before, I volunteer to help out
with the coordination if it is needed.

>Just some more illustration. If people are to be judged by their=
 activities,
>here are some related to coordination which have been spotted in mud-dev:
>
>- JCL provides structures which allows other people to be productive
>- Chris G makes sure he understand by asking questions where other people
>are afraid of loosing face.
>- Raph organize a statements taken from mud-dev and put words on his
>experience
>- Marian follows discussions even though she has little interest in
>programming, and she openly admits what goes "over her head".
>
>I don't know of any obvious coordinator in mud-dev, if I were to vote=
 (which
>I am not) I probably would have voted for Chris Gray.

I have to admit, that I also agree with this.  Although I suspect Chris is
probably too busy to do this either. :)

Best,

Darrin