Failing fast to learn a lot

In another post I referred to a survey, showing that the majority of errors are made in the specification phase.

I often wonder why it’s such a hazel, for the customer to specify what they actually want.

I was attending a change management meeting not so long ago. One of the pointers was, that we are all making the majority of our decisions based on “perceived personal value (PPV)”.

In the case of change management PPV is the value, that one thinks the change will have for one self.
That is, if my boss suggests to me, that we should change the way we test our deliverables. I will unconsciously evaluate the value of those changes to me.
If I think I’ll end up spenting more time without elevating the quality. I will not be as motivate to implement those changes, as if I think I’ll spent less time accomplishing the same results after implementing the changes.

Sounds pretty obviuos right? But just as important and not so obvious is: If I cannot see the value nor see a loss of value. I will still be more affraid of the loss of value than looking for the potential gain.

Basically PPV is all the coolness factor. If a change makes us look more cool, we welcome that change. If it doesn’t make us look cool, we’ll more often than not be afraid that the change will make us look uncool and hence we’re not overly excited about it.

Let’s try and apply the same logic to specifications.
The persons responsible for the specifications will want all the success of the application to reflect back on them self and the possible failures to be somebody else’s problem.

Bear in mind that no matter how bad the specifications might seem. The people writing them are doing their best to be as cool as possible. The problem is, that the way they unconsciously evaluate what’s “best”, might be and often is slightly off the target.

My favorite user argument for doing things the way they did, was that they wanted the specifications to be flexible. They did not realize that that was self contradicting.

Loooking through the PPV glasses they were so affraid of making decisions that might turn out to be lower their PPV that they wanted to be able to change their mind at any time.
At some point they did change their mind. Unfortunately to implement the wanted changes we would have had to rewrite the entire domain model.
Faced with a 50% cost increase they decided to stick with what they already had.

I’m sure, if they had been forced to make those decisions before hand. The fear of taking uncool decisions would have made them think more about use scenarios. Making them realize that subtle changes to the requirements was needed. I also know, if we had had those extra requirements from the start we could have implemented them with no extra cost.

I wish that we as developers could make customers realize that not taking decisions that might lower the personal value later on, is making a decision that will lower the personal value gained. I do however have an idea on this, that I’ll blog about later, which is where building bath rooms comes into play.