James O'Neill's blog

Windows Platform, Virtualization and PowerShell with a little Photography for good measure.

Quality assurance Vs Quality improvement. Which thinking do you want ?

Quality assurance Vs Quality improvement. Which thinking do you want ?

  • Comments 1
  • Likes

One of the Microsoft internal discussion lists has had an interesting thread over the last couple of days which started like this. 
Poster: "I know about bugs in [X], but I work on [Y] and all the objectives I'm measured on are based on getting [Y] right. I can't find time to file bug reports on another teams product."
Others: "That's terrible"

And from there the conversation descended into criticism of product [x], the Poster's attitude, the Poster's management's attitude and the bug reporting process, the philosophical nature of objectives, and has now reached the point of  someone posting a picture of their cat...

This reminded me of something from Long ago, when I was working in product support for RM, and our Managing Director picked up the Juran Quality Improvement (JQI) methodology used in Japan (he talks about it here). I remember 3 principles of JQI, and I'm convinced there was a fourth but I can't track it it down - probably something about counting defects and trying to get to zero. (I was visiting a high tech customer a couple of weeks back and saw a chart which showed defect rates way below what I'd expect for their business - zero in one recent month - with the words "Defect rates remain unacceptably high" in the text beneath it. That's JQI thinking.) The three principles I remember are:

  • Quality is meeting the customer's needs.  [Different customers have different needs. The top need is that the product works, and keeps on working. 'Quality' is not simply a synonym for good or "prestige"]
  • Quality is free [better phrased as quality pays for itself. Unhappy customers, and support have a cost which is more than the cost getting the product right]
  • Quality is everybody's responsibility

And of course this last point is the one which links to the discussion on the thread. It's also the most difficult one to implement because, responsibility without power achieves nothing. The easiest way to turn "Quality is everybody's responsibility" into an empty slogan, is to make any action that such responsibility requires a career limiting move. To work, management must shift their thinking to be self critical and when their actions hinder meeting the customer's needs they must embrace criticism. I'm not surprised that (in Britain at least) quality improvement went out of fashion in favour of quality assurance (ISO 9000) systems which assume that management knows the best possible way to do things and what's needed is ensure people follow a process: empowering them to change things or criticize management decisions isn't desirable or even necessary.  

 

Of course the opposite of "Quality is everybody's responsibility" is the Bystander effect or what Douglas Adams called the "Someone else's problem field" (I mentioned this before when talking about mail.). Last week one of the Proxy servers which hooks us up to the Internet had a fault. Steve complimented me on my endurance after I spent 48 minutes on the phone to the "Help desk" to report it. Our help-desk used to be based in Dublin, and it helped. You'd often get someone with a mixed Dutch and Dublin accent (the staff we multi-lingual) and they'd improvise to solve the problem when they needed to. To cut the cost per call the function our helpdesk moved to India, but it's more than the accents that have changed: the staff now won't depart from their scripts, even if the script isn't right for the problem (which I associate with implementations of ISO9000 ) 

In the old days I would have called Dublin said "When I try to go some web sites I get an error that says Proxy server 11 is out of space" and they'd have answered "We'll send yer-man Dermot down there with a big a hammer. Try again in a few minutes". Now I call Bangalore and someone opens a service request and launches into the "Problem accessing the Internet" Script. He remotes into my machine, relaxes my security settings, turns off auto proxy detection (so IE won't work at home), disables third party add ons, and finds that the proxy server is still giving the same error. So he mails himself the results of IPconfig and tracert. He's amazed when I use "Mode Con COLS=132" in a command window to stop the text from wrapping (which makes me wonder about his ability to go off-script). Normally I'd commend someone for spending 48 minutes trying to find problem on my machine - except I told him the first 48 seconds the error came from the Data centre and affected other people. When he's done I have to put my machine back to its working state and close the service request. Total cost in my time - about an hour. I  still price of my time at the billing rate it was when I was a consultant 1 hour = £200.

This experience isn't unique: When a I called to get a disabled network port re-connected, the help desk pulled out the "Network connection problem" script and asked my IP address. I couldn't get an IP address because the port was disabled. "Oh". They said can we have the MAC address then. I gave it to them. "We can't see that address". "No" I said, "When I plug into the port on this desk the lights on my network socket don't light up, the port is dead. How did you expect to find me on the network."

A colleague's  SmartCard split: the chip looked OK but his card wouldn't work in any machine, other cards worked in his machine. He called to find out how to get a replacement  Dublin would have said "Nip down to the security office and they'll get a new one for you". Bangalore got out the "smartcard problem" script and walked him through re-installing the Smartcard Crypto provider, drivers for the reader (he protested every step of the way that the problem was physical damage to the card). After an hour the call went to second line support (who eventually told him how to get a new card).

Of course Microsoft isn't the organization where people are getting experiences like these. They teach us don't call the help desk; problems affecting shared systems are someone else's problems, and if it really is your problem, find someone on your team to help. With fewer calls and each costing less offshoring the help-desk looks like a success. Unless you look at the meeting the needs of the helpdesk customers (like me).

Comments
Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment