Not all project requirements are created equal
Some project requirements have more weight than others, at least in the minds of project stakeholders. And of course, stakeholders are unlikely to be in perfect agreement on the importance of all requirements.
That’s where the MoSCoW method of prioritizing requirements can be quite handy. If you haven’t used this method before, it usually goes something like this:
Must Have – The requirement must be met precisely as stated, or the project will fail.
Should Have – The requirement must be met, or a workaround must be found.
Could Have – The requirement is only for better satisfaction or project outcome.
Won’t Have – The requirement is not necessary for now, but we could have it in the future.
If you search the web, you will find similar definitions.
But in the real world
In practice, however, I have found these definitions are often confusing to stakeholders, which can make it difficult to get agreement on requirement priorities. First is confusion over the word “requirement.” Many stakeholders believe that all requirements must be met, or it isn’t a requirement at all. They aren't necessarily wrong. After all, the Oxford dictionary defines a requirement as “A thing that is compulsory; a necessary condition.” But a seasoned project manager knows that if all requirements are prioritized as Must Have, the project is doomed from the outset, given the "precisely as stated" restriction above.
If you can get past that hurdle, the next stumbling block is the difference between Must Have and Should Have. This is where I see the most difficulty, and it really comes down to semantics again. Most stakeholders who have never prioritized requirements using this method struggle to articulate their confusion. But I’ve learned that what they are really saying is “If we are willing to accept a workaround, then can’t we just reword the requirement to say that, then prioritize it as Must Have?” The bottom line is that they still can’t shake the innate desire to prioritize all requirements as Must Have.
Then, there is Could Have. Most people are more familiar with the phrase “nice to have.” With Nice to Have, it’s clear that the project hasn’t failed if the requirement isn’t fulfilled or is only partially fulfilled. It really is just icing on the cake. In my experience, even with the definition of Could Have prominently displayed on the whiteboard during brainstorming sessions, stakeholders still refer to it as Nice to Have.
And finally, there’s Won’t Have. To me it just sounds weird, and the definition above can mislead stakeholders to believe that these elements of the project will continue, even after closure. Or perhaps it’s just an empty promise, which feels unsatisfying. That’s why I believe that the project management vernacular “out of scope” is a better alternative. To most stakeholders, requirements that are Out of Scope are correctly interpreted as things that won’t be accomplished within the project, period. Which as project manager, is exactly the clear interpretation I need them to have.
MoSCoW simplified
So that leaves us with a simplified model that looks like this:
Must Have – The requirement must be met, or the project will fail.
Nice to Have – The requirement is only included for greater satisfaction or a better outcome.
Out of Scope – The requirement is specifically excluded from the project and will not be addressed.
I have found that stakeholders have very little difficulty prioritizing requirements according to this scheme. MiNnOw, if you need a way to pronounce it.
So great, now we have clear, working definitions for prioritizing requirements. But the way a requirement is written is still open to interpretation and can make it difficult to determine if it has been met. So how can you be sure? The answer is acceptance criteria. If you state precisely the conditions, tests, or deliverables that constitute fulfillment, then it should be clear when a requirement is met, and that makes it much easier to close the project when the time comes.
Good acceptance criteria are usually tangible. For example, a document, a successful test, survey results, a prototype, or an event. It’s sometimes necessary to be even more specific and state the first draft of a document, or the first successful test, so the requirement can be met, and the project can continue until the final deliverables are ready. Once you have your acceptance criteria for each requirement, they’re ready to include in the project plan.
Clearly defining and prioritizing the requirements also pays off in the end. When it comes to project closure, all the Must Have requirements should be fulfilled, meaning that all their acceptance criteria have been met.
Project EMC2 can help
Fulfillment of requirements is one of the errors that Project ECM2 checks at project closure. Other checks include overall project status, no missing critical information, all activities are completed or canceled, and all risks and issues are closed. This gives you and your stakeholders assurance that the project is indeed ready to close.
