Quality - What's It Really All About?

I've spent a lot of time recently (far too much I fear) looking and occasionally participating in some of the LinkedIn Quality Forums. Most of these have been the ISO 9001 type forums rather than domain specific. With ISO 9001 being a generic quality standard, it’s not surprising that the participants in these forums come from all walks of life, from aerospace to telecoms, from supply chain managers to certification body auditors, and from quality directors to quality engineers. Occasionally there are people like myself - who are primarily involved with knowledge workers.

The biggest take-away I’ve had from these forums is that consensus amongst quality professionals is rare, that tempers seem to flare far more than in other forums I frequent (including some of the ‘agile’ oriented groups) and that you could lock a group of quality folk in a room for a month and they’d still be no closer to defining what quality really is!

So, if there’s so much discord between people who actually spend their lives and earn their keep from working in quality, what chance do the rest of us have. I include myself as one of the rest of us quite deliberately as these days I think of myself as a business person who happens to have some hands-on understanding of quality matters in some very specific situations - namely the IT industry and more specifically in software development.

Looking for a standard definition doesn’t really get us very far. I’m not even going to bother with a dictionary definition because it’s so vague but here’s Wikipedia’s entry:

Quality in business, engineering and manufacturing has a pragmatic interpretation as the non-inferiority or superiority of something; it is also defined as fitness for purpose. Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people. Consumers may focus on the specification quality of a product/service, or how it compares to competitors in the marketplace. Producers might measure the conformance quality, or degree to which the product/service was produced correctly. Support personnel may measure quality in the degree that a product is reliable, maintainable, or sustainable. A quality item (an item that has quality) has the ability to perform satisfactorily in service and is suitable for its intended purpose.

The clue as to the problem is clearly stated in the second sentence which is so important that I’ll quote it again.

Quality is a perceptual, conditional, and somewhat subjective attribute and may be understood differently by different people.

My experience of quality is mostly internally facing, supporting the group of people who collectively have responsibility for developing the IT product or service, be they managers, developers, testers, analysts or even salespeople, HR, and finance. This is my set of primmary customers, and there is usually some interaction or interface with a client side quality person. The products I have traditionally had responsibilty for are the processes, artifacts, workflows, data and tools that my customers need to be able to produce the best products they can for their customers.

It’s been evident for many years that trying to apply traditional product and manufacturing quality tools in a knowledge working environment is somewhat futile. Conceptually, there are great ideas that can be applied in both manufacturing and knowledge based industries. A great many quality principles can be applied universally, but principles, ideas and tools need to be aligned closely to the environment they are to be used in. In other words, they are almost always contextual.

An inspection process (let’s not get involved for now about whether inspection is a good or bad thing) in the software development environment is very different to the inspection process on an automotive production line. Six Sigma out of the box, doesn’t work well in the software development environment - if for no other reason than the original principles were designed to work with highly repetitive automated processes where human interaction is much less than when developing software which is highly dependent on individuals. We have a similar situation where Lean Manufacturing ideas applied to an office environment without some serious tailoring and adaptation leads to the type of nonsense I described in my previous post where desks were marked out with the 'optimised' positions for computers, keyboards, mice, telephones, etc. regardless of whether a person was right or left handed.

Ultimately, it doesn’t matter too much if there isn’t consensus between quality folks coming from different contexts. What’s important is that people in the same organisation have a consistent view of what quality means in their very specific context. I’m not talking about the slogans and banners that seem to adorn so many office corridors and walls, but a real shared understanding of what is expected from your people when it comes to quality in the workplace, and an up front statement of what your people can expect from their quality department. And then we all need to act and behave accordingly.

If we work on the old adage that "quality is everyone’s responsibility", then this is the very least we can do.

Are You a Slave To Your Quality Management System? (Part 2)

In my previous post I proffered up some suggestions as to why many organisational Quality Management Systems end up as Quality Management Shambles. My hypothesis is that too many management systems (quality or otherwise!) are created for the wrong reasons, and generally get created without due care and attention to quality principles, systems principles or architectural and design principles. Over time, without a strong foundation on which to build, the QMS grows chaotically and incongruously, and ceases to be able to serve the people it should have been intended for in the first place. Instead, the organisation becomes a slave to the QMS.

In this second part, I'm going to expand on the five questions I posed in part one, with specific regard to the principles mentioned above - Quality, System, and Architecture/Design.

Question 1 -  What is the purpose of your QMS?


I surmise that if I asked that question in a certified ISO 9000 organisation (or many organisations successfully asssessed at CMMI L2/3) I would get a  different answer for each person that I asked - and certainly different answers from different levels of the business). Typical responses:

• Developers - it's because of this ISO/CMMI initiative
• Middle Management - to ensure compliance
• Senior Management - so that our staff know what they have to do
• Executive Management - so that we can standardise operations and efficiencies across the business

The real reason for a QMS has most likely been forgotten or distorted over time. If you cannot articulate you reasons for having a QMS (think elevator speech here) then it's probably time for a major review. Adherence and compliance to standards may be valid reasons for a QMS but they really must not be the primary drivers. You also need to consider whether your QMS has become a substitute for training. If your induction speech for new starters includes "you need to read the quality manual to understand how we do things round here" you probably need to rethink both your QMS and your training strategy, not to mention your induction techniques!

Question 2 - Who is the intended audience?


Most managers will glibly answer this by saying that the QMS is mandated for all staff, but the truth is that the mandate (and usage) will also certainly be biased towards the lower levels of the organisational hierarchy. In far too many organisations senior managers cannot even tell you where to locate the corporate policies never mind being able to explain them or even abide by them (even though they are responsible for them!).

Ideally a QMS will be architected from multiple viewpoints; a developers needs will differ from someone in HR or Finance, so it makes sense to organise a management system accordingly. That said, it doesn't follow that HR related material should be restricted to HR staff. A good QMS must be transparent across the enterprise.


Question 3 - How do we intend our staff to use it?

This is linked to elements of the preceeding questions. Ideally, the QMS will be a simple to use, easy to navigate, supporting reference for staff. Inexperienced 'users' can see as much detail as necessary, whilst more experienced 'users' can filter out the information so that the material acts as a memory jogger when they need guidance.

Having a good, well maintained QMS does not abrogate the organisation from ensuring that staff are 'trained' in company policy and procedure - and this should be on-going for all staff across the business, especially as changes and modifications are made.

Failure to design and architect a QMS from multiple perspectives will devalue it over time, and once it becomes 'shelfware' (or whatever the cyber equivalent is) it becomes a potential source of many other cultural problems.


Question 4 - Does the QMS reflect the way we actually work and our culture?

In the same way that failing to architect and design a QMS according to our basic principles initially will ultimately devalue it, the QMS should be continuously updated to reflect changes to working practices, regulations, and cultural changes. Most importantly, things that are wrong, inappropriate or outdated must be modified or removed as early as possible. Users do not want to be placed in a situation where they are required to demonstrate compliance to a process, policy or procedure which may be detrimental to their daily work. A mechanism for emergency fixes is critical and a queuing system for change requests is not good enough. A waiver system must be in place to allow teams to bypass incongruous instructions, and this process must be quick and simple. [Note that a waiver is a temporary mechanism and requires appropriate governance to prevent abuse!  - see my blog entry from July 2009 for more about waivers]

As a user of dozens of management systems over the years the things that annoy me most are (in no particular order) - over complexity, difficulty to navigate, response times and missing or inconsistent information. Which brings us onto the final question...


Question 5 - Is the QMS aligned to the system that is our organisation?

For me, this is the fundamental question. If we accept the basic premise that an organisation is a system, then it goes without saying that the QMS should map against that system and should mirror the entities, interactions and flows that exist in the real world of the enterprise. It should reflect the internal corporate culture and use the organisations language and terminology. Most of all, it should reflect what you do, not what you think the auditors or assessors are expecting you to do. When it comes to the QMS too many organisations waste too much time and effort doing the wrong things.

So, there you have some quick answers to my five questions. A good QMS will be an valuable asset to everyone in the organisation. A well designed and architected QMS that aligns to the business systems, objectives and values, and is maintained accordingly will be welcomed by the majority of staff and most importantly it will get used - for the right reasons.

Take back control of your QMS today, and stop being a slave to it!

Are You a Slave To Your Quality Management System? (Part 1)

When I first started working, IT businesses tended to fall into one of two categories - those that had a Quality Management System and those that didn't. Those that did tended to have a library of management standards (literally - there would be rooms stacked full of folders with thousands of pages of policies, processes and procedures) which employees were expected to obey without question. The whole purpose of the Quality Department was to maintain the Quality Management System and to ensure compliance to it. The Quality Management System not only represented thousands of trees, but the amassed knowledge, understanding and wisdom of the organisation over its lifetime.

Over time, these libraries have been (mostly) replaced by equally enormous libraries of on-line documents much to the relief of trees and tree huggers over the planet (but to the chagrin of printers). More and more companies have moved from the "have none" category to the "have" category thanks to the relentless movement towards ISO, CMMI, ITIL and whatever other set of standards, models and frameworks you wish to add.

What most of these companies share is that what they call a Quality Management System is anything but a system. In many cases it's actually a shambles, so for the rest of this piece when you see the acronym QMS it stands for Quality Management Shambles.

So how does something that starts off with a (hopefully) good intention end up in such a mess and what can you do about it?

Many organisations signed up to ISO 9000 because they were required to in order to do business with other organisations, especially government ones. Some did so because they saw that having a Quality Standard behind them help differentiate them from their competitors. Some probably did because a Quality Consultant told them it was a good idea. Whatever the underlying reason, one thing was certain - the first thing they did was to create a QMS in order to meet the requirements of the standard and then mandate that all employees followed the QMS to the letter so that the organisation could get (and subsequently keep) its certification. In many organisations, you can see that the QMS is actually organised according to the original headings of the standard in the same way that many businesses now organise their QMS to align with CMMI Process Areas. Over time, new bits got added to correspond to new departments, regulations, legislation, management proclamations and other influences. In the good places, old bits got updated or achived, and in the very good places improvement programmes were initiated to replace the bits that weren't working and so the ISO quality cycle was fulfilled. And the QMS became more and more shambolic.

By making the QMS meet a relatively arbitary standard (albeit globally recognised) the most crucial questions and drivers were generally ignored, namely:

• What is the real purpose of the Quality Management System?
• Who is the intended audience?
• How do we intend our staff to use it?
• Does it reflect the way we actually work and our culture?
• Is it aligned to the system that is our organisation?

In other words - do we control our Quality Management System or are we slaves to it?

If you don't have answers to these questions, then you should really start to reconsider whether your Quality Management System has any place in your business other than as a stick to beat your staff with, or a tool to demonstrate compliance to a standard that may or not add genuine value to your business.

Next time, I'll look at the critical success factors in designing a [Quality] Management System that is fit for purpose and can be used to enhance the working environment rather than choking it.

A Message to the New Breed of Software Developers

With the advent of the "App" and their associated distribution stores (Mac, iPhone, Android etc.)  the act of developing software has never been more popular or more accessible. The opportunity to create the next "Angry Birds" in your bedroom or living room and become an overnight millionaire is clearly very enticing to many individuals.

Before I became involved in Quality and Process Management, and long before I became a consultant I earned my living as a software engineer. I use the term advisedly - I wasn't just a programmer; I was a systems designer, architect, tester, requirements engineer, configuration manager and I learnt my trade over the course of many years from some great and passionate people.

I was driven by simplicity, elegance and efficiency in both design and code. But mostly I was driven by a desire to be a brilliant engineer with acute attention to detail, and a self motivated need to write as near perfect code as possible. It helped that in those days we were constrained by both hardware and software limitations. Compliers were command lines driven, terse and unforgiving, and IDEs were few on the ground. Memory and disk space was grossly expensive and processors were slow. A build that today might take a minute or two would take half a day, so silly mistakes were costly and time consuming. Most people, including myself coded away from the machine, only committing when we had desk checked everything to iron out as many problems as possible. All these things led to the disciplines of efficiency and care that we learnt back then.

Today, computer resources are plentiful and cheap. Software development tools are powerful and much easier to use. The constraints we suffered are resigned to our memories and computer museums. The only constraints that haven't changed are time and money which are clearly still in short supply in all commercial development shops.

But despite these advances in technology those quaint old values that I shared with my colleagues, my mentors and mentees, should still be forefront in every developer's mind. Cutting corners is not acceptable. Shipping products that fail is not acceptable. Thinking of your customer simply as a cash cow is not acceptable.

I use mobile devices for many activities during the course of the day - some critical for business and some which are critical for my relaxation. I expect these devices to work without having to reboot them during the course of the day (as I do with my laptop and desktop machines). Far too many apps crash my devices and memory management is often diabolical. New versions of software reintroduce old bugs suggesting that no proper version control is in place.

I think it's great that people have the ability, imagination, enthusiasm,  capacity and desire to create software and there are a number of apps I use regularly on both my iOS devices and Macs which are a pleasure and delight to use. These are often sourced from those one person outfits whose desire to create great software outweighs the desire to get rich quick. They also tend to be great at supporting problems and always willing to go the extra mile to help fix things when they occasionally go astray. These people understand that they have a responsibility to focus on the details and to get things as right as possible as often as possible.

So my message to all developers, commercial and freelance, whether part of a team or solo artists, is simple. Please reassess your values and your methods next time you start to work on a piece of code or a new design. The best processes in the world are worthless if you - as an individual developer - fail to actually give a toss about what you are responsible for, and fail to give true consideration to your customers and their basic needs and requirements.

A Trip Back to the "Bottom of the Ladder"

I've worked as a "management" consultant, either internally or externally, for the best part of 20 years now, and I've often heard people say that all consultants should occasionally step down from their ivory towers, and go back to their roots. It's not very often that I've heard of any consultants taking their own advice, unless it's a career move, but recently I did just that, although not through choice or design. I've spent the last six months working back at the coal face as a project quality manager. Now I can let you into a secret: it was not a fun experience! It was interesting, challenging, frustrating, and at times just damn hard work, but fun is not an adjective that readily springs to mind when talking about the engagement.

So why on earth would I want to write about it? That's easy; I now fully understand why every consultant should do the same thing and that's what I really want to share with you.

Before I go any further however I want to make an important statement. The organisation I was working for showed me nothing but respect and I would gladly work for them again in a different role. The people I worked with on a day to day basis were professional, open to new ideas and accommodated my slightly maverick and off-the-wall approach and this included both managers and project staff. The organisation itself is a very large, world renowned, and highly respected financial institution, and it won’t do me any harm whatsoever in having it listed on my CV. It has its headquarters in continental Europe where English is not the first language (but where it is the accepted business language), and as a financial institution it is part of a highly regulated and somewhat conservative industry, especially when it comes to quality. Of course, as a large organization with a distinct culture built up over many years, change can be difficult to manage, and therein lies the heart of my discontent during my tenure there.

I’m used to leading change in organisations, either directly as a programme manager or in an advisory and consultancy capacity. I like working with the “big picture”, although I’m happy to work amongst the weeds to better understand what’s really going on and I have no problem understanding and working with the little details. In the project quality management role, I experienced first hand the deficiencies of an industrial level process improvement programme and set of quality policies which I have fought so hard to change in the past. As an external contractor, on the lowest rung of the quality ladder, my day to day existence was spent adhering to internally imposed quality standards and practices which, for the most part added little or no value and which I was unable to push back against. More frustratingly, my views were clearly shared by many of those around me including my managers who were also manacled by these policies created by an apparently intransigent central process and quality team which was deaf to genuinely useful feedback and refuted that they have any obligation to change their own behaviours. It is one of the worst cases of ivory tower syndrome I have ever encountered, made even worse by dint of their being geographically removed from the hub of the delivery operation.

The quality culture, as applied to process improvement, was partially diluted and confused by the decision to outsource a large tranche of the process improvement activity to an external consultancy from India. Although senior managers were home grown, the volume of external consultants overwhelmed the internal staff, and they effectively imposed their own process improvement culture on the organisation. Now I'm all in favour of bringing in external consultants to assist in developing process management capability; otherwise I'd be permanently unemployed. However, I don't agree in outsourcing, en masse, something which has to be developed organically.

During my incumbency the organisation underwent the scrutiny of a CMMI Level 3 SCAMPI A appraisal and two of the projects I was working on were in scope as non-focus projects. This gave me an even better understanding of how and why some things were as they were, but still did not excuse the basic errors that were being made in terms of overall process and quality management. It was as if this was the first process improvement programme in history, and there was no history to learn from. However, I won't dwell on that just now.

Regular readers of these posts will be able to recognise how frustrated I was by the end of six months, and why I just wanted to get out and come home. But it was important to come home with something other than negative thoughts, so I spent some time reflecting about my own behaviour in the past, and what lessons I could learn to apply to future engagements. This is my list, and it is specific to quality and process management consultants

You are a Change Agent First

You are first and foremost an agent of change and if you don't understand the basics of change management, stakeholder management and relationship management go and find another job. Changing they way people do things needs their cooperation and collaboration. You need to listen to them and engage in dialog with them.

Command and Control Doesn't Work

Old fashioned command and control management doesn't work for quality and process management. People need to understand why they are expected to do certain things (which may appear to be completely worthless) and if your only explanation is "because we tell you to" they will find ways around it and everyone could suffer as a result. If you only make recommendations that add value it will help, but you still need to win hearts and minds.

Be Prepared to Admit You Are Wrong

I've often used the phrase "I'm not always right, but I'm never wrong", but only in jest (I hope). Sometimes you will come up against people who may be wiser or smarter than you, and you need to acknowledge that and let them correct you. Don't just sit there and rely on your authority; listen to what is being said and make the appropriate changes and acknowledgements.

Look Out for Learning Opportunities

Only the very arrogant think they can get by without improving themselves and learning from others. Sadly, I've met a lot of very arrogant consultants and managers. Sadly, too many younger consultants have no actual work experience other than as consultants and they are unable to accept that those who have done things (or are still doing them) have any value or anything to offer.

Don't Impose Your Standards on Others

Just because you have a tried and tested way of doing things doesn't mean it's always going to work. And that is true with individuals, teams and organisations. You cannot and must not try to impose your culture and values on others. Instead, work with them, and let them choose what is appropriate for them.

If It Isn't Working, It's Probably Wrong

When you've put a plan or a system or a mechanism or a programme in place and you aren't seeing the desired or expected results one of two things may have happened. You didn't know what to expect so you can't recognise it when it happens, or more likely, you've done something wrong and it needs changing. This is a bit of an extension to my third point but on a larger scale. It's no good persisting with something in the hope that it will improve. Learn from what's happened, change what needs to be changed, and move on. If necessary consider whether it is time for you personally to move on permanently...


I hope these six values are already engrained in my own ethos as a consultant and as a person. I'm sure I've been guilty of not following all of them in the past, and this experience has made me acutely aware of potential pitfalls in my chosen area of expertise. All experiences are learning opportunities, and this was a timely reminder of what to think about next time I set foot in someone else's organisation and before I start to tell them what they need to do!

As for you, dear reader...take a six month break from consulting, and go back and do some proper work for a change. You might just find it changes your outlook on life! And besides, why should I be the only one to suffer?!

.

8 Quality Principles that everyone should adhere to

At various times in my career to date I've held the role of Quality Manager or Quality Leader either at project, programme or organisational levels. Over the years I've developed a set of eight simple Quality Principles that are easy to understand and more importantly, easy to achieve by everyone in the organisation. In fact these aren't so much Quality Principles as common sense principles which often fly out of the window in times of stress. However, if you follow these principles, and communicate them across the team, department or enterprise you may find that some of the things that cause the problems in the first place will start to disappear. Print them out and post them on your noticeboards, issue all members of staff with a laminated copy to keep on their desks. And make sure that you follow up on them by ensuring that at the very least you yourself adhere to them whatever pressure you find yourself under.

Quality is a collective responsibility

• Everyone must be actively involved
• Your actions and what you produce reflects on all of us

Honour your commitments

• Create a realistic estimate prior to making the commitment and document your assumptions
• Don’t commit to something you know you can’t achieve
• Provide an early warning if you cannot fulfil a commitment you made

Right first time, every time

• If you don’t have time to do it right initially, when will you have time to fix it ?
• Perfection is not a contractual requirement

A second opinion is not optional

• All contractually required deliverables that you create must be reviewed by a person other than yourself
• Allow time for review and rework in your estimates

If in doubt…ask

• No question is stupid if it helps you to do your job, as well as helping others…
• …but use your common sense

If you see something wrong (or know of something better) …tell someone

• All processes can be improved
• We can’t fix things we don’t know about

Plan your meetings

• Make sure you have a clear purpose, a published agenda and the right participants
• Record critical decisions and actions in meeting minutes

Keep It Simple, Stupid (KISS)

• Life is complicated enough – don’t make it any more so