Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Kano Analysis and Software Requrements

10,972 views

Published on

Using Kano Analysis to prioritise Business Requirements

Noriaki Kano, recipient of the Deming Prize, developed a model to work out what stakeholder requirements are mandatory, which ones are value for money proposition (i.e. more is better,) and which requirements will delight them. This talk introduces the Kano model in the business/software requirements context, and presents a step by step application of the model so that you can delight your stakeholders.

Published in: Business, Technology

Kano Analysis and Software Requrements

  1. 1. Kano Analysis A talk on requirements prioritisation To ACS requirements SIG 25 th June 2009 By Craig Brown
  2. 2. Whois: Craig Brown <ul><li>Craig Brown is a project consultant, project manager and business analyst. </li></ul><ul><li>I have worked with several leading corporate brands in Australia as well as started two small businesses. </li></ul><ul><li>I am currently lecturing in project management at Melbourne Institute of Technology's Sydney campus and contracting about town. </li></ul><ul><li>Blog: www.betterprojects.net </li></ul>Sponsor: Ingena Group Limited Web: www.ingena.com.au
  3. 3. <ul><li>Using Kano Analysis to prioritise Business Requirements </li></ul><ul><li>Noriaki Kano, recipient of the Deming Prize, developed a model to work out what stakeholder requirements are mandatory, which ones are value for money proposition (i.e. more is better,) and which requirements will delight them. This talk introduces the Kano model in the business/software requirements context, and presents a step by step application of the model so that you can delight your stakeholders. </li></ul>Noriaki Kano
  4. 4. <ul><li>What is the role of the business analyst? </li></ul>The business analyst as product manager
  5. 5. <ul><li>The premise of this discussion, and most of what I say on the topic, is that the BA is responsible for… </li></ul>
  6. 6. <ul><li>The delivery of a valuable product to the client </li></ul>
  7. 7. SOME PROBLEMS WITH REQUIREMENTS ELICITATION
  8. 8. <ul><li>Over-engineered solutions </li></ul><ul><ul><li>Building in superfluous quality </li></ul></ul><ul><li>The mixed bag </li></ul><ul><ul><li>Scoring goals in one area but still failing to hit the right points </li></ul></ul><ul><li>“ That’s not what I meant” </li></ul><ul><ul><li>L istening to what stakeholders and customers say, rather than understanding what they really want </li></ul></ul><ul><li>Never ending requirements </li></ul><ul><ul><li>Dealing with budget and schedule constraints </li></ul></ul>
  9. 9. REQUIREMENTS MANAGEMENT IN AN ITERATIVE AGE
  10. 10. <ul><li>Multiple releases </li></ul><ul><li>Product roadmaps </li></ul><ul><li>Solution Layers </li></ul><ul><li>What comes first? </li></ul>
  11. 11. ALTERNATIVE MODELS
  12. 12. <ul><li>MOSCOW </li></ul><ul><li>Mandatory – Optional </li></ul><ul><li>Balancing the scorecard </li></ul><ul><li>Other? </li></ul>
  13. 13. PLUGGING KANO INTO BABOK 2
  14. 14. <ul><li>Chapter 3; Requirements elicitation </li></ul><ul><li>3.2 Conduct elicitation activity </li></ul><ul><ul><li>The elicitation event takes place (brainstorming, focus groups, interviews, observation, prototyping, requirements workshops), or elicitation is performed (document analysis, interface analysis) or distributed (survey/questionnaire). </li></ul></ul><ul><li>Chapter 4; Requirements Management and Communications </li></ul><ul><li>4.1 Solution scope </li></ul><ul><ul><li>Obtain and maintain consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented. </li></ul></ul><ul><li>Chapter 5; Enterprise Analysis, </li></ul><ul><li>5.4 Solution scope </li></ul><ul><ul><li>The capabilities supported by solution components, such as business processes, organizational units, and software applications. </li></ul></ul><ul><li>Chapter 6; Requirements analysis </li></ul><ul><li>6.1 prioritise requirements </li></ul><ul><ul><li>Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. </li></ul></ul><ul><li>6.2 organise requirements </li></ul><ul><ul><li>The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. </li></ul></ul><ul><li>6.6 validate requirements </li></ul><ul><ul><li>The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfil its goals and objectives, and meet a stakeholder need. </li></ul></ul><ul><li>Chapter 7; Solution Assessment and Validation </li></ul><ul><li>7.2 Allocate Requirements </li></ul><ul><ul><li>Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team. </li></ul></ul>
  15. 15. <ul><li>Chapter 3; Requirements elicitation </li></ul><ul><li>3.2 Conduct elicitation activity </li></ul><ul><ul><li>The elicitation event takes place (brainstorming, focus groups, interviews, observation, prototyping, requirements workshops), or elicitation is performed (document analysis, interface analysis) or distributed (survey/questionnaire). </li></ul></ul><ul><li>Chapter 4; Requirements Management and Communications </li></ul><ul><li>4.1 Solution scope </li></ul><ul><ul><li>Obtain and maintain consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented. </li></ul></ul><ul><li>Chapter 5; Enterprise Analysis, </li></ul><ul><li>5.4 Solution scope </li></ul><ul><ul><li>The capabilities supported by solution components , such as business processes, organizational units, and software applications. </li></ul></ul><ul><li>Chapter 6; Requirements analysis </li></ul><ul><li>6.1 prioritise requirements </li></ul><ul><ul><li>Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. </li></ul></ul><ul><li>6.2 organise requirements </li></ul><ul><ul><li>The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. </li></ul></ul><ul><li>6.6 validate requirements </li></ul><ul><ul><li>The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfil its goals and objectives, and meet a stakeholder need. </li></ul></ul><ul><li>Chapter 7; Solution Assessment and Validation </li></ul><ul><li>7.2 Allocate Requirements </li></ul><ul><ul><li>Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team. </li></ul></ul>
  16. 16. <ul><li>Chapter 3; Requirements elicitation </li></ul><ul><li>3.2 Conduct elicitation activity </li></ul><ul><ul><li>The elicitation event takes place (brainstorming, focus groups, interviews, observation, prototyping, requirements workshops), or elicitation is performed (document analysis, interface analysis) or distributed (survey/questionnaire). </li></ul></ul><ul><li>Chapter 4; Requirements Management and Communications </li></ul><ul><li>4.1 Solution scope </li></ul><ul><ul><li>Obtain and maintain consensus among key stakeholders regarding the overall solution scope and the requirements that will be implemented. </li></ul></ul><ul><li>Chapter 5; Enterprise Analysis, </li></ul><ul><li>5.4 Solution scope </li></ul><ul><ul><li>The capabilities supported by solution components , such as business processes, organizational units, and software applications. </li></ul></ul><ul><li>Chapter 6; Requirements analysis </li></ul><ul><li>6.1 prioritise requirements </li></ul><ul><ul><li>Prioritization of requirements ensures that analysis and implementation efforts focus on the most critical requirements. </li></ul></ul><ul><li>6.2 organise requirements </li></ul><ul><ul><li>The purpose of organizing requirements is to create a set of views of the requirements for the new business solution that are comprehensive, complete, consistent, and understood from all stakeholder perspectives. </li></ul></ul><ul><li>6.6 validate requirements </li></ul><ul><ul><li>The purpose of requirements validation is to ensure that all requirements support the delivery of value to the business, fulfil its goals and objectives, and meet a stakeholder need. </li></ul></ul><ul><li>Chapter 7; Solution Assessment and Validation </li></ul><ul><li>7.2 Allocate Requirements </li></ul><ul><ul><li>Allocate stakeholder and solution requirements among solution components and releases in order to maximize the possible business value given the options and alternatives generated by the design team. </li></ul></ul>
  17. 17. <ul><li>Kano analysis tells you </li></ul><ul><li>What is mandatory </li></ul><ul><li>What is delightful </li></ul><ul><li>What is a value for money proposition, and </li></ul><ul><li>What doesn’t matter </li></ul>
  18. 18. <ul><li>Herzberg’s Motivation-Hygiene Theory </li></ul><ul><li>In the late 1960s Frederick Herzberg wrote about worker motivation. </li></ul><ul><li>He distinguished between motivation factors and hygiene factors. </li></ul>motivation factors Help motivate workers directly eg. achievement, recognition, work, responsibility hygiene factors cause dissatisfaction if absent but do not motivate, eg. Money, working conditions,
  19. 19. Achievement Recognition Work itself Responsibility Advancement Growth Company policy and administration Supervision Relationship with supervisor Work Conditions Salary Relationship with peers Personal life Relationship with subordinates Status Security Factors characterising 1,844 events on the job that led to extreme dissatisfaction Factors characterising 1,753 events on the job that led to extreme satisfaction 50% 40% 30% 20% 10% 10% 20% 30% 40% 50%
  20. 20. http://www.provenmodels.com/21/motivation-hygiene-theory/herzberg-mausner-snyderman
  21. 21. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters Indifferent
  22. 22. Kano Requirement types <ul><li>Delighters </li></ul><ul><li>Things customers are excited about </li></ul><ul><li>Basic features </li></ul><ul><li>Things customers need </li></ul><ul><li>“ Must Be” </li></ul>Performance Indifferent <ul><li>More is better </li></ul><ul><li>Not needed </li></ul>
  23. 23. Secondary Key Plus Basic Llosa (1997 [8] , 1999 [9] ) Low impact One-dimensional Attractive Basic Brandt and Scharioth (1998) [7] Low Key Value-added Flat Venkitaraman and Jaworski (1993) [6] Unimportant as determinant Hybrid Value enhancing Minimum requirement Brandt (1988) [5] Neutral Critical Satisfier Dissatisfier Cadotte and Turgeon (1988) [4] Indifferent One-dimensional Attractive Must-be Kano (1984) [3] Motivator Hygiene Herzberg et al. (1959) [2] Driver type 4 Driver type 3 Driver type 2 Driver type 1 Author(s)
  24. 24. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters Indifferent
  25. 25. Satisfied Dissatisfied
  26. 26. Satisfied Dissatisfied Fully implemented Not implemented
  27. 27. Delighted Disgusted Fully implemented Not implemented What customers articulate when talking about requirements
  28. 28. Delighted Disgusted Fully implemented Not implemented What you put in the product
  29. 29. Delighted Dissatisfied Fully implemented Not implemented Fully implemented Satisfied Performance needs
  30. 30. Satisfied Disgusted Fully implemented Not implemented Not implemented Dissatisfied Performance needs
  31. 31. Satisfied Dissatisfied Fully implemented Not implemented 1 hour battery Performance needs
  32. 32. Satisfied Dissatisfied Fully implemented Not implemented 1 hour battery 24 hour battery Performance needs
  33. 33. Satisfied Dissatisfied Fully implemented Not implemented Performance needs 1 hour battery 24 hour battery 72 hour battery
  34. 34. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs
  35. 35. Satisfied Dissatisfied Fully implemented Not implemented Performance needs These features don’t Satisfy customers Basic needs
  36. 36. Satisfied Dissatisfied Fully implemented Not implemented Performance needs These features don’t Satisfy customers But if they are not present the customer will be dissatisfied Basic needs
  37. 37. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs No internet service
  38. 38. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs No internet service Limited speed internet
  39. 39. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs No internet service Limited speed internet Full broad- band
  40. 40. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters
  41. 41. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Not having these features doesn’t disappoint customers Delighters
  42. 42. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Not having these features doesn’t disappoint customers But any reasonable implementation delights them Delighters
  43. 43. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters Touch screen Drag and snap
  44. 44. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters
  45. 45. <ul><li>Surprise and delight. Capabilities that differentiate a product from its competition (e.g. the iPhone touch screen). </li></ul><ul><li>More is better. Dimensions along a continuum with a clear direction of increasing utility (e.g. battery life, number of aps). </li></ul><ul><li>Must be. Functional barriers to entry—without these capabilities, customers will not use the product (e.g. ability to sms, access internet). </li></ul><ul><li>Better not be. Represents things that dissatisfy customers (e.g. no camera). </li></ul>- Concept from Scott Sehlhorst
  46. 46. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters Over time delightful innovation becomes another basic need
  47. 47. 2001 2009 Satisfied Dissatisfied Fully implemented Not implemented Basic needs Broad band internet Broad band internet
  48. 48. <ul><li>Rate your satisfaction if the product does have this attribute? </li></ul><ul><li>A) Satisfied </li></ul><ul><li>B) It must be that way </li></ul><ul><li>C) Neutral </li></ul><ul><li>D) Can live with it </li></ul><ul><li>E) Dissatisfied </li></ul><ul><li>Rate your satisfaction if the product did not have this attribute? </li></ul><ul><li>A) Satisfied </li></ul><ul><li>B) It must be that way </li></ul><ul><li>C) Neutral </li></ul><ul><li>D) Can live with it </li></ul><ul><li>E) Dissatisfied </li></ul>
  49. 49. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  50. 50. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  51. 51. Delighted and Excited!
  52. 52. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  53. 53. Indifferent
  54. 54. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  55. 55. Questionable (logically inconsistent)
  56. 56. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  57. 57. Mandatory/Basic
  58. 58. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  59. 59. <ul><li>? </li></ul>
  60. 60. If I had this… Dissatisfied If I didn’t have this… Satisfied Dissatisfied Neutral Don’t care Satisfied Dissatisfied Neutral Don’t care ? R R R             Dissatisfied R R R R $ ! ! ! ?
  61. 61. Example requirements
  62. 62. A) Satisfied - B) It must be that way - C) Neutral - D) Can live with it - E) Dissatisfied <ul><li>Rate your satisfaction if the product has this attribute? </li></ul><ul><li>Rate your satisfaction if the product did not have this attribute? </li></ul>A A A A A A A A A A A A A A B B B B B B B C C C C C C C D D D D D D D E E E E E E E B B B B B B B C C C C C C C D D D D D D D E E E E E E E Single sign on Ability to model sales & get quotes prior to committing View current order status online Get email as status changes Ability to view jobs in progress Ability to view historical jobs Ability for manager to take and re-allocate jobs
  63. 63. A) Satisfied - B) It must be that way - C) Neutral - D) Can live with it - E) Dissatisfied <ul><li>Rate your satisfaction if the product has this attribute? </li></ul><ul><li>Rate your satisfaction if the product did not have this attribute? </li></ul>A A A A A A A A A A A A A A B B B B B B B C C C C C C C D D D D D D D E E E E E E E B B B B B B B C C C C C C C D D D D D D D E E E E E E E Single sign on Ability to model sales & get quotes prior to committing View current order status online Get email as status changes Ability to view jobs in progress Ability to view historical jobs Ability for manager to take and re-allocate jobs How do you avoid this?
  64. 64. A) Satisfied - B) It must be that way - C) Neutral - D) Can live with it - E) Dissatisfied <ul><li>Rate your satisfaction if the product has this attribute? </li></ul><ul><li>Rate your satisfaction if the product did not have this attribute? </li></ul>A A A A A A A A A A A A A A B B B B B B B C C C C C C C D D D D D D D E E E E E E E B B B B B B B C C C C C C C D D D D D D D E E E E E E E Single sign on Ability to model sales & get quotes prior to committing View current order status online Get email as status changes Ability to view jobs in progress Ability to view historical jobs Ability for manager to take and re-allocate jobs Apply constraints (e.g. costs, time, story points, etc)
  65. 65. A) Satisfied - B) It must be that way - C) Neutral - D) Can live with it - E) Dissatisfied <ul><li>Rate your satisfaction if the product has this attribute? </li></ul><ul><li>Rate your satisfaction if the product did not have this attribute? </li></ul>A A Single sign on A A A A A A A A A A A A Ability to model sales & get quotes prior to committing View current order status online Get email as status changes Ability to view jobs in progress Ability to view historical jobs Ability for manager to take and re-allocate jobs B B B B B B B C C C C C C C D D D D D D D E E E E E E E B B B B B B B C C C C C C C D D D D D D D E E E E E E E
  66. 66. If I had this… Don’t care If I didn’t have this… Satisfied Dissatisfied Neutral Don’t care Satisfied Dissatisfied Neutral Don’t care ? R R R             Don’t care R R R R $ ! ! ! ?
  67. 67. ?   R ! Questionable Delighted Indifferent Reverse Mandatory/Basic
  68. 68. <ul><li>Delighters are Unexpected things that a client would like to have. </li></ul>
  69. 69. <ul><li>Satisfaction is based on perception and expectations </li></ul><ul><li>Parasuraman and Berry (1991) </li></ul>Perceived performance Expected performance
  70. 70. <ul><li>“ So what does this mean for IT? </li></ul><ul><li>“ Making sure that you cover ALL basic requirements in a release, making sure you have some satisfiers and ONE delighter thrown in would always keep your business users happy. And no more than ONE delighter. Save some for future releases. “ </li></ul><ul><li>Narri Kannan </li></ul>http://it.toolbox.com/blogs/narikannan/kano-analysis-in-it-1023
  71. 71. Planning releases <ul><li>Delighters </li></ul><ul><li>Prove some in each release </li></ul><ul><li>Basic features </li></ul><ul><li>Release 1… </li></ul>Performance Indifferent <ul><li>Later stage features </li></ul><ul><li>Not needed </li></ul>
  72. 72. Context
  73. 73. Caution
  74. 74. Satisfied Dissatisfied Fully implemented Not implemented Performance needs Basic needs Delighters
  75. 75. The business analyst as product manager Stakeholders don’t always see the big picture You have the integrated view Use your judgement
  76. 76. Questions? <ul><li>www.BetterProjects.net </li></ul>
  77. 77. References <ul><li>Ullman, David G., The Mechanical Design Process, McGraw-Hill, Inc., U.S.A., 1997 pp. 105-108 ISBN 0-07-065756-4 </li></ul><ul><li>Jacobs, Randy, Evaluating Satisfaction with Media Products and Services: An Attribute Based Approach, European Media Management Review, Winter 1999. http://www.tukkk.fi/mediagroup/emmr/Previous%20Issues/Satisfaction.htm </li></ul><ul><li>Sehlhosrst, Scott, Prioritising Software Requirements with Kano Analysis, Pragmatic Marketing, Volume 4, Issue 3 http://www.pragmaticmarketing.com/publications/magazine/4/3/0605ss </li></ul><ul><li>Kanna, Nari Kano Analysis in IT , IT Toolbox, http://it.toolbox.com/blogs/narikannan/kano-analysis-in-it-1023 </li></ul><ul><li>Dave Verdyun, C2C-Solutons www.c2c-solutions.com/kano_tutorial.htm (Video tutorial) http://www.servqual.com/html/kano.tml </li></ul><ul><li>Lawrence Phillips, (2009) “Kano, How to delight your customers” Slideshare http://www.slideshare.net/LawrencePhillips/kano-model-rev-1 </li></ul>
  78. 78. More information can be found <ul><li>One of the best resources I found when researching this presentation was from Dave Verduyn at C2C Solutions Inc. </li></ul><ul><li>See his further information here; </li></ul><ul><li>  </li></ul><ul><li>An 8 Step Systematic Innovation Process (Kano’s Excitement Quality): </li></ul><ul><li>(1 of 2) www.c2c-solutions.com/Videos/SI_1of2/SI_1of2.html </li></ul><ul><li>(2 of 2) www.c2c-solutions.com/Videos/SI_2of2/SI_2of2.html </li></ul><ul><li>Integrating Kano’s Model into a Product Development Process </li></ul><ul><li>www.c2c-solutions.com/pdfs/C2CRoadmapNE.pdf   </li></ul><ul><li>Kano, VOC, and QFD: </li></ul><ul><li>www.c2c-solutions.com/tutorials/voc-qfd/player.html  </li></ul><ul><li>3 more videos on Systematic Innovation: </li></ul><ul><li>Video (1 of 3) www.c2c-solutions.com/sys-inn01.html </li></ul><ul><li>Video (2 of 3) www.c2c-solutions.com/sys-inn02.html </li></ul><ul><li>Video (3 of 3) www.c2c-solutions.com/sys-inn03.html </li></ul><ul><li>  </li></ul><ul><li>Article on integrating Systematic Innovation into Product Development: </li></ul><ul><li>http://www.c2c-solutions.com/pdfs/Integrating Innovation into DFSS_DMV1.pdf   </li></ul><ul><li>8 minute tutorial on Customer Wants and Needs: </li></ul><ul><li>http://www.kanomodel.com   </li></ul>

×