When I was working as a developer, years ago, the IT Director decided that he wanted to improve the performance of the team by focussing on quality.
As a result, we were all asked to go away into our teams and figure out what is quality, and how we could improve it.
As developers, we had a clear idea about quality; it meant structured code, sensible naming conventions for variables and comprehensive documentation, so that another developer could pick up the code and understand what was going on.
The Network Team felt that quality meant twisted pair LAN cabling, TCP/IP and digital (kilostream and megastream) links to our remote sites.
The Business Analysts thought that it was more about the quality of their ideas, and the amount of value they added as an interface between the users and the technical teams.
The Service Desk team had a strange view, they thought it was all about user satisfaction. Surely, we argued, quality for you should be about call resolution times, call pickup stats and the correct categorisation of calls?
No, they insisted, quality was inextricably linked to user experience, and the only meaningful way to measure it was the response from the users.
It may help to explain at this point that the Service Desk team (or Helpdesk, as it was then) was made up of people who had come from the business, and weren’t generally very technical. It’s probably no coincidence therefore that they put a strong emphasis on user experience.
The matter was settled once and for all when a consultant was brought in to help us with our quality system, and he pronounced that quality meant exceeding users’ expectations. I recall that I was unhappy, at the time, with this woolly, imprecise definition, and I thought that my technical definition was much better.
Fast forward twenty something years and it’s evident to me now that the consultant was right and I was wrong; quality is all about expectations, and I would say that the most important part of my role right now is ensuring that customers are clear about what my team can deliver, and by when.
I have written before about Service Catalogues and Business Cases, and these are excellent ways of describing service boundaries, but it amazes how often people still make assumptions about what we can do for them.
Until we can be certain that our stakeholders understand about IT’s capabilities and resources, it will be impossible to claim that we are providing a quality service.