>The most difficult thing in any software project (of significant size) - tracking and assessing 'progress'. To do so you need to have good estimates of the work scope and the time required. As a project manager (I project managed Civil Engineering and other non-software specific projects before becoming a programmer) the one thing that I find that continually frustrates software projects is the Estimation/Progress cycle. It comes down to to two key questions:
>
>[1] How to come up with a reliable estimate of time (and hence costs) for developing a software application
>[2] How to ensure that the actual development is on schedule

What's always worked for me:

- Identify every task
- Every task MUST have a deliverable
- Use project management software for precedence diagramming, critical path analysis, resource allocation / leveling, progress monitoring
- No task is allowed to take longer than 4 days (without a deliverable) ... in a 5 day work week (this all allows for a 1 day contingency per week for sick days, unscheduled meetings, unproductive time, etc). If a task is "scheduled" to take more than 4 days, the problem hasn't been partitioned properly and the task has to be repartitioned. The rapid production of deliverables also keep enthusiasm up, for the developers and end-users alike.
- Everyone has to "buy" into the schedule; developers must agree that their time allocation is reasonable; no one is "forced" to accept a schedule that they do not feel is reasonable. Typically they will feel (with a reasonable schedule) that they can do it faster and will work that much harder to prove their point.
- Ideally, assign a separate body for bug fixes (identified during integration testing); keep developers "developing"
- Weekly status reviews / meetings and an open door policy; developers are expected to come forward "before" the "end of the week" if their deliverable may be missed. This insures that you will never be more than "4 days" behind schedule (ie. a missed deliverable)