Re: Tips for managing Perl projects?

Why do large projects have such an abysmal failure rate? Large companies that can afford to throw a half million or more at a project don't do so on a whim. They spec out the project and determine if it's feasible. And despite this, it still fails. Why?

It fails due to information costs. Those costs are frequently not considered when the project starts and the larger the project is, the greater the informatin costs. For example, Alice is the boss of Bill and Charlie. Alice happens to tell Bill something that Charlie should know and expects him to tell Charlie. Bill tells Charlie Bill's understanding of what Alice said and Charlie writes bad code because his specs are wrong. However, he doesn't know to ask Alice what the correct specs should be because he had no reason to think he was heading down the wrong path.

Obviously, if you have one manager and only two programmers, this is less likely to happen. However, as a project grows, these sorts of miscommunications continue to occur and the poor Charlies realize something is wrong so they keep trying to double-check their information and this raises overall costs (which is why I refer to "information costs", sometimes known as "search costs").

Part of the reason XP is so successful is that it defines a lightweight system where everyone has a clearcut role and you know exactly where you should turn for any information you need. Everything in successful project management is about lowering these search costs. Any time someone has a question, they can immediately receive timely, accurate and complete information. If you can pull that off, you'll probably be a successful project manager. Mind you, this isn't saying you should go the XP route, but if you do, it's frequently a quick route to success.

Cheers,
Ovid

New address of my CGI Course.

Comment on Re: Tips for managing Perl projects?

Replies are listed 'Best First'.
Re^2: Tips for managing Perl projects? - I'm ranting & going off topic here. by Joost (Canon) on Dec 16, 2004 at 00:09 UTC
I agree with your observations but... As far as I understand it XP is mostly about eliminating project management by having the client sit down next to the programmer and telling him directly what he's expecting from the program. I'm not saying that's a bad thing; most programmers could certainly do with more direct communication with the client. I do think it doesn't solve the problems in a project that's already running - the client simply never has the time to do this. Last project I did that went horribly wrong, we had more than 10 programmers working at the project 8 hours of every working day - we were lucky if the client could spare one person 4 hours per week to help us out with the specs. Ofcourse almost all of that time was spend by management promising the client golden castles in the sky instead. This particular project went over the deadline by more than 20 man-months (original estimate: slightly over two man-months - yes, the estimates were that bad) And ofcourse, the client expects the project managers & programmers to be clairvoyant anyway :-). I think most of the problems in the project described above were caused by just plain awful specs and cost-estimates coupled with horrible management from all sides. I think the most important lesson I learned from that project was that you simply cannot spec & build anything without really understand what the client wants - not what they tell you they want: what they really want - what their goal is, how much they want to spend on it, and what their priorities are. Let's back up a bit from there: I think I've spotted a recurring theme from all the projects I've done that went bad (as in: over budget and/or made me feel terrible and stressed out) The most important thing you need from a client is a list of functionalities ordered by priority. Get this list before you start designing. It will make the client think about what it is they want, and you can (hopefully) see from that list what it is they actually think is important about the product. At least 50% of the time, you'll be really surprised (and then you can probably talk him out of paying for weeks of development on that really annoying piece of functionality that the client actually doesn't give a damn about, but was just put in the specs to stop somebody nagging in a meeting). I quit that job by the way - I feel much better now that I'm self-employed :-) "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^3: - XP is still project management by Ovid (Cardinal) on Dec 16, 2004 at 03:47 UTC
As far as I understand it XP is mostly about eliminating project management by having the client sit down next to the programmer and telling him directly what he's expecting from the program. This is not eliminating project management. It's about improving information flow. There's still a project and the work is still being managed. It's just not being managed with a bunch of charts, out of date documents or unwanted features that are hidden away until they are revealed a few months past the deadline. Just because it's not being done the old way doesn't mean it's not being done (or that the old way is necessarily bad, for that matter.) Cheers, Ovid New address of my CGI Course.	[reply]
Re^3: Tips for managing Perl projects? - I'm ranting & going off topic here. by chromatic (Archbishop) on Dec 16, 2004 at 02:49 UTC
the client simply never has the time to do this. That's easy. The client really doesn't want working software.	[reply]


No such thing as a small change
	PerlMonks