As agile as we all want to be, projects invariably face time and budget constraints that must be worked around. Outside of the world of idealism and theory, the way that we prioritize solutions is essential to building deliverables that satisfy the requirements and the expectations of stakeholders. Since the Moscow method was integrated into the DSDM Consortium, savvy companies have been using it to reorganize thinking within a time boxed process.
However, Moscow can be used in other contexts as well. Time is not the only constraining value in terms of project success. Depending on the company, there may be more prevalent limiting factors such as funding or even pleasing the idiosyncrasies of an individual investor or distributor to secure future support.
Dealing with overlapping constraints is the primary reason for a more robust prioritization schedule. Segmenting and quantifying different levels of priority instead of trying to eyeball a feature set leads to a much more predictable result, one that can be included in projection reports to stabilize the expectations of customers and investors.
Moscow stands for "Must, Should, Could and Won't." The "o's" are just to make the acronym pretty and give the technique a recognizable name. Here is the basic concept of the Moscow Method:
Must or Must Have
These are top priority items that the project needs in order to move forward. If there is a way to continue forward on the project without an item on this list, then that item does not belong on this list. DsDNA defines a "Must Have" item as 1. an item that completely stops delivery of a project, 2. a deliverable that makes deployment pointless, 3. a deliverable that is required to keep a project within legal compliance of some sort, or 4. a deliverable that, if left out, makes the product unsafe.
Should or Should Have
Should or Should Have items are very important items that are nonetheless not critical. These items, when left out, cause visible discomfort in one or more departments. The company may have to reconstruct expectations concerning the product, and the description of deliverables may even need to be changed in press releases or other paperwork. In short, these are not items that you want to leave out if at all possible.
Could or Could Have
Could or Could Have items are desirable points that are less important than either of the two previous categories. These may be things that set a product apart from its competition, but exclusion would not in any way reduce the viability of the product or burden users. The items that belong in this category may be contentious, but merely the fact that there are varying opinions on them means that they belong here rather than in the Should or Must categories.
Won't or Won't Have
These items are not negative or bad; rather, they are desirable items that are identified as impossible to include within the constraints of the project. Perhaps the project will miss its delivery date if a Won't item is included, or the budget may not fit it. Won't items can possibly be moved into another category in a future iteration of a project. As a matter of fact, the Could and Should item lists of future software builds usually begins from the Won't list of the previous iteration.
How effective is the Moscow Method?
The Moscow method is quite effective because it requires companywide, interdepartmental agreement on project priorities. Because the Must category and the Won't category are nonnegotiable, the project immediately has a more defined direction. The Could and Should categories, including items that are usually major points of contention, are worked out very early in the process and properly assigned resources and manpower according to their priority level.
The major advantage of using the Moscow Method to prioritize is the ability to assign a certain percentage of resources to each category. Eliminating items in the Won't category (and assigning them 0%, obviously) allows the company more resources to plan for the Could and Should categories. You can then split your resources by percentages. Not only does this ensure proper management of these resources, but it also allows for precise productivity analytics. You can reward departments that outperform and shore up efforts that underperform. Total effort can be divided up between the Must, Could and Should categories. Resources can be transferred once the Must items have been completed.
Although most business analysts agree that the Moscow Method is only meaningful within a time constraint, the fact that most projects incur this constraint means that it can usually be applied. When priorities are set before resources are committed to any particular process, they are more easily reviewed throughout the duration of the project. You can report successes and deal with failures more easily under the auspices of a quantified priority structure. If you have been winging it in terms of your latest product feature sets, then the Moscow Method may provide your company with the structure it needs to more effectively meet your deadlines and improve product quality.
