To be successful projects need to be properly prioritized for both the requirements and the main project objectives. One mechanism is to use a number system, but this is flawed as it results in all elements being number one. A more useful method is to use a set of words that have meaning such as the MoSCoW method. However to be effective prioritization requires hard choices to be made.
Prioritisation of Requirements
An important factor for the success of any project is ensuring that the requirements, are prioritised. In many cases this is not done leading to sure project failure. Sometimes it is the customers’ fault who want the entire system to be delivered now. Other times it is the project manager’s fault because they do not discuss the project with the customer. In either case prayers for miracles are often required if the project is to have any chance of being successful. In my experience miracles rarely happen on projects.
However prioritising is not an easy process, and even less so when done using a number system. The trouble with number systems is that it appears logically to give the features a priority of 1, 2, 3 etc. However who wants a requirement to be a “2” or even a “3”? As a result all requirements become a “1”, which is useless. This can lead to having to resort to additional systems such as giving “1*” and “1**” ratings to try to sort out what is really important. Even this is subject to prioritisation drift – upwards.
Even more damaging with number systems is that features that will not be developed this time are left off the list, and are ultimately lost. This means that designers and developers are unaware of these future needs, and therefore cannot select solutions which will make it easier to accommodate them at a later date.
So effective prioritisation is important but how can it be done if number systems are not effective?
A more successful method is to prioritise requirements by using words that have meaning. Several schemes exist but a method popularised by the DSDM community is the acronym MoSCoW. This stands for:
M – MUST have this.
S – SHOULD have this if at all possible.
C – COULD have this if it does not effect anything else.
W – WON’T have this time but would like in the future.
The two lower case “o” are there just to make the acronym work. The importance of this method is that when prioritising the words mean something and can be used to discuss what is important.
The “Must” requirements are non-negotiable, if they are not delivered then the project is a failure, therefore it is in everybody’s interest to agree what can be delivered and will be useful. Nice to have features are classified in the other categories of “Should” and “Could.
“Must” requirements must form a coherent set. They cannot just be “cherry picked” from all the others. If they are then what happens is that by default all the other requirements automatically become “Must”, and the entire exercise is wasted.
Requirements marked as “Won’t” are potentially as important as the “Must” category. It is not immediately obvious why this is so, but it is one of the characteristics that makes MoSCoW such a powerful technique. Classifying something as “Won’t” acknowledges that it is important, but can be left for a future release. In fact a great deal of time might be spent in trying to produce a good “Won’t” list. This has three important effects:
- Users do not have to fight to get something onto a requirements list.
- In thinking about what will be required later, affects what is asked for now.
- The designers seeing the future trend can produce solutions that can accommodate these requirements in a future release.
Prioritising the Project Objectives
When a set of requirements has been prioritised then it can be compared against the other planning aspects of project: scope, quality, timescale and resources, and a risk statement produced.
There is a general wish among managers to be able to decide when a project will be delivered, how much it will cost and what it will do. They then think they have removed all the degrees of freedom, and as they have made an assertion, reality will follow their thinking.
Reality will not, as they have left out two significant factors. The first is quality; it may be delivered on time but the quality is appalling. It does what the requirements say, but the system is not robust enough to be used by anybody, as one mistake will make it crash. The other factor is risk, which may be so sky high, that project failure has guaranteed before it starts.
One suggestion is to prioritise the four main factors of scope, quality, timescale and resources, and thus prioritise the key project objectives. Which of them “Must” be delivered, which has the maximum flexibility and is defined as “Could”, with the other two factors between these as “Should”. This means that at least one factor can be allowed to slip, and provide flexibility for setting a proper risk plan to ensure the essential factor is met. This is not losing control, it is acknowledging that building a piece of software is a trip into the unknown, and precautions need to be taken.
Implications of Prioritising the Project
Selecting the right prioritisation order of is not easy. Any choice that is made has tradeoffs.
If nearly all the requirements are prioritised as “Must”, then there is not much flexibility in the scope of a project. By definition the scope is the “Must” factor in the project and a decision has to be taken either about which of the others will have flexibility, or which of the requirements will be down graded from a “Must”.
However many studies have shown that it is better if a project is delivered on time, even if it has few features, than if a project is delivered late, but with a full set of features. This can be likened to saying when is the best time to deliver Christmas crackers to shops, before or after Christmas? Therefore timescale competes to be the most important factor.
If quality is sacrificed then faults will occur in the software. One way around this is to train the users in the use of a new system, so that they only use it in proper fashion, and know how to get around any bugs that are discovered. However if it is an Internet system intended to be used by customers, then this cannot be done, and a reputation damage to the organisation may result, due to a faulty system.
Finally all systems must be produced to a budget, and a business does not have unlimited resources to put into a project. Moreover the business case normally assumes a rate of return, which will be considerably reduced if the resources are increased significantly on a project. Therefore resources have a strong case for being the most important factor.
Regardless you cannot “have it all and have it now”, and a balanced and planned prioritisation of the factors must take place if a project is to have a chance of delivering business value. If it is not then the fifth factor of risk goes sky high, and ceases to be risk and become inevitable.