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.

PM Q: How do you prioritize features?

As many of you know, I'm interviewing for a new job. It's going really well. Yesterday I had to write up a screening document and I thought I would share some of my answers here.

I wish I had had a few more days to polish and simplify my answers, but they are still comprehensable. I start the document out with just about my favorite Mark Twain quote: “I'm sorry this letter is so long, but I did not have time to make it shorter”

-----------

How do you prioritize features? What criteria do you use?

At the highest level: Must have, Should Have, Could Have.

Although generally worked out long before a feature list, big items like business priorities, time to market, globalization, industry laws/standards, revenue models, applied laws, and other items at this level are the first stop.

And I like a very tight vision statement or mantra that the whole company believes about a release. It needs to be so clear that it is immediately apparent to everybody on the team if a feature moves the release in the right direction or not. For example if this release is all about making sure we find every document, we would prioritize supporting the Macintosh over features that go very, very deep into specific file types.

I like the feature team itself to make this call. I like for the developer and tester to sit down with the PM and talk about the features in context and make the first stab at it.

I also like good user and market research, based on science if at all possible. Things like usability testing, experimental releases, betas, etc. Periodic customer Strategic Design Reviews are great. I want to know the other products in our market space better than most of their employees do.

I like to do feature level SWOT analysis: Strengths, Weaknesses, Opportunities and Threats. This can keep the most important issues front-of-mind even if they are not that obvious. Sometimes it a feature looks very cuttable until you remember that this feature plugs a hole that could keep the company out of trouble in Indonesia.

If I’m pulling together a team wide prioritized feature list then I typically need to do some balance between the different feature teams’ prioritization. With all of the above data, matching these up is generally pretty obvious. Then I publish the list in an easy to understand manner and gather feedback and make adjustments. If possible, I would love to do a team offsite on this and get bottom-up buyoff and feedback. The more I can get the team on the same page here the easier the rest of the journey is going to be.

And one last thing I like is to have some space at the end of the schedule for a feature to come back. I create a mini-milestone that can be used as extra buffer if needed or for the team to sort through all the postponed features and new ideas and pick a few that are implementable. This takes the pressure off any one feature cut and also gives a way for the team to be more creative or more responsive to any late breaking market pressures.


-------

More soon...