Wednesday, July 25, 2012

Must do vs Should do

In my classes about agile methods and risk management, I entertain discussions about requirements management, and specifically whether or not students buy into Must Do/Should Do requirements--either in the RTM or the backlog

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'

Delicious Bookmark this on Delicious