This is another way of talking about MoSCoW (except I've shorted this discussion to just the M and S)
- M - MUST: Describes a requirement that must be satisfied in the final solution for the solution to be considered a success.
- S - SHOULD: Represents a high-priority item that should be included in the solution if it is possible. This is often a critical requirement but one which can be satisfied in other ways if strictly necessary.
- C - COULD: Describes a requirement which is considered desirable but not necessary. This will be included if time and resources permit.
- W - WON'T: Represents a requirement that stakeholders have agreed will not be implemented in a given release, but may be considered for the future.
So, most of my hardward project students say: Once the customer has decided on the RTM, there's no debate and no M vs S; everything's a M;
And, most of my software project students say just the opposite: there's room for the S's in the backlog; and
Most of my students who deal in the public sector or work through contracts, regardless of the technology, say: a contract is a contract... there's no room for the S's.
What do I say? I say requirements (a synonym for scope) need slack just like the schedule. A plan without slack is more a hope than a plan. If both scope and schedule have slack, then by extrapolation the budget has some slack. The payoff for slack is predictability.
Some may call it sandbagging: fair enough, sometimes there are sandbaggers that give the slackers a bad name. But nobody can predict with anything other than prayers where a no-slack project is going to wind up.
I used to build hardware; a lot of it and complicated stuff. I never met a RTM that didn't have some flexibility in it, even with a contract. Now, an enlightened contract will be an award fee contract. An award fee contract rewards (with an award of fee) thinking and innovation. What's not to like about that?
I never accept "never" in the project business. We're not doing six-sigma production; we're doing stuff for the first time, and so we can expect 'stuff' to happen. That's where slack comes in... to handle the 'stuff'
Bookmark this on Delicious 
