>>What's always worked for me:
>>
>>- Identify every task
>>- Every task MUST have a deliverable
>
>I agree entirely! However, that can be, in itself, a major project when dealing with a large development.

Certainly; it's a function of analysis and design. It's the plan that drives subsequent development. And if the analyst(s) / designer(s) were not competent ...

>>- Use project management software for precedence diagramming, critical path analysis, resource allocation / leveling, progress monitoring
>
>This is a little harder. As I said at the start, the snage with measuring progress in software projects is that it is rarely 'linear'. YOu can be 80% done after 1 day and still miss a 4-day deliverable <s>

It's simply not practical to manage a project with 10 - 20 resources and hundreds of activities "manually"; that's why I advocate PM software. It's no substitute for intelligence and skill; it simply helps with the drudgery.
At any given time, there are still only a limited number of tasks under direct focus which are manageable due to the (maximum) "4-day" production schedule of any given deliverable. The "small deliverables" are so visible, there is rarely a problem or issue of "percentage complete" ... since they are so small, it is very easy to get them back on track, typically with a bit of assistance from the PM / Project Leader.

>Agreed! This is in line with all good practice. Do you also advocate "weekly builds"? (That is something that I like to see too because it helps keeps people focused on 'shipping').

Generally, there is a "user schedule" that runs in parallel with the production of the deliverables. I'm for a staged releases, so the user is intimately involved in integration / subsystem testing. The users become familiar with the system even while it is still in development as each "subsystem" is released. There is not so much a "weekly build" as there is a subsystem build as each subsystem is assembled. Typically, the "master file" subsystems are released first; it's an excellent way to get users creating production-class "test" data for the development team.

>Not so sure about this one. I would prefer to have developers fix bugs that come up during integration. Once past that point I would hand it over to the 'maintenance' team.

It's part of change control. As "project leader" I typically handle this. Users come to me with issues and I handle them, instead of "pulling" a programmer off what they are doing, interupting their current train of thought, and having them visit a program they may have been working on a month or more ago. It's simply more efficient this way.