-
When IT Is Your Company’s “Piggy Bank”
February 10, 2012
-
4 Key Things a Project Manager Must Do
February 10, 2012
-
Essential Project Management
February 10, 2012
-
8 Traits of Top Project Managers - Part 1
February 9, 2012
-
Agile Project Management - Engaging Your Customer!
February 9, 2012
-
9 Tips to Avoid Traps in Project Planning
February 9, 2012
-
Why Projects Succeed - Executive Sponsorship
February 8, 2012
-
On Customer Participation in Agile Projects
February 8, 2012
-
A Project Charter for Lazy Teams
February 8, 2012
-
The Power of Process: How Bad Project Management Kills Great Ideas
February 7, 2012
Kano Model and Classifying Requirements
August 6, 2007 | Author: PM Hut | Filed under: Project Plan Development
Kano Model and Classifying Requirements
By Craig Brown
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 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.
Craig Brown has worked as a project manager and business analyst mainly in the Australian ITC and the banking industries. He has also worked in the law, education and welfare industries, including starting a law firm. Craig now has a Master’s degree in project management from RMIT university, and is currently working with a Melbourne based IT consulting firm called OptimiseIT. Craig’s personal blog can be found at http://betterprojects.blogspot.com.
Related Articles
feel free to leave a comment
Comment Guidelines: Basic XHTML is allowed (a href, strong, em, code). All line breaks and paragraphs are automatically generated. Off-topic or inappropriate comments will be edited or deleted. Email addresses will never be published. Keep it PG-13 people!
XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
All fields marked with " * " are required.
- Agile Project Management
- Ask the Hut
- Certification
- Change Management
- Communications Management
- Computer Based Information Systems
- Concepts
- Corporate Transformation
- Cost Management
- Critical Chain Project Management
- Delegation
- History
- HR Management
- Implementing Project Management
- Integration Management
- Lessons Learned
- Management
- Miscellaneous
- People Issues
- PMBOK
- PRINCE2
- Procurement Management
- Program Management
- Project Lifecycle Phases
- Project Management Advantages
- Project Management Advantages
- Project Management as a Career
- Project Management Best Practices
- Project Management Charts
- Project Management Definitions
- Project Management Ethics
- Project Management for Beginners
- Project Management Guides
- Project Management Musings
- Project Management Office
- Project Management Proposals
- Project Management Templates
- Project Portfolio Management
- Project Workforce Management
- Quality Management
- Requirements Management
- Risk Management
- Scheduling
- Scope Management
- SCRUM
- Soft Management
- Time Management
- Training
- Uncategorized
2 people have left comments
[...] like this model and have written about it before. It’s about identifying what is going to delight a customer if delivered, and what is going [...]
[...] Requirements can also be categorised into classes along the lines of the Kano model: [...]