MoCoW Analysis

MoSCoW Analysis

I recently came across the MoSCoW Analysis technique. Since I was not familiar with this terminology and thought that it seems to be uncommonly used hence tried to do some research of this technique. I was also curious to know whether it has any significance in the analysis of the Procurement function.

I’m trying to elaborate it to the best of my understanding for my friends in the Procurement fraternity. However please note that these are my views about the MoSCoW concept and can have differences of opinion from its usability point of view.

MoSCoW stands for Must Have, Should Have, Could Have, Won't Have, the o's make the acronym more pronounceable.

Many business units use the MoSCoW method to decide their business strategy. It enables everyone involved in a project to know what work to complete first and how that work helps increase revenue, decrease operational costs, improve productivity, or boost customer satisfaction.

On the business side, it can help stakeholders to decide the importance of specific product features when choosing a software vendor. On the IT side, the MoSCoW method plays an important role in?Agile project management?by helping project teams prioritize?story points.

In short MoSCoW analysis helps us to decide our priorities based on our business/function goals. In any project procurement, prioritization plays a vital role in quick turnaround however prioritization of tasks is always ignored in general practice.

If we make effective use of MoSCoW, we can prioritize well.

This method is structured to assist you in the range of your tasks as per importance so that you'll be able to target the foremost vital ones initially.

1. MUST HAVE:?You need to identify the tasks you want to accomplish that are essential for your function/business or success. You have already considered this stuff, so it shouldn't take ample time or energy to complete!
2. SHOULD HAVE:?These are the things on the list of priorities and important; however, they could lack a lot more attention than a "must-have." Should-have items are important for project completion, but they are not necessary. In other words, if the final product doesn't include should-have requirements, then the product still functions. However, if it does include should-have elements, they greatly increase the value of the product.
3. COULD HAVE: This category includes requirements that have a much smaller impact when left out of the project. As a result, could-have requirements are often the first ones that can be deprioritized -- must-have and should-have requirements always take precedence as they impact the product more.
4. WON’T HAVE: This final category includes all the requirements the team recognizes as not a priority for the project's time frame. Assigning elements to the will-not-have category helps strengthen the focus on requirements in the other three categories, while also setting realistic expectations for what the final product does not include.

Most of the points mentioned above are from a business or project standpoint and do not seem relevant from a Procurement standpoint, however, in my opinion, each procurement transaction itself is a project, and prioritization in a project or within a function is vital from a function performance perspective.

Requesting your valuable comments.