Making Things Better Makes Things Worse February 11, 2010
Posted by mwidlake in development, Management, Perceptions.Tags: behaviour, perception, system development
trackback
This could be a Friday Philosophy but I’ve got a couple of those lined up already. Anyway, I am suffering at work at the moment. I’m encountering a phenomenon that I have talked about with Dennis Adams a couple of times. It probably has a proper term, but basically it is the odd situation that when you make things better, you get more complaints. {Dennis, do you know the proper term?}
{Update. Dennis was good enough to link to this paper he wrote on customer feedback}
Anyway, Let me explain. You have an application sitting on a database. The screens are slow, the reports take an age to come out, your might even have considerable system instability and unplanned outages. The users are not unhappy. They were unhappy last year. Now they are just cynical and they just expect the system to be slow, unresponsive, flaky. So they do not report any problems.
Then things change. The system gets some much-needed care and attention and now the slowest reports get tuned up, the screens come back faster and less spontaneous department-wide coffee breaks are caused by the system crashing. Everything gets better. But not for the help desk, now they start getting calls. “This report is too slow”. “Why can’t I jump straight from the customer screen to the pending orders screen?”. This happens because the users now realise that something can be done. There is a point in complaining as there is a chance their piece of misery could be made better. I certainly went through this many years ago when I inherited a system that crashed every week. No one mentioned it, they just went to tea and complained about it. The first time it crashed after I arrived I could not believe that no one had called before I had realised it had died. Once it had been up solidly for a couple of months, then when it crashed boy did we hear about it!
Also, when you improve a system and things generally get better, occasionally something will improve and then fall back a bit. Hardly anyone says “thanks” for the initial improvement but they will say something if it improves and then drops back.
That is what is happening for my main client at the moment. The system was not that bad, but it needed some help. Why else would I be there? I’ve been beavering away with the rest of the team and we are making things better, so far mostly at an underlying “getting the overall system straight” level. A new chap has joined to help concentrate on performance and he is really making inroads into specific things, individual reports and processes that need a good sorting out.
So now that things are getting better and performance is generally improving, anything that is still slow is being brought up by the development and support teams. Also, we’ve made a few things slower (I’m sorry, it just happens like that) and they certainly get mentioned.
So, I’m busy. And I could get annoyed at people asking why X is slower when Y and Z are faster. But I don’t, because Dennis explained this counter intuitive theory to me.
I know things are getting better as people are annoyed as opposed to apathetic 🙂
Posted by Dennis but on the wrong post {and I went and referenced him! Weeellll, he is a process guy more than a techie these days 🙂 }
***********
Martin,
Nice Blog.
Thanks for proving yet again that it’s always People that confuse an otherwise simple system!
The theory about how customer expectations change over time is based on work by Prof. Noriaki Kano (name dropping!).
There is a fairly famous story of where Xerox came across this many years ago, so it is sometimes known as the “Xerox effect”.
I prefer the term “BOG”, because I have that sense of humour !
Click to access BOG-customer-feeedback.pdf
Dennis
Thanks for moving the comments, Martin.
I tend to be so much involved in IT Strategy these days that I forget the fundamentals… Such as “make sure you put a comment in the correct blog entry”.
Sorry 😦
Dennis
[…] while I’ve got your attention, here’s an excellent posting from Martin Widlake about making things worse by making things better – and make sure you follow the link from Dennis […]
A problem is the perceived distance between expectation and reality. When you changed reality, you changed the expectation, too!
Your blog post is evidence that you’ve got to measure them both.
It’s a very valid point Cary, but measuring expectation is damned difficult when the expectation is based on apathy. Dennis’s paper makes that point very well.
The whole issue of judging the opinion of those who are neither very happy or very unhappy is a common problem (and a common fault) of opinion surveys.
BTW Cary, very, very good book 🙂 I was so glad to come across something that put so well things I had been struggling to put into words about the significance of variation and tipping points.
Lovely. And how familiar.
Hmmm, I’ve seen a related phenomenon in which people raise the improved performance itself as an apparant bug. Many years ago a company I worked for generated monthly invoices overnight for several days. The process was slow because the generation of each invoice number took about 30 seconds (partly a consequence of requiring that invoice numbers be sequential). Adding an index allowed the generation of a month of invoices in less than an hour, and a call was raised on the basis that something had obviously failed … “some key part of the processing must obviously have been missed and the invoice run must have been invalid”.
One genuine fault did emerge — the overheating of the invoice printer as it exceeded it’s duty cycle.
Good times.
🙂 I like it David, especially overheating the printer.
I had a similar “too fast to be working” experience several years ago. I had to work on a load of “exceptions” reports for a large gas energy shipment company. These exeception reports were taking 10,12 hours and the people who processed the exceptions had nothing to do in the morning, waiting for them to turn up. So we found that cunningly adding some indexes to support the queries would make them faster. The reports now took two or three minutes after that. But it took days to persuade the managers that they were coming out with the correct results, because (a) they ran too fast and (b) the resultes were not exactly the same from the new version.
They were not exactly the same as these reports ran sequentially and, for the long-running ones, the data was shifting underneath them. There was a difference, the faster ones were more accurate. 🙂
“Gas energy shipment” company eh? I wonder if it was the same company as the one with the invoice problem …
[…] Widlake has a thoughtful post on the DBA and his or her job, called, Making Things Better Makes Things Worse. He say, “I’m encountering a phenomenon that I have talked about with Dennis Adams a couple […]
Hi David,
If the printers were in Solihill (or Shirley) then yes, same company probably 🙂
Martin
Hotsos 2010 – Day 2 – The conference begins…
A 3:30 start, which gave me lots of time to work on my demos and by breakfast time at 7:30, I felt in a reasonable place (but not quite done yet) and headed down to eat … wait for it … some fruit! Then again, I’d eaten so little the previous day t…