The knee-jerk response to prioritizing requirements is to mark everything as a must-have . I need everything before the product becomes generally available. I want it ALL! Give me a break.

Granted, if a requirement is written in the SRS, then it must be because you want it. But the reality is some features are more important than others and a good product manager can tell them apart.

If everything is high priority, then there are no priorities. Let me repeat that statement once more. If everything is high priority, then there are no priorities.

Unless this is your very first software project, you know that time is always a constraint. Combine an overly optimistic project schedule with a list of requirements that aren't prioritized, and what do you get? A team of developers that implement what they want, when they want.

You have a choice. You can (a) leave it up to the development team to pick and choose their favorite features to implement, or (b) give them a clear sense of direction by prioritizing the requirements. Have them start with the must-haves, followed by the nice-to-haves. When the project deadline comes up, you can decide to extend the project schedule to add a few more nice-to-haves, but you won't be forced to because your product will already include all of the must-have requirements that would make or break your sales. In other words, you're managing the schedule instead of letting the schedule manage you.

Wondering how to best prioritize requirements? Check out First Things First in The Project Mangler's archives.