Friday, 28 August 2015

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.



Thursday, 2 July 2015

A Lean Excuse for Not Thinking

Recently a former colleague posted an article on a social media network entitled "The History and Simplicity of Lean Process Improvement". The author, Brian Hunt, suggests that elements of modern 'lean' can be traced back to ancient and mediaeval times. He then goes on to talk about modern Lean implementations and specifically Six Sigma techniques are often shoe-horned into an organisation with little thought for the people who actually do the work. Having had first hand experience of this, where both management and external consultants colluded to create a version of Lean that bore no resemblance of anything remotely approaching process improvement I couldn't help but chuckle at his example of a UK Government implementation of Lean which included marking out the required position of pens, telephones and other desk furniture for optimum productivity.

But my comment to Bianca, was more along the lines that we've a long established tradition, especially in IT, of jumping on bandwagons like Lean, Agile and a plethora of other 'methods' over the years, whilst at the same time throwing common sense and considered thought into the wayside.



Now I'm all in favour of new ideas, old ideas being regurgitated, or even incongruous ideas being thrown in the mix and muddled together to create something innovative. What I'm not in favour of is the latest fad being seen as a silver bullet to solve every problem regardless of how suitable or unsuitable it may be.

If you look at the job market for project managers these days very few of the advertised positions do not include Agile in them. For process improvement positions, a black belt in Six Sigma is pretty much a mandatory requirements, although Lean Six Sigma is preferred.

The reality is that very few organisations operate a truly agile environment (those that have adopted Scrum shouldn't even be advertising for project managers) and in fact some good old fashioned project management and good governance improvements would be a much better way to improve results than blindly deciding that 'we need to be Agile' without genuinely understanding what that means.

Similarly, organisations with a track record of failed process improvement initiatives would probably be better off looking at their organisational change management processes (or lack of them) than attempting to implement a Lean Six Sigma improvement programme (whatever that is!) and expecting it to succeed in spite of history....select your favourite maxim

  • those who fail to learn from the lessons of the past are doomed to repeat them
  • stupidity is the practice of repeatedly doing the same thing in the expectation of getting a different outcome
Unfortunately there are too many managers and leaders out there who behave like the relative who gives you green jumper every birthday because you twenty years ago said you'd like a green jumper.  They jump on ideas and inflict them on their people, because they've stopped thinking properly in the internet age. It's easier to find out about a new idea by reading an article on LinkedIn and stamp it across the business without a second thought than it is to actually work out what the problem is and determine the best approach to solve it using the most appropriate tools and techniques before then implementing the change using good change management practice.

I'm still amazed at the number of organisations that launch an improvement programme, or roll-out a new tools without actually doing any analysis of the problem, let alone putting together any requirements. And absolutely not thinking about the consequences of their actions!

The best consultants and practitioners are not the ones who pigeonhole themselves into a trending method or ideology. The most successful people are those who keep an open mind, understand how different concepts, principles, ideas and tools actually work and how to get the best from the synergies between all the ingredients in the melting pot. They won't always succeed overtime, but at least they'll have a better chance than the trend followers and the ones seeking out the next silver bullet.







Tuesday, 16 June 2015

Blueprints for Success or Recipes for Disaster?

I've seen a few articles recently about using 'blueprints' for the successful implementation of organisational change, especially in the IT industry. I rarely read beyond the title because I believe there is a fundamental problem in the concept of using a blueprint for anything other than what the original term designated, namely: 
blueprint is a reproduction of a technical drawing, documenting an architecture or an engineering design, using a contact print process on light-sensitive sheets. Introduced in the 19th century, the process allowed rapid and accurate reproduction of documents used in construction and industry.


I know there will be people out there accusing me of being pedantic and that over time the term blueprint has come to mean a template, plan or design that may or may not be reusable. But the fact is that many people will associate the concept of a blueprint as being a very detailed schematic without which certain projects will be doomed to fail. From there you might be then be forgiven in thinking, that if you have a proven blueprint, you are guaranteed success for future undertakings. You probably couldn't be further from the truth.

As a leader, it took me precisely two change initiatives to work out that blueprints don't work in that context - and in fact very rarely work in IT projects of any description, unless they are relatively simple, repeatable infrastructure projects. As soon as the level of complexity is increased, the blueprint becomes a millstone rather than an aide.

Having worked within organisational project and process improvement teams for some years, I eventually found myself responsible for setting up and managing a new team from scratch. Having built a very successful group with a global reputation, I was asked to repeat the process with a larger organisation. Over-enthused with my previous success I made the assumption that I could use the 'blueprint' and repeat what I had previously achieved. What I failed to take into account was that even a few hundred miles away, the culture within the same organisation was completely different from where I'd come from. My 'blueprint' failed and so did I. 

Except in very small companies, cultures are often very different across the business - different attitudes and sub-cultures prevail between departments, and even within the same department there may be further sub-cultures between different buildings or even different floors in the same building. When companies go across countries or continents, the differences will magnified enormously and any previously successful blueprints will be mostly worthless.

There are, however, alternatives to blueprints which can help enormously to tilt the scales of change in favour of success. Using a change management framework, either homegrown or from external sources is a necessity not an option (yet many large organisations still fail to understand this and wing it with all their change programmes). Integrating good project management practice into your change process will help enormously. 

The greatest chance of succeeding with change initiatives is to make use of the expertise in your organisation that is hidden in plain sight - the people who do the day to day work, not managers and consultants who have their own agendas. Involving people from the outset will help prevent you from making dumb decisions, from disenfranchising the work force, and for misunderstanding or misinterpreting the organisation's ability and desire to handle specific changes. 

Blueprints are fine if all the materials and conditions and constraints defined within those blueprints are available or can be met as specified. If they aren't, then the blueprint is probably no longer valid and needs to be modified. 

A half decent cook will be able to follow a recipe and adjust things as they go along to allow for deviations in ingredients, number of diners, time available and a myriad of other variables. If you are leading change initiatives you need to follow the same principles. It won't take long to find out that it's the recipes that help you succeed and the blueprints will guarantee your failure!





Monday, 15 June 2015

Standard Disillusionment

I've been getting increasingly disillusioned with standards and certifications as I've grown more experienced, older and wiser. And it's not always the standards themselves, though increasingly that is also the case. It's the bodies that own and curate the standards, the organisations that administer them and the people who act as judge, jury and executioner for all things related to a standard.



I used to think that standards were useful. There are probably some standards which still are useful. These are the ones regarding industry specific rules and regulations which are designed to benefit people's safety and well-being. But generic quality standards appear to be being continually dumbed to such an extent that they are becoming increasingly meaningless and irrelevant.

ISO 9001 in particular has had a chequered history. When I first started using it many people were of the opinion that it didn't matter how you interpreted it. As long as you did was you said you were going to do - even if it was plainly wrong - you could gain your ISO 9001 certification and be a 'quality organisation'.  The 2000 release did much to regain faith in the standard, but the forthcoming release appears to be propelling it back into the dark ages.

Much of the current problem with today's 'standards industry' is just that - it has become an industry in its own right and responsible bodies are milking their consumers for every penny they can get. For example it will cost you $79 (about £50) to purchase the 56 page draft version of ISO9001:2015 which isn't due to be finalised until the end of the year.

The key word with a generic standard is interpretation. I've suggested on more than one occasion that quality people fall into one of two camps - those who focus on compliance and telling people what to do (not necessarily ever having done it themselves) and those who understand that the world isn't black and white but made up of many shades of grey and a multitude of other colours, tints and hues. These are the people who have actually done the job, look for pragmatism over compliance and add genuine value to the people they support. They have no need to hide behind rigid interpretations of standards because they understand that different situations require different interpretations and approaches. You only have to look at some of the LinkedIn quality forums to see this for yourself!

When I'm in the role as a quality manager this disillusion with standards can be seen as both a curse and benefit. As a standard becomes more woolly and vacuous it does allow more scope for interpretation which enables me to promote some of my personal business agendas - like reducing organisational tendency to focus on things that really benefit no-one (not even the people pushing them!). At the same time, I have to be careful about voicing my dissatisfaction which could be seized on by the anti-process brigade as an excuse not to adhere to any process - even the good ones.

I'd like to think that the worm will turn - but I'm not going to hold my breath. We seem to go from one extreme to the other. The draft ISO 9001:2015 standard as stated previously runs to 56 pages and gives little guidance regarding interpretation. The ITIL version 3 framework (we can argue another time over whether this is a genuine standard) now runs to just under 2000 pages and costs over £250 - but is summarised in 300 pages for a tenner (as in the ITIL Foundation Handbook) and far less in some of the pocket guides. Much of the rest is simply padding. I wonder if the authors thought that they needed to create hundred of pages of documentation simply to justify the cost.

Standards need to be precise enough to be of value. They need to be affordable enough to find global acceptance, not just in big corporations but in small, one person businesses, and the cost of applying useful and relevant standards needs to be clear and transparent to the business owner.

I've recently worked in a number of major corporations in financial and pharmaceutical domains where they see no need for ISO 9001 amidst the other regulatory standards they have to adhere to - and it believe this trend will increase unless the people writing, publishing and administering the standards begin to get their acts together and start thinking of their customers and the folk who have to implement standards in their own organisations.