slightly OT: Project Managers

Having been to the pub tonight and bored for Britain on many a subject
there cam to my companions lips a topic of conversation that we came
quickly to verbal blows about; specifically, on IT projects, does a
project manager make an iota of difference to the outcome. My
colleague argues along the lines that he is knowledgeable in Six Sigma
(spit!), Prince 2 and now CMMI but does not believe that any of these
methodologies contributes one iota to the successful outcome of the
project. I believe otherwise, but am unable to find any evidence in
support of my argument. It seems that I may be wrong. As no Maclean
has ever been convicted of being wrong can any of you provide any
evidence of the efficacy or otherwise of any project managers? I have
read Dilberts excellent book so I realise this could be an uphill
struggle.

"Alistair Maclean" <alistair@ld50macca.demon.co.uk> wrote in message
news:d487f04c.0411191638.24b4cd84@posting.google.com...
> Having been to the pub tonight and bored for Britain on many a subject
> there cam to my companions lips a topic of conversation that we came
> quickly to verbal blows about; specifically, on IT projects, does a
> project manager make an iota of difference to the outcome.

Yes. In my experience a good PM can be the difference between success and
failure. (but then, I WOULD say that....<G> ) However, even before I became a
PM myself, I worked with good and bad ones. The difference is severe.

>My
> colleague argues along the lines that he is knowledgeable in Six Sigma
> (spit!), Prince 2 and now CMMI but does not believe that any of these
> methodologies contributes one iota to the successful outcome of the
> project.

He is right. All of these are based on the Project Life Cycle, which in
turn, is based on the Waterfall, which is fundamentally flawed in its
assumptions.

(I have written about this at length:
http://www.aboutlegacycoding.com/archives/v3/v30501.asp )


> I believe otherwise, but am unable to find any evidence in
> support of my argument. It seems that I may be wrong.

"wrong" is too strong... If you use the above methodologies and they work
for you, how can that be wrong?

I simply contend that there is a better way. Does the existence of a motor
car make a horse and buggy "wrong"?
(it depends on the roads, right <G>?)

As to the value of a PM on a project (or not) I have often had mail from
members of teams I managed, AFTER I moved on, saying how it was only after I
left that they realised the role I fulfilled. (I take that as a compliment
<G> ).

A good Project Manager should do the following (not in any particular order
but, in my book, all essential):

1. Support the team and use all of his power to see that necessary tools,
support, and proper working environment are provided.
2. Set clear direction, listen to objections, consider, and rule fairly
where a ruling is necessary. (I have seen PMs, swayed by the need for
approval, make rulings that would be the most acceptable... this is
inevitably, disastrous. I have managed projects where I was hated (even sent
to Coventry, on one occasion <G> ) for a period of the project. By the end of
that project, the SAME people who sent me to Coventry, refused to go on
another Project UNLESS I managed it. PMs are not in popularity contests,
they are in the business of successfully delivering systems. However, it is
true that if you achieve that, your popularity will increase...everyone
likes to be associated with success <G>.
3. The PM is responsible, not the team members. Protect your team and give
them unconditional support. If they screw up, deal with it one-on-one, find
out what when wrong, ensure it doesn't happen again. Don't accept blame or
excuses for yourself or others. NEVER denigrate anyone in your team to
ANYBODY!
4. Cultivate a blame free culture where people can make a mistake without
being crucified.
5. Encourage forthrightness from the team, and make it "Safe" to express
politically incorrect opinions (or non- "Corporate party line" opinions) as
long as they are honestly held and not simply for the purpose of agitation.
6. A good PM, in addition to his management skills, should also contribute
technically where possible. This builds respect on the part of the team and
fosters understanding on both sides. (This one is particularly useful where
team members, used to incompetent or non-technical managers, will try
"sandbagging".  It goes like this:

PM: "How long do you think it will take you to produce debugged code for
this?"
Programmer: "6 days."
PM: "OK, what other workload do you have? Maybe we can re-prioritize or
off-load some of that."
Prog: "None. It will take me six days to do this job. "
PM: "Is that really the best you can do?"
Prog: "Yes."
PM: "OK, then I won't give you that task."
Prog: "Huh?! Why not?"
PM: "Because I could write it myself in 2 days and I would've thought 3 or 4
would be reasonable for most people."
At this point there is some eyeballing and one of the following responses:
Prog: "OK. I'll do it in 4".
OR:
Prog: "Bullshit! You couldn't write that in 2 days...".
PM: "I understand your scepticism. We really don't know each other very well
yet. I'll deliver it in two days and you will buy me a beer and NEVER
sandbag your estimates again, OK?"
Prog: "OK. But I'll believe it when I see it..."

In my career I have had to actually deliver on this on two occasions. One of
them I sweated, because I had a lot of other work to do as well, the other
one was easy. On both occasions, the benefits (word goes round the team
pretty quickly, and code is something they can look at and assess) made the
effort well worthwhile.

7. Have team building sessions off site and reward goal attainment.
8. Make sure the credit for any achievements goes to the team (this may also
involve the Business as joint developers).
9. Enlist and nurture senior management support for your project. This is
invaluable, especially if middle managers become obstructive. (This happens
sometimes when they consider that a new  system will rob them of some of
their Empire or control...). On this, NEVER go behind their backs. It is
usually enough to take the line: "Well, it looks as if we have an impasse
here. I guess we need to raise it up the line. What do you say we set up a
meeting and both present our cases to (Senior Manager)?" (If you have
ensured the senior manager concerned has been kept informed by short wly
reports and verbal updates on occasion, and he has "bought in" to the
benefits of the system, it is unlikely you will be overruled.)

Now, you can see a PM as an "expensive overhead" or you can see him as a
"valuable facilitator" and both these viewpoints can be true for certain PMs
and projects.

I charge a lot for managing projects (it is less than IBM or Andersen would;
it is still a lot for mortals), but I do give a guarantee, and I do try and
deliver value for money. (I have done this successfully for around 20 years,
and was programming 20 years before that...)

Currently, I am looking at moving into another less stressful field. The
money in PM is hard earned.

>As no Maclean
> has ever been convicted of being wrong can any of you provide any
> evidence of the efficacy or otherwise of any project managers? I have
> read Dilberts excellent book so I realise this could be an uphill
> struggle.
>
Yes, I read (and thoroughly enjoyed) Dilbert's view on this too <G>

Pete.

..    On  20.11.04
wrote  dashwood@enternet.co.nz (Pete Dashwood)
on  /COMP/LANG/COBOL
in  307o9kF2tr3siU1@uni-berlin.de
about  Re: slightly OT: Project Managers


PD> Yes. In my experience a good PM can be the difference between success
PD> and failure. (but then, I WOULD say that....<G> ) However, even before
PD> I became a PM myself, I worked with good and bad ones. The difference
PD> is severe.

I liked your explanations, and there are two books related to the
subject which I like, and like to mention:


"The mythical man-month" by Frederick P. Brooks, jr.
Brooks was project manager at IBM in (for?) the System /360 and OS/
360 projects, later professor at University of North Carolina
The book was originally published in 1975, and has been republished
as 20th anniversary edition in 1995, with the addition of several
chapters.
Addison-Wesley, ISBN 0-201-83595-9


"The soul of a new machine"
which I have somewhere, but I can't locate it now. It tells the
story of the development of a new computer system at Data General,
centered on the role of the project manager. This one does not try to
pass lessons, but it is fine reading, even exiting.

I just googled for the title, and found the name of the author,
Tracy Kidder, that it was published in 1980, and that it seems to be
still available. On the first page of estimated 19'500 finds, there is
this review from Atlantic Monthly:
http://www.forum2.org/eran/shelf/soul-machine.html



Yours,
Lüko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Ein Buch ist ein Spiegel, wenn ein Affe hineinsieht, so kann kein Apostel he
rausgucken. -G.C.Lichtenberg

..    On  20.11.04
wrote  dashwood@enternet.co.nz (Pete Dashwood)
on  /COMP/LANG/COBOL
in  307o9kF2tr3siU1@uni-berlin.de
about  Re: slightly OT: Project Managers


PD> Yes. In my experience a good PM can be the difference between success
PD> and failure. (but then, I WOULD say that....<G> ) However, even before
PD> I became a PM myself, I worked with good and bad ones. The difference
PD> is severe.

I liked your explanations, and there are two books related to the
subject which I like, and like to mention:


"The mythical man-month" by Frederick P. Brooks, jr.
Brooks was project manager at IBM in (for?) the System /360 and OS/
360 projects, later professor at University of North Carolina
The book was originally published in 1975, and has been republished
as 20th anniversary edition in 1995, with the addition of several
chapters.
Addison-Wesley, ISBN 0-201-83595-9


"The soul of a new machine"
which I have somewhere, but I can't locate it now. It tells the
story of the development of a new computer system at Data General,
centered on the role of the project manager. This one does not try to
pass lessons, but it is fine reading, even exiting.

I just googled for the title, and found the name of the author,
Tracy Kidder, that it was published in 1980, and that it seems to be
still available. On the first page of estimated 19'500 finds, there is
this review from Atlantic Monthly:
http://www.forum2.org/eran/shelf/soul-machine.html



Yours,
Lüko Willms                                     http://www.willms-edv.de
/--------- L.WILLMS@jpberlin.de -- Alle Rechte vorbehalten --

Ein Buch ist ein Spiegel, wenn ein Affe hineinsieht, so kann kein Apostel he
rausgucken. -G.C.Lichtenberg