Most project teams I work with prioritise their work in a simple order: most important, second most important, etc. But sometimes people still use the MoSCoW method, and I find this leads to problems.
MoSCoW stands for Must, Should, Could, Won’t—it’s a way of categorising deliverables into one of four buckets. The Musts get done first, then the Shoulds, and finally the Coulds. The Won’t don’t get done at all. The good thing about this approach is that planning is quite straightforward—it’s pretty easy to drop each deliverable into a bucket.
But I find there’s a problem with MoSCoW that impacts project delivery. The problem is that it’s too course-grained. The time available for the project will almost always not allow us to deliver just the Musts, or just the Musts and Shoulds, or all of the Musts and Shoulds and Coulds. As a result, when time runs out we end up having done a largely-random selection of the last category.
The problem is even worse if time doesn’t allow us to complete all the Musts—and I find this is usually the case. Even if our initial estimate suggests we will have sufficient time it rarely turns out like that in practice.
So if we must do all the Musts, and there’s no priority order among them, then we end up doing them with slight randomness. We might first pick the most obviously important one, then maybe do one which is quite interesting, or which a key stakeholder suddenly expressed an interest in, and then pick up an item that’s convenient, and so on. When we realise time is running out faster than we thought it’s too late. We realise, after all, that some of the things we’ve delivered are less important than some of the ones we won’t have time for. We regret spending time on some of those items, but we can’t turn back time. Our project under-delivers, or we have to let it run late.
Prioritising in strict order is a much harder exercise, but it does ensure we get the best out of our time, and so is much more likely to lead to a successful outcome.
niksilver.com 