Project planning

I read this good article on Gamasutra today: Making Great Games In 40 Hours Per Week (login required, free signup)

A few points I really liked:

• "someone must be functioning effectively as the builder and keeper of the schedule". My personal additions to this is: Some people are better at managing project plans and schedules and estimates than others. The *someone* who owns the schedule should be a technical person, capable of understanding the details of a task. Without the technical knowledge they cant judge the quality of estimates given by the engineers. Also from my experience with XP, I favor measuring the progress on tasks frequently. This feedback is important to keeping the schedule in touch with reality and knowing when its time to replan.
  
• "There should be no such thing as a five-day task" If your task estimate is 5 days, then you need to drill down into more detail to make your estimate. This is difficult in Analysis and Design phases of the project when so much can change later. I agree tasks should be examined in detail to get estimates. However, this detail can create the illusion that your estimates are accurate. More times than not, your estimates are still inaccurate. A multiplier or fudge factor is still required to allow for changes during the project lifecycle.
• "Know What Can and Can't Be Cut". Yes, I learned this the hard way on a recent project. The timeline was set by business factors so that only a minimum implementation could be completed on time. Unfortunately we had nothing to cut! So when the unavoidable technical problems happened, schedule slipped. A project should always have prioritized features, and some fudge features that can be cut.
• "we (usually) add a fudge factor - from 15 to 25 percent - for unexpected events." Howie says he uses a percentage multiplier. I'm impressed that his multiplier is only 0.25. In my experience, I've learned the multiplier depends on the person(s) giving the estimate. Some people typically give more accurate estimates, other people tend to give more optimistic estimates. In addition to the reasons Howie lists for a fudge factor, I would add *reality changes*. That is, during the lifecycle of a project, requirements become invalid because the real world outside is changing. Therefore a project plan must include a fudge factor for *reality changes*, and plan to revisit and modify some percentage of the requirements in the middle of the project's development.
• "Regularly Update Your Schedule" This gets back to my prevoius comment about tracking progress and replanning.
• "Use Overtime Sparingly" Howie goes on to talk about scheduling crunch time. I still prefer adding fudge factors to the plan. Fudge factors come in two forms: features that can be cut and good fudge time added to the plan. However, even the best plans can get into trouble. So I liked his ideas of planning and scheduling crunch times. My last project had crunch time in late December! Yuck!
• "People-Management is Critical" I have yet to work at a company that really does a great job at People Management. However, pretty much all companies I've worked for have done a fair to good job at people management. I guess it is just a trade off between productivity and cost.