Monday, November 5, 2007

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.

2 comments:

Mikey said...

One of the problems with being effective at PM is the lack of understanding of the management reserve. People begin to believe that the management reserve is fluff that be discarded. A solid 10% magament reserve of time and resources is what keeps things on track.

Upper management (IMHO) never seems to grasp the "You never have time to do it right but always find the time to do it over" concept.

Brandy Galos said...

Oh, I agree!!

I was in charge of the first mini-launch for Microsoft Reader at Comdex and I scheduled a full booth rotation for myself.

I nearly collapsed between that and running the show.

It's a really good point.