Feb 10 2010
The Billboard over Moscow
Effective prioritisation is key to delivering value with a software project. The MoSCoW model, splitting features into Must have, Should have, Could have and Would like (really Won’t have), theoretically does the trick. However, I found it very hard to apply in practice – too many things end up in the Must category. I recently came across an alternative model that seems to solve that problem.
The MoSCow model, at least when I tried to implement it, suffered from the Priority 1 Paradox:
The more we ask customers to narrow down priority 1 features the more they’ll be scared to leave anything out of that category.
The complaint is always the same: everything must be there – especially all the old functionality when replacing a legacy system. Prioritising so that most of the stuff ends up as ‘Must’ pretty much defeats the point of the exercise.
I am currently reading Stand Back and Deliver: Accelerating Business Agility
In a case study, the authors describe a discussion with a stakeholder who claimed that their IP protection was a differentiating factor. The authors then asked the VP of sales ‘When was the last time you sealed a deal by touting Lifebrands’ excellence in IP protection? When was the last time you felt you should include the IP protection process in sales presentations and collateral?‘ (pp 36) They also offer a simpler version of this rule of thumb as a Billboard filter:
Would you put this feature on a billboard?
If so, the feature is obviously differentiating and should be invested in. If not, this feature falls into the parity category at best. The introduction of the parity category which, as the authors repeatedly point out, holds mission-critical features which are not billboard material, seems as a great way to avoid the Priority 1 paradox. This is to intentionally avoid the feeling that anything not Priority 1 won’t be delivered. The system must have these things too offer a full service, but it just isn’t worth investing too much or being too creative there. Nickolaisen and co-authors suggest that the Parity category is where companies should apply industry best practices and streamline processing.
Overdoing it in this category might actually be damaging to the bottom line. In another case study, the authors describe a project to automate complicated pricing rules. After it was identified that complex pricing isn’t really billboard material, the project was completely turned on its head. Instead of implementing a complex rule engine, the pricing system was streamlined using industry best practices. It turned out that customers were actually happier with the new model, so simplifying a parity process increased the revenue. This was possible because the stakeholders agreed that while the company must have an automated pricing system, it wasn’t a core differentiating factor.
Strategic design ideas of Eric Evans also suggest some good guidelines what to do with such software: if the thing is available off the shelf (generic domains), buy it. If not, possibly get a third party to develop and maintain it. Evans calls these domains supporting, and they are prime candidates for outsourcing.
This article is part of my Building software that matters series. See other articles here
Btw, I’ve created a mailing list for this topic so rather than commenting here, post your comments to the Building Software That Matters mailing list and let’s discuss them!
Image credits:Steve Rhodes
 |
 |
Funny you should bring this up – I’ve been working on a whitepaper around this very topic – http://www.coryfoy.com/whitepapers/DeliveringWhatsRight.pdf. Would love your feedback on it!
This matrix is interesting.
I think what’s also often missed is that prioritisation is time-based. When we ask ‘what are the must-haves?’, it must be qualified with a timeline. I.e., it must be clear that we’re not saying ‘if its not in the must-have category you won’t get it’, but rather saying ‘you won’t get it in this time frame’.
There is also a sequence/order aspect: its not that you won’t get ‘should haves’ at all, its just that you’ll get the ‘must haves’ first. And within those categories, there’ll be some internal order.
There’s also an example in Goldratt’s The Goal where a staggered delivery of a large amount of product is more optimal than a ‘big bang’ delivery of the same amount; more optimal for both the customer and the supplier. I.e. ‘we can’t give you all of this on this particular date, but we can give you some of it earlier and some of it later. Which would you prefer earlier and which later?’
I also think that this matrix essentially forces the customer to re-evaluate how they consider or assess value: ‘if we wouldn’t put it on a billboard, will it really add value (to our customers)?’
Seems like there are quite some parallels to the Kano Model:
http://en.wikipedia.org/wiki/Kano_model
The “Differentiating” quadrant corresponds to the “Excitement” features while the “Parity” quadrant corresponds to the “Performance” features (maybe even the “Basic” features.
Interesting is the fact it is quite common that over time (even during the project) features that were initially in the “Differentiating” quadrant are drifting into the “Parity” quadrant…