It has been suggested that context is somehow irrelevant. This notion seems to start around the criticism of the MoSCoW requirements method where requirements that implement the needed capabilities of a system are categorized.
MoSCoW means: (how it got the moniker I have no idea) and is a well developed method of eliciting requirements in a paradigm where the customer has some notion of what done looks like. If this is not the case, no method will help and the norms of project management are no longer effective - it's a Chaos mode. So in fact MoSCoW has no value and the suggestion may be true - in Chaos we don't need requirements elicitation methods.
But let's assume we're not in chaos and we actually would like to know something about what Done looks like, how much it might cost to get to done, how long it might take, and what of value will be produced when we reach done.
- M - Must Have - our mission will fail without these being available when needed
- S - Should Have - our mission will be successful, but it would be much better if these are deliverd as well
- C - Could Have - if we can have these, our result would be better
- W - Won't Have - we don't need these requirements, in fact many times, we want to make sure these are not included (excluded) from the outcome of the project.
But for projects operating in the other three uncertainty modes - variaton, foreseen uncertainty, and unforeseen uncertainty, the first question is actually the inverse question ...
Why would we NOT prioritize the requirements using this or a similar mechanism?
Let's look at some content in the notion that prioritizing requierements should be ignored. A requirements Trade Space is mandatory on any non-trivial project for some very simple reasons:
- There is never enough time and money to satisfy everyone's need
- There is always a deadline for going live with the results to the projects
- There are always changes in the needed outcomes, so the requirements process must have margin meaning we can't commit to everything at once.
Below is an example (at the end) of a program that has a minimum set of capabilities fulfilled by the requirements, where the Program Manager and the Customer managed the success with ruthless adherence to a schedule and the needed capabilities.
This example might serve as a paradigm for other mission critical projects.
- Page 19 shows how to assign misson needs to Measures of Effectiveness and Measures of Performance through the requirements. If a requirement doesn't support a capability, drop it when the going gets tough.
- Page 26 shows our team discussing what requirements will be delivered when.
- Page 37 shows the issue of managing a project in the absence of a clear and concise description of where you're going.
- Page 54 starts the Star Dust mission description.
Now the question is can this paradigm or context be applicable to small group, agile software projects? Turns out Star Dust had small team software intensive software components. As Shim says think about it.
