5 August 2007

Kano model and classifying requirements

If you aren’t already using it, Kano’s quality framework is a far superior model to flagging requirements into three tiers of ‘must haves,’ ‘serious wants’ and ‘nice to haves.’

After all, good Requirements Specifications only have ‘must haves’ in them, right? If a requirement doesn’t add value it should have already been dropped.

Mandatory
These requirements will cause your stakeholders to reject the solution is they aren’t addressed. These requirements will be core to achieving the business case objectives, and meeting minimum quality standards such as security and customer privacy requirements. Most non-functional specifications will be mandatory.

One dimensional
These requirements are linear in the cost/benefit trade off. For every dollar spent on one of the requirements you’ll get two back (or whatever the appropriate ROI target is.) There may be opportunity costs as well as financial costs associated with the cost benefit analysis.

These are the requirements you will partly meet, and the degree to which you meet them will be based upon resource availability an time. These requirements are potentially easier to measure and may gain more time that they should in relation to the delighters.

Delighters
Delighters are the special features that make the customer happy with the product. A classic example is good design. You can get an excellent payback from good design but it‘s sometimes hard to quantify. Depending on the market though, delighters can be the key to success.

When dealing in intangible services project teams are often at a loss to delight their customers, especially software project teams.

Many programmers and IT workers have an engineering mindset that says work to the written specification, but that won’t make you customer happy. At best it will leave them satisfied, and usually it leaves them disappointed. Project teams should always plan to deliver a handful of delightful features into their products for the sake of client satisfaction. The job isn’t done, just because the specifications have been delivered.

The best way to do this is to have your requirements manager highlight which of the requirements fall into the delighter quadrant on Kano’s model and make sure that at last some of them get delivered.

==Added 31/8/07==

Here is an online video tutorial on the Kano model for those that like an interactive education.

5 comments:

  1. How does one know at requirements stage whether a linear requirement fulfills the ROI target? In a good organization, you should be able to gauge the return value of the requirement, but to determine the investment generally requires analysis as well; if you aren't careful, you can spend a lot of resources determining the cost of things that will never be built. And those resources are the very same ones who could be producing value rather than analyzing potential ROI.

    ps: you always do a good job on your photos, you'll have to share your supply secret.

    Leader 4 success

    ReplyDelete
  2. Thanks for the comments. YOur points are good. Thnigs ned to be broken into the right sized parts depending on cost and benefits or yes - time is being wasted.

    As for the photos; a miz of getty images and my own. And sometimes a google search for the professors and experts.

    ReplyDelete
  3. Thanks Craig,

    this was a very insightful post.

    ReplyDelete
  4. Initially, I did not know about Kano Model. However, after reading about it and viewing the post and reading about kano model, I feel more equipped. Thanks for this article. Thanks.

    ReplyDelete
  5. Saji, Linda

    Glad to have helped out. Let me know how it goes if you get the chance to use it in the field

    ReplyDelete

Search This Blog