I*ve used the MoSCoW model (but I'm not project manager, I'm developer) and I think it is good. But I also think that you can tell me more and perhaps find a drawback that I didn't think of while I say to friends and colleagues that MoSCoW model is a good project management model. Can you tell me about potential pitfalls using this method? I identify the tasks and identify whether the task is a must ("M"), what we should ("S"), what we coudl ("C") and what we won't ("W") right now. Perhaps a potential pitfall is that I almost always end up working only with what the project must do and the shoulds and coulds are just listed and almost never implemented.
Add a comment
|
3 Answers
Here are some pitfalls I've seen with the MoSCoW model.
Managers are worried that their requirements will fall into "should" or "could", and won't get done, so they make up reasons why their requirement is a "must". This ends up delaying business-critical functionality. (This is usually caused by, or exacerbated by, bad KPIs at an organizational level. I'm not sure there are any good KPIs when they're tied to pay. In fact, I'm pretty sure there aren't.)
Time is spent discussing things that "should", "could" or "would" happen, delaying progress on the things which are absolutely essential. This is exacerbated by managers worried about the elements of the project which would help them achieve their goals, but which are not immediately essential (KPIs, again).
Managers use the "should", "could" and "would" requirements as ways of getting extra budget, which they then spend as buffers for the "must". (I also love Beyond Budgeting).
Architects and people in charge of other shared dependencies spend time creating support for all possibilities, instead of focusing on what "must" be done. Because it takes longer to actually create all the "coulds", "shoulds" and "woulds", it takes longer to prove the architecture, so the feedback on whether the architecture is appropriate takes ages too. This is one of the things that causes architects to act as such strict gatekeepers, and to spend ages designing architectures in the first place.
Frequently, the things which "must" be done are ideas which haven't been proven, nobody uses, and which eventually get thrown away anyway. If they were released earlier, they would also be discarded earlier, but by the time they're released along with the "should" and "could", they're woven into the fabric of the application or system, and retirement is far harder. Pivoting (a la Lean Start-Up) becomes impossible.
Hence why I tend to encourage people to differentiate between "must, right now", focus on developing and getting feedback on an MVP which is as tiny as possible, and then worry about what the next "must, right now" is. Done deliberately and with forethought, this leads to developing architectures, communication patterns, organizational relationships, etc. which are easy to change, rather than right (see also Real Options).
The greatest advantage is when you bring in a variety of stakeholders and talk through their different opinions on what needs to be done. Treat MoSCoW as a tool to help facilitate the discussion and document the consensus. This will help to get broad buy-in around what the product needs to be comprised of, hopefully avoiding rework downstream.
Contrary to @Jonathan Miles, I'd question the assertion that it is simple. I've run into problems when stakeholders start worrying too much about the semantics of "Should Have" and "Could Have". This may just be bad luck on my part, but typically I've reduced MoSCoW to a MustHave-NiceToHave paradigm, where the former is in scope of the project and the latter is put on the shelf.
Frankly I don't see only working on the "Must Haves" as necessarily being a pitfall, as delivery of "Should Have" and "Could Have" functionality usually follows the laws of diminishing returns.
A definite advantage is it's simplicity, you shouldn't need prior knowledge or training to understand the concept. It uses human language to prioritise and define requirements rather than a specific scale, or measurement.
Although the obvious counter argument is that it can be too simplistic, and doesn't provide enough information on what should be actioned first. You may have come to a consensus on what MUST be delivered and have a list of half a dozen tasks, but which are you going to do first? Which tasks depend on other tasks? Where is your critical path? From a project management perspective there will be a lot of unanswered questions.
In my opinion it's a simple yet powerful tool for initial, high-level requirement prioritization. It's a great starting point for a project, knowing what needs to be delivered and what can initially be deferred helps greatly with decision making.
Although as a side not, and I realise this isn't specifically a disadvantage of the method itself but rather it's implementation. Relying too heavily on one persons/teams list of requirements can be disastrous. Say you got all your developers together and drew up a MoSCoW prioritisation list, what does that tell you... here's a list of what the development think we should be doing. But what about the business, customers, other stakeholders etc. are they being represented. Good project management means understanding requirements of all the project stakeholders, so if you decide to use the MoSCoW system ensure you have representation (and consensus where possible) from all stakeholders.