A good focus technique when we have to choose from too many options is the MoSCoW technique.
It comes from the software development Agile Method DSDM and is a straightforward way of prioritizing items.
In short, we can classify our items (let’s say the importance of each functional requirement or which quick win shall one address in the first place) following this criteria:
M – MUST have this
S – SHOULD have this if at all possible
C – COULD have this if it does not affect anything else
W – WON’T have this time but WOULD like in the future
If done with the Customer – for example during an initial brainstorming workshop – it empowers him to participate actively in the decision process regarding the most adequate order of doing things (and which ones are really important).
A bit more on this here.
ITIL Blues 
October 21, 2007 at 12:33 am |
[…] out 100 points between all items (more of a group exercise) or perhaps a method born out of the Agile Development method, DSDM (Must have this, should have this, could have this if it doesn’t affect anything else and […]
February 22, 2011 at 11:55 pm |
A useful guide for distinguishing Should have from Could have is the cost and pain caused by the workaround.
Should Haves cause a lot of pain and have costly workarounds.
Must haves form part of the Minimum Usable Subset (MUST) – without these you should abort the project
September 27, 2012 at 12:03 pm |
In our development process (http://railsware.com/approach/whole_process/approach) we’ve started to use this great practice when we realized that we are facing a strong client desire to get a lot of features build in short period of time or for small fixed budget. After that the communication became much more transparent. We were not talking about 100 items now, but 4MUSTs, 7 SHOULDs, 21 COULDs and 68 WON’Ts.
September 29, 2012 at 1:10 am |
Yes, a simple yet effective approach for dealing with “I want this” versus “I need this”. Love to see how you guys apply it in your development process.
Also, your Benefits Driven Approach aims the right target, making sure something really brings value. It is easier to aks for something than to understand what relevant outcomes it can bring. Actually using stories helps finding out the benefits.
Last but not the least regarding techniques Railsware from Ukraine are using: Colorscope (I do like the names you invent) is fun. I’ve used a similar coding system (4 colors) once in a project for a different purpose. I did it in order to classify kinds of information collected during business interviews so I could distinguish: customer depiction of what they did and their responsibilities, how they were using IT, what aspects of IT use they were not happy with and what new IT uses they would like to have. Then I grouped that information and looked for patterns across the whole interviews set (around 10 in total).
Thanks Ira! Refreshing checking out your company’s site.
November 3, 2012 at 12:13 pm |
[…] is really more of a conversation with the client / Product Owner, that allows me to make use of the MoSCoW process used in other agile methodologies like DSDM, and gives me a feature buffer that can be used […]
January 2, 2013 at 1:15 pm |
[…] https://itilblues.wordpress.com/2007/04/02/prioritization-technique-moscow-must-should-could-and-wont… […]
May 2, 2013 at 8:15 pm |
[…] in unstructured notes and still identify higher level qualitative information. More on this here from a previous […]