Posted by: Anonymous
on February 27, 2008 06:06 PM
Depends on the project and project management style. The three main types are feature driven, time driven, and ad hoc.
Most people tend to gravite towards ad hoc, which is usually why procrastination and project delays happen so frequently and why you often
get into the situation where everything is 95% finished for the last 6 months but nothing is really there yet, but it will be "real soon now"
once I get to these other two must have features.
The other two work well, but only if you're hard nosed about either schedule or feature creep. I personally find the time driven appearch easier
since you can always tell the customer (we'll add your feature in the next cycle but let's get a solid foundation that's usable now) than feature
driven because schedules tend to be longer and because of this, so the pressure to add "just this one feature" tends to lead towards feature creep and
unless classic Debian-like release slippages.
From my perspective there is just two differences between the two:
a) Open source projects face the same problems any volunteer run organization does. You may not have enough people who need to do a critical part of the project and even when you do, there's no guarantee that they'll do what they promise.
It's very tempting, to let people off the hook (especially if it's an understandable family emergency) or give people other chances (after all, they *are* volunteering and you may not have anyone else),
but if they're on the critical path and their work is important, you'll need to give their work to someone else who can do the job (without loosing volunteers) or make contingency plans so that their work (any any work that depends on them) may be removed. Inspiring your volunteers is also important or they'll lose interest and give up.
Overall resource management is extremely hard for such projects.
b) Corporations have a much easier time at this. They either have the resources or they don't, and if you don't, you need to put it in your project plan and plan contingencies. The key issue is not resources or getting people to do their jobs
but lying to yourself, your customers, and your bosses. The lying isn't always intentional. Sometimes you or your resources want to be a "good guy" and take on more
that is possible (especially if this is only one of many projects) and sometimes you or your resources want to look good or believe you can rely on some other
resource which you can't. A good project manager here needs to be very hard nosed and be able to say "NO" when a schedule is impossible because of resources, especially
when those resources are a lie or someone else says "Don't listen to him, I can do it in half the time", and must find ways of getting all those involved to be realistic and come up with reasonable alternatives or compromises.
a) Open source projects, except at the beginning, really don't have to worry about being strict with their schedule. Perl 6 is extremely late. Who cares,
Perl 5 is still good. Ditto for Debian. Sure things go stale after a while and competitors come into play (Ubuntu wouldn't have existed if Debian
had regular releases), and you lose motivation, but it's not that fatal as long as your foundations are solid and you have good maintenance of
the previously released project.
b) With corporate projects, you're getting paid to deliver and people's jobs (and sometimes safety or money) are at stake. Delays must not happen.
To use a non-software example, imagine that you bought a house that's being built and will be finished on June 1. You've rearranged your life
and made all the necessary irrevocable arrangements to move on June 1, but the house isn't finished and won't be for another 5 months. To you,
it doesn't matter that there was a strike and a shortage of lumber and a flood. You and your family *need* that house and the project manager
is to blame because he didn't plan all the contingencies, resource management, early notifications of possible delays, and in the worst case,
alternative temporary residences for the people involved.