How should I write a moscow analysis?

Question

I have to conduct a MoSCoW analysis as part of a justification to buy some equipment. What should I look for and how should I best present my findings?

Answer 1

Normally the MoSCoW analysis would be used in this context to rate different alternative solutions (or different suppliers/models of equipment).

Start off with a description of what the equipment is for, for example what tasks will it be expected to perform. Then write your list of Musts: features without which it would be impossible to perform the required tasks. Then write your list of Shoulds: features which ideally the equipment would have, but which you could live without, possibly by doing something manually rather than automatically, or by keeping some old equipment as well as the new equipment rather than replacing the whole lot.

Next comes the Coulds - features which you think would be useful, either immediately or in the future, but which are not essential to the primary tasks (ie you could get away with not doing them at all).

In this context there's not much value in the Won'ts, so I'd skip this if I was you.

Then draw a grid with the different equipment solutions (one of which might be to not buy any new equipment, by the way), and fill in how each option matches the Must/Should/Coulds. Hopefully at least one option will match all the Musts. Hope this helps.

Answer 2

Break it into sections

Must Have
Should Have
Could Have
Won't have

Jeff

Also see

MoSCoW Method
From Wikipedia, the free encyclopedia
(Redirected from MOSCOW Analysis)
Jump to: navigation, search
For other uses, see Moscow (disambiguation).
MoSCoW is a method used in business and particularly in software development to get an understanding with the customer on the importance they place on the delivery of each functional requirement. It originated as part of the Dynamic Systems Development Method. Sometimes called a MoSCoW list or a MOSCOW Analysis. MoSCoW stands for:

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.

The o's in MoSCoW are added to make the word pronounceable, and are often left lower case to indicate that they don't stand for anything.

Contents [hide]
1 Explanation
1.1 Must Have
1.2 Should Have
1.3 Could Have
1.4 Won't Have (this time around)
2 Criticism
3 Sources



[edit]
Explanation
The plain English meaning of the MoSCoW words has value in getting customers to understand what they are doing during prioritisation in a way that other ways of attaching priority, like high, medium and low, do not.

[edit]
Must Have
Anything labeled as "MUST" has to be included in the project delivery timebox in order for it to be a success. If even one "MUST" item is not included, the project delivery is considered a failure. "MUST" is also an acronym for the Minimum Usable SubseT.

[edit]
Should Have
While not critical to the success of the project delivery, "SHOULD" items are nearly as important and should be included if it is at all possible. "SHOULD" items are often as important as MUST items, however "SHOULD" items have workarounds allowing another way of satisfying the requirement.

[edit]
Could Have
"COULD" items are less critical and often seen as "nice to have". A few easily built Coulds in a delivery can increase customer satisfaction for little development cost.

[edit]
Won't Have (this time around)
"WON'T" items are either the least-critical or lowest-payback items. As a result, "WON'T" items are not planned into the schedule for the current project iteration. "WON'T" items are either dropped or reconsidered for reprioritization in later project increments. This, however doesn't make them any less important. Sometimes this is described simply as "Would like to have" in the future. This however leaves some ambiguity in the minds of the users as to its priority compared to the other marks.

All requirements are important, but they are prioritized to deliver the greatest and most immediate business benefits early. Developers will initially try to deliver in all the M, S and C categories but the S and Cs will be the first to go if the delivery timescale looks threatened.

[edit]
Criticism
Some feel that classifying a requirement as "nice to have" makes it no longer a requirement, but more of a nicety. Therefore it no longer fits the definition of a "requirement" and thus has no place in a "Requirements" Document.

Response #1 Since the priority of requirements is fuzzy (and even varies over time) it is quite appropriate to consider "nice to have" items to still be "requirements". A "nice to have" item is generally one that has some return/payback but isn't part of the "minimum useable subset" required to deliver the product.

Response #2 Stakeholders in a new computer system will often come up with a wish list of every thing they can think might possibly be of use. To implement the whole wishlist would be wasteful in time and money. MoSCoW is a way to work with that list so that a compromise is reached between what is most useful and can be built in a short timescale of 3 to 6 months and what can be put off to a future development cycle.

Response #3 Iterative development can also lead to re-prioritisation which can sometimes convert nice-to-have-s into could-haves.

[edit]
Sources
MoSCoW @ DSDM
Coley Consulting on MoSCoW

Answer 3

If you are still striving to improve you are straight and you are looking to get the hands above the edge, put Vert Shock to the check, a program you will believe it is here https://tr.im/khFQ4  and give it a take to, you will end up amazed of how quickly you can be a monster hopper if you train the proper way.
This system won't cause you to leap tens and thousands of times because Vert Shock was produced and used by real elite stage basketball players.
In regards down seriously to it, if you actually want to jump higher, you only found the very best program in the world to complete so. Any way would simply be a waste of time.