PM Q: What causes a project to slip?

Q: What causes a product or project to slip schedule in your opinion? Where have you had the most problems in the past?

Mistake #1:

Everything in life is a tradeoff and software projects doubly so. Oversimplifying a little, the three variables of software projects are the amount of resources (and that typically means people), the product’s features and lastly, the time to market. You can not change one without affecting at least one of the others.

There are limits to this. Getting 100 people to do 100 features in a week would, in fact, create a program, but probably not something that would be a good program.

If time to market is the number one priority, then features and/or resources must be ruthlessly adjusted to keep the schedule on track.

Mistake #2:

Not enough buffer in the schedule. The different team members will give you estimates of how much work the different tasks require. The key word is estimates. There are a lot of techniques you can use to maximize the accuracy of the estimates, but in the end, people are always going to be optimistic and the only way to address this is to make sure there is room in the schedule for mistakes.

My Feelings:

It’s not IF the project will slip, it’s WHY the project slips.

Projects where the date is the most important thing are called “Slogs” or “Death Marches”. You can’t ask a team to do too many of these without repercussions. Projects that allow features to change or new ones to come in willy-nilly never ship and are just as painful to work on.

I like a reasonable number of milestones whose dates are adjusted as they approach. If too many milestones are coming in late, then program management digs in and figures out why, fixes it and then adjusts the rest of the schedule.

And to keep things more fun, besides the normal buffer, put in some time at the end for creative new ideas and market course corrections.