Management Models

They say time is infinite. Theoretical Physicists may agree, but anyone involved with Projects knows only too well that time is finite. No matter what you are delivering in your portfolio or project, there never seems to be quite enough time to get everything the customer wants delivered. More often than not, we end up negotiating on scope - agreeing which scope items are mandatory, and which can be skipped without affecting the business case.

This is a problem that Agile project managers are very familiar with. When delivering within fixed iterations to high standards of quality, the only thing you can flex is the scope. One of the most popular methods of prioritizing scope (or stories) is a technique called MoSCoW that was developed by a man called Dai Clegg and later adopted by DSDM.

MoSCoW prioritization

The MoSCoW method assets that all requirements are important, but they should be ordered to deliver the greatest and most immediate business benefits early. Requirements are sorted into one of four categories: Must have, Should have, Could have and Won't have. Teams will set out to deliver the Must, Should and Could requirements, but the Could and Should requirements are first to be descoped if the timeline is at risk.

The Categories are defined as follows:

Must Have Requirements labeled as Must have are critical to the current delivery timebox in order for it to be a success. If even one Must have requirement is not included, the project delivery should be considered a failure (note: requirements can be downgraded from Must.

Should Have Requirements labeled as Should have are important but not necessary for delivery in the current delivery timebox. While Should have requirements can be as important as Must haves, they are often not as time-critical or there may be another way to satisfy the requirement, so that it can be held back until a future delivery timebox, or a later project.

Could have Requirements labeled as Could have are desirable but not necessary, and could improve user experience or customer satisfaction for little development cost. These will typically be included if time or budget permits.

Won't have Requirements labeled as Won't have are agreed by stakeholders as the least-critical items. This is not to say that they are not valuable - just that they are not needed at this time and can either be dropped, or pushed to a later delivery window.

The problem with MoSCoW

The problem with this prioritization approach lies not with the method itself, but with its application. Imagine a scenario where your team have a backlog of requirements that the sales and marketing team would like a product team to invest in. These types of request are typically backed by a sense of urgency and promises of high value sales/conversions. Based on our MoSCoW ranking system we would categorise these based on their ability to deliver great and immediate business benefits and would therefore categorize them as 'Must Have'. Other items are descoped, or recategorized to compensate. The danger with this approach is that it is typically the exciting and new requirements that end up making the cut, whilst anything that can be put off, ends up being deferred indefinitely. A common pattern is for work such as refactoring, maintenance and efficiency improvements being put off, in favor of new features.

How can Kano help?

In the 1980s, Noriaki Kano developed the Kano Model of Customer Satisfaction. Using the model we can divide requirements into three categories: Baseline Expectations, Linear Satisfiers, and Delighters

Baseline Expectation Requirements are those that must be present for the product to be successful.

Linear Satisfiers Requirements are those that are on a sliding scale. The more we have, or the better they are - the more customer satisfaction they bring. Conversely, the worse they are, the more dissatisfaction they bring. A good example here may be the speed of a web site, or the number of free Excel templates available for download on a website for PMO professionals!

Delighters are requirements that will delight your customer and 'wow' them. These are the items that will typically not be missed if they are absent, but they will impress your stakeholders, and will make your product stand out.

Where Kano starts to get interesting, is when we plot the relationships among these different categories as shown below.

The red arrow at the bottom of our graph shows our Baseline Expectations. Without these items, there is either no customer satisfaction, because the product does not exist, or we get customer satisfaction up to somewhere close to (but not quite at) neutral. Our Linear Satisfiers are items that can cause dissatifaction if they do not exist, or are partially implemented, but can make our customers REALLY HAPPY if we fully implement them. Finally our Delighters are things that make our customers happy, but will never result in them being unhappy. This is because Delighters are usually things that our customers did not expect - in a sense you could describe them as 'value-add'.

Combining MoSCoW and Kano

Combining the simplicity or MoSCoW with the customer-centric view that Kano provides, gives us a powerful lexicon with which to explore the mix of requirements we are delivering. In the example I gave further up this post, we saw that many items that are categorised as 'Must Have' in MoSCoW could be classified as 'Delighters' in Kano. Kano takes the opposite view and says that we should be getting the baseline expectations delivered first, but acknowledges these are unlikely to make our customers happy - merely make them less unhappy.

Mapping requirements to Kano gives us greater insight into our requirements and supports more informed decision making about requirement priority. For teams who are delivering in iterations, it will be important to get a good mix or requirements that ensure baseline expectations are met, whilst continuing to improve our Linear Satisfiers and add a splattering of Delighters to keep our stakeholder excited. The mix is likely to vary throughout the lifecycle of the project, with the focus being on Baseline Expectations and Linear Satisfiers at the start of the project, with more Delighters being added to the mix later in the lifecycle.