By now we should all have an idea what Kano analysis looks like. There are basic, performance and excitement classes of requirements. You generally have to work your way through the basic ones before you can start to address the other categories.
I have been reading Daniel Kahneman’s work on decision making and found he’s got some concepts on the importance of reference points for decision making. He talks about “Bernoulli’s error.
Are you with me?
I’ll back up two steps and cover the “Bernoulli’s error” concept here.
Basically this is the guy who gave us the normal distribution. The thing he came up with is decision making ‘should’ be based upon logic and rational thinking. It’s also fixed on a particular reference point (i.e. the day you analyse the situation and make a decision) and the decision extends into the future.)
So, an example; You need to work out the best car for you. The Aptera 2e may be the right choice. It was always the right choice, and it always will be. At least until a better car comes along.
But.
If you are already driving the ZAP Alias, the decision to migrate to the Aptera may be a different one that if you are driving something a little older.
The mistake that Kahneman identifies and articulates is that our reference points change over time. What we perceive as valuable, or risky today, is different from the past and will be different in the future.
Kano recognises this and sees that what can be an ‘exciter feature’ today will eventually be commoditized.
Another example for the business casers out there. A return on a project of $10 million a year sounds okay now, but what if a better opportunity comes up later? Does our decision to go for $10Mpa stand?
And at the more detailed level, a system requirement that sounds like a basic and mandatory feature today might become irrelevant later, as more becomes known about the way users interact with the system itself.
Of course you eventually have to commit to something and you can’t just keep abandoning projects or requirements as something better comes up. You have to be able to see where you are and where your next step will take you. Divining too far into the future is pointless and results in ‘analysis paralysis.’
12 March 2010
Subscribe to:
Post Comments (Atom)
Popular Posts
-
I have been having a bit of a discussion over at the IIBA blog with Kevin (VP BOK) and Julian (Chief architect.) It’s migrated over to ...
-
Due to popular demand I have aggregated some information on User Stories and created a simple template. If you feel this would be useful to...
-
Better Projects Templates I am uploading a couple of project document templates to Google Docs. As I add more I'll post them up here. You...
-
You've heard many reasons why project fail. Here is a discussion hosted by BCS on why projects work. The discussion covers four dimensio...
-
The Precedence Diagramming Method ( PDM ) was developed in the early 1960s by H.B. Zachry in cooperation with IBM. It has largely repla...
-
In the below video some of the #10yrsagile participants discuss the role of the Business Analyst. A question for you; Do you agree or di...
-
This is a guest post by Jeff Hobbs. Jeff is a project manager at ActiveState Software who provide pm and collaboration software. Email, ...
-
In one of the Carnivals of Business Analysts the theme was “ Requirements Analysis ." I searched the web far and wide and came up with a n...
-
The definition of a stakeholder is controversial. For example, project team members are generally not considered stakeholders, but in virtua...
-
I have written about the V-Model across several posts. The V model is a testing focused expansion of the software development lifecycle. In ...

1 comments: