One Last Thing on Kano

Last post on this (following this one and this one), I promise.  A slightly different look at the Excitement path as it applies to deployment.

How many times have you or your peers tried to deploy a new process or tool, only to have it met with a “meh” from your clients?  When you KNOW it’s a quality product and that it works as designed, your frustration can skyrocket and your motivation disappear.  Why does it happen, and why does it get us down?

Well, the second part is easy to answer.  We’re humans.  (Most of us, anyway.)  We like to be successful, we like to be recognized and appreciated for what we bring to the table.  And when our projects aren’t met with much fanfare, it stings.

More important, though, is WHY they are met with anything less than ticker tape.

Let’s think back to the last time this happened.  Examine the process or tool, and think about where it falls on the Kano model.  There are real dangers of non-acceptance for each category.

Basic

Are you “good enough” at it?  If so, rolling out more, new, improved or lemon-scented version are inherently unnecessary.  The work may not be a “waste of time,” but it won’t be something for which people are waiting, and it won’t be something for which they will thank you.  It’s more likely to be met as “more change.”  And that will hurt your future projects.

If you’re working on Basic items, and you are “good enough,” stop working.  Your clients will thank you.

Excitement

It feels like these should be met with kudos, right?  So why doesn’t it always happen?

Excitement items will get people, well, excited, but only if you execute them at a high level.  Rolling out a first pass or draft version that isn’t spot on and error free will actually hurt your credibility.  People don’t want early iterations.  They want final products.  These projects are the ones that should come with a warning tag to ignore due dates, and focus on a deliverable list instead.

Performance

A whole different approach applies here.  These are the projects that do benefit from iterations.  Going back to the examples from the first post in this series, commodity goods fit this model.  We like gas at $1 per gallon, and we like it a whole lot more than gas at $3 per gallon, but we still buy it at $3 because we need it.  Buying expensive gas is, in most cases, less painful than not buying gas at all.

If you are building a Performance tool (such as a self service system), you might be well suited to roll out a stripped down basic version first, building momentum and credibility, and then cycling through iterations of improvements.  As long as each version brings more value to your customers, your adoption rate and positive feedback will increase as well.

The key to successful project implementation is knowing when to release and when to delay.  Knowing where your project falls in the Kano can help you time your activities to get the most out of your work and position it for the best response from your customers.

 

Comments

  1. Thank you for this model. Occasionally HR iniatives are rolled out without thought or communication of the underlying value to the business – how will this help us make/save money/time, etc. It just appears, people are trained (with much confusion) and in some cases the initiative is never heard of again. I like the idea of using this model and totally agree that good enough for many things is plenty – reach error free and then stop.

    • Mary –

      Thanks for the feedback. It’s one of those great forgotten tools that help us stay focused. I’m glad you liked it.

      Thanks for reading!

Lean HR is using WP-Gravatar

%d bloggers like this: