Taking a project to MOSCOW
Moscow, as everyone knows is a city in Russia. Hot in summer, very cold in Winter. What you might not know is MOSCOW is a good way if breaking down project requests into the absolutely necessary and the nice to have. In this regard, dropping the letter "O" from Moscow gives us MSCW -
M = Must Have
S = Should Have
C = Could Have
W = Wish List
This is a convenient way of managing unwieldy project specifications by prioritising requirements, particularly those where there are either: a) many objectives, b) many stakeholders, or c), development or delivery complexities.
M = Must Have
These are the only requirements that the project must deliver. A requirement can only have this priority for one of the following reasons:
a) They are mandated by law or an (internal or external) regulatory body.
b) They are high value business requirements delivering the benefits on which the Business Case for the project is founded
c) They are requirements which must be met to enable requirements of the above types to be met.
S = Should Have
These are medium value requirements, directly delivering business benefits, but the Business Case for the project is still valid even if these requirements are not met.
C = Could Have
Requirements which would be useful but do not directly deliver any of the business benefit on which the Business Case is based.
W = Would Like to Have
These are either:
a) Stand-alone requirements that could be postponed to a later project (or project phase) without impacting on the benefits or usefulness of the core functionality being delivered.
b) Minor requirements reflecting personal preferences, e.g. cosmetic
For example, regulatory and compliance issues would be tagged "M", whereas minor cosmetic details not affecting operations would be tagged "W". This allows a business case to be more focused and ensure that scare IT development resources are applied more intelligently, in pursuit of the most ecomonically beneficial tasks.
Managing Brief Creep
In Customer Management, like many other fields, there is always something more that can be done. There are always new initiatives that can be rolled out to customers, there is always more analysis that can be done to improve targetting and there is always more information that can be provided to advisors (or customers through self-service channels) througk Knowledge Management, training and systems. Consequently, managers in customer management are never short of development briefs. When you add to the complexities of managing cross-channel interactions with, say, a technology refresh or a merger incorporating two diverse platforms, there is rarely a time when managers in this are conclude that they have all of the systems and support that they need. So, specifications and briefs abound. Managing these briefs and delivering greatest economic value back to the business is a testing role.
The factors above and the constantly changing world of marketing communications means that briefs evolve as knowledge and understanding evolves and as the business responds to the dynamics of the marketplace (new products, regulation, competition, etc). This results often in brief creep. Using a MOSCOW prioritisation scheme is helpful in managing down the extent of the creeping and focusing attention back onto that which is really delivering economic value.
Copyright 2006 Robert A Innes

