In the past couple of posts I've tried to set out my stall and ask the question about how organisations can get the best out of their quality departments. It's a double sided question, because it's primarily aimed at quality staff, namely how can you add value to the organisation through your activities?
My overriding observation about quality teams that I've worked with over the years is that they tend to be rather one dimensional. Their focus is often to 'audit' projects and teams and they carry out this task with demonic resolve like ferrets in a rabbit warren. The audit schedule is defined at the start of the year so that all projects get audited at least once, preferably at different stages of the lifecycle. The auditors then spend their time trying to get access to the project teams, being rebuffed by the project manager at every possible opportunity because of delivery priorities. When they finally get into the project, they run through their quality checklists, ticking and crossing the boxes and passing a verdict on the way the project has complied to the quality management standards in play. The quality manager logs the findings and creates a pile of powerpoint slides which are presented to senior management at the end of the month. The management team asks some polite, semi-probing questions and accepts the answers provided, agrees some actions and the cycle continues. This kind of activity is in keeping with the spirit of the old 1984 ISO9000 standard but it does little in terms of adding value to the organisation and nothing to enhance the reputation and standing of the quality team. Organisations and quality teams need to radically move away from this Dilbert-like approach to quality, and the battle lines between quality staff and project teams must be broken up.
So what to do?
1. Take the Initiative - It's vital that quality teams take the initiative and start to adopt a more collaborative approach to quality by working with project teams and management to establish what is really important to them. Doing things the way you've always done them doesn't make them right or useful in a modern environment. Engage with your quality lead and offer suggestions on how you can make your activities more valuable
2. Become more generalised - I've worked with many quality staff who have no first hand experience of the domain in which they operate. They audit programmer and project managers but have never been either. I remember being at a European quality meeting some years ago where I was the only person in the room who had any management experience. Without first hand understanding of the problems faced by the people you are dealing with you cannot realistically expect them to take you or your suggestions seriously. Quality staff need to stop thinking of themselves as purely quality staff and get stronger exposure to the roles and functions they audit
3. End the Checklist Mentality - The best auditors use a checklist to guide them and help them remember key areas for investigation. If they find a particular area of concern during the audit they will throw away the checklist and pursue that matter more rigourously. (In order to do this, they have already followed step 2 above!). Ticking boxes is fine for a pure compliance audit but this type of audit does little to help improve an organisation, rather it serves as a stick to berate delinquent areas of the organisation
4. Proffer Solutions - I've seen so many audit reports which highlight deficiencies and non-conformances but do nothing to help the subject of the audit to understand or fix the problem. In the case of some non-conformances, it makes little sense to fix them anyway, because the moment has passed, or the cost may be too high in terms of the return. Auditors will be taken far more seriously if they can offer explanations as to why something is a non-conformance, and more crucially why a non-conformance may cause a problem later on in the lifecycle, in which case they should be able to proffer a solution, or better still, help the subject derive their own solution. In this way the auditor becomes more of a coach and a collaborator and less of a witch hunter
Many quality staff and auditors are hard working and passionate individuals who are prevented from achieving greater things because the system itself is broken, and quality is seen as a necessary evil rather than a value add activity. This piece is not intended as a criticism of those individuals, but as a challenge to those who have the power to make things better. So it is a challenge to everyone who works in the quality field and everyone else who doesn't think they do. Next time I'll focus on management responsibilities and the challenges they need to rise to.
Monday, January 11, 2010
Friday, December 18, 2009
Getting Value from the Quality Department (Part 2)
In this post I want to discuss the problem about Quality terminology and how it is chronically abused in the IT industry and in software development in particular. Somehow in software development, the term quality is now generally taken to mean testing, and worse still it is often limited to testing after the event. In other words, once the code has been written and integrated, a group of people run a batch of test scripts using an automated tool and look for problems. Without wanting to belittle the role of the testing team, this is not quality or quality assurance. This is testing, and it is a part of the software development lifecycle just like analysis, design and build phases. Any book on Software Engineering will explain this. Nowhere is it written that quality equals testing. You don't test for quality, you build quality into the system and you build an organisation based on quality principles. Once you move away from those central tenets you may as well pack up and go home.
But look through the job adverts on any recruitment page and you will find positions such as Quality Engineer, Quality Assurance Manager, and in ninety percent of cases the associated job description talks about testing; developing test scripts, using testing tools, and more often than not having ISEB qualifications. At my girlfriend's place of work they even run testing bootcamps for graduates, which turn non-IT graduates into certified testers in four weeks. In my opinion, any organisation that works in such a fashion is certifiable itself.
If you read the ISO 9000 set of standards, which despite its faults, is still a reasonable place to start in a discussion about quality, you'll read about Quality Management which incorporates Planning, Control, Assurance, and Improvement. You really have to dig quite deep into the standards before you get to any serious mention of testing, and by that time you should have worked out that it is one of set of tools available to an organisation, along with reviews, audits, inspections, and other verification and validation methods.
Which brings me onto the subject of audits. I've worked in a number of organisations where the quality team only performs audits. Armed with nothing more than a checklist and set of pre-prepared questions, the person doing the audit goes into the project and runs through the questions, ticking the boxes. I use the phrase 'person doing the audit' advisedly. These are not necessarily trained auditors. Even those that are, often appear to have little understanding of the domain, whether it is project management or even software development. Often the people assigned to the quality team are those with least experience of anything - it used to be common practice to place graduates and new starts into the quality team to keep them out of the way. Nowadays the quality team simply doesn't exist because it's just been made redundant to save costs.
The point is that audits performed by people without the necessary training, understanding and experience of the problem domain cannot add value to the process. We'll cover this in more depth in a future post but an organisation that relies on this type of audit, to identify problems after the event is unlikely to add any value to the organisation, and by that account, sets itself up to fail. A Quality Manager in this position deserves to be looking for a new role.
At the heart of these issues is the failure of the organisation to really address what it is trying to achieve. If the organisation sets itself objectives it needs to consider how to achieve those objectives, and it's very rare for one activity to work in isolation. Different methods and techniques (and tools where appropriate) need to be considered, and each needs to be evaluated from a value and cost benefit perspective. This is where the Planning element of Quality Management fits it. It's not enough to create a Test Plan or an Audit Schedule. A Quality Plan needs to align to organisational/programme/project objectives and customer requirements and it needs thought and expertise.
My challenge to today's quality teams is to put themselves back in the forefront of organisational operations and be counted as people who make a real difference by adding extraordinary value to the organisation and not restrict themselves to one dimensional entities who only do one thing, and don't even do that very well.
But look through the job adverts on any recruitment page and you will find positions such as Quality Engineer, Quality Assurance Manager, and in ninety percent of cases the associated job description talks about testing; developing test scripts, using testing tools, and more often than not having ISEB qualifications. At my girlfriend's place of work they even run testing bootcamps for graduates, which turn non-IT graduates into certified testers in four weeks. In my opinion, any organisation that works in such a fashion is certifiable itself.
If you read the ISO 9000 set of standards, which despite its faults, is still a reasonable place to start in a discussion about quality, you'll read about Quality Management which incorporates Planning, Control, Assurance, and Improvement. You really have to dig quite deep into the standards before you get to any serious mention of testing, and by that time you should have worked out that it is one of set of tools available to an organisation, along with reviews, audits, inspections, and other verification and validation methods.
Which brings me onto the subject of audits. I've worked in a number of organisations where the quality team only performs audits. Armed with nothing more than a checklist and set of pre-prepared questions, the person doing the audit goes into the project and runs through the questions, ticking the boxes. I use the phrase 'person doing the audit' advisedly. These are not necessarily trained auditors. Even those that are, often appear to have little understanding of the domain, whether it is project management or even software development. Often the people assigned to the quality team are those with least experience of anything - it used to be common practice to place graduates and new starts into the quality team to keep them out of the way. Nowadays the quality team simply doesn't exist because it's just been made redundant to save costs.
The point is that audits performed by people without the necessary training, understanding and experience of the problem domain cannot add value to the process. We'll cover this in more depth in a future post but an organisation that relies on this type of audit, to identify problems after the event is unlikely to add any value to the organisation, and by that account, sets itself up to fail. A Quality Manager in this position deserves to be looking for a new role.
At the heart of these issues is the failure of the organisation to really address what it is trying to achieve. If the organisation sets itself objectives it needs to consider how to achieve those objectives, and it's very rare for one activity to work in isolation. Different methods and techniques (and tools where appropriate) need to be considered, and each needs to be evaluated from a value and cost benefit perspective. This is where the Planning element of Quality Management fits it. It's not enough to create a Test Plan or an Audit Schedule. A Quality Plan needs to align to organisational/programme/project objectives and customer requirements and it needs thought and expertise.
My challenge to today's quality teams is to put themselves back in the forefront of organisational operations and be counted as people who make a real difference by adding extraordinary value to the organisation and not restrict themselves to one dimensional entities who only do one thing, and don't even do that very well.
Thursday, December 17, 2009
Getting Value from the Quality Department (Part 1)
It's a been a while since my last entry on this blog but I've been doing a lot of thinking in the meantime and I keep coming back to one of my favourite subjects which is the role of the Quality team in a typical software development environment, both in terms of what they think they are supposed to do and what they should actually be doing. Over the next few entries I want to have a look at the problems I encounter in quality teams and organisations and what to do about them. I'm likely to get a bit sidetracked onto some connected bugbears so I'll beg forgiveness in advance and hope that it doesn't put you off reading!
I was introduced to the organisational concept of "Quality" quite late in my career. None of the first four organisations that I worked for had any documented processes or standards other than the Employee Handbook which was almost all HR oriented. One company took a tentative step towards ISO 9000 back in the mid-1990's, and even went as far as hiring a quality manager. They made him redundant after a few weeks when he told them how much it would cost them to get their ISO certification. Later, I took on the role of "quality person" in my immediate department, and that's pretty much where everything else in my career started. I introduced a few things like code inspections, facilitated JAD sessions, and coding and documentation standards which were tolerated by the majority of our developers, and appeared to generate some improvements. Bearing in mind that my brief was pretty much "develop and implement some stuff to make us better" I'd like to think that I was quite successful. My only qualification for being given the role was "you're the only one who could actually give a fig".
About this time, we elected to change our development model from 'none' to Objected Oriented Development and Rapid Application Development using DSDM (Dynamic Systems Development Method). We engaged a consultant, Paul Allen who worked for Select Software at that time. As the person responsible for the implementation I worked closely with Paul and he taught me a lot about processes and process improvement. Our pilot project failed dramatically for various reasons, and I left the company before they threw me out, as it was quite clear that my final job title was going to be scapegoat.
I learnt a lot from that experience, but when I started my new job as a process improvement specialist in 1998 for a large global outsourcing company on a major British manufacturing account it quickly became clear that I was now in a different league. Quality wasn't just a buzzword; it was taken SERIOUSLY. Getting SW-CMM Level 2 was a priority objective and goal, along with maintaining ISO9000 certification.
Since then, my own role grew in size, influence and diversity so I got to see things in many different parts of the organisation. I later moved into consultancy and saw things from the outside looking in, rather than purely inwardly focused. And a dozen years later I have rather a different view and a much better understanding of the reality of Quality in the enterprise. Very few of the quality and process improvement people I used to work with still have jobs with that corporation. Much of the cash spent on improvement initiatives has largely been flushed down the pan and the company has little to show for it. A few groups have been successfully been steered through CMMI L2 and L3 assessments, but regular reorganisations tend to dilute even that achievement - not to mention the loss of tens of thousands of developers and other staff. Quality is a necessary evil that has to be tolerated rather than embraced. It rarely appears on meeting or review agendas any more, and the higher in the organisation you go, the less likely the chance of it being mentioned. I've seen exactly the same happen at other companies, small and large, so this isn't an isolated case.
So where did it all go wrong and how can we get back on track to where we really ought to be after years of investment, research and more failure than success? Over the next few entries I'll look at Quality Perceptions, Management Responsibility, the Audit Process, Quality Metrics, and Quality People, and examine the issues and provide some ideas on resolution.
I was introduced to the organisational concept of "Quality" quite late in my career. None of the first four organisations that I worked for had any documented processes or standards other than the Employee Handbook which was almost all HR oriented. One company took a tentative step towards ISO 9000 back in the mid-1990's, and even went as far as hiring a quality manager. They made him redundant after a few weeks when he told them how much it would cost them to get their ISO certification. Later, I took on the role of "quality person" in my immediate department, and that's pretty much where everything else in my career started. I introduced a few things like code inspections, facilitated JAD sessions, and coding and documentation standards which were tolerated by the majority of our developers, and appeared to generate some improvements. Bearing in mind that my brief was pretty much "develop and implement some stuff to make us better" I'd like to think that I was quite successful. My only qualification for being given the role was "you're the only one who could actually give a fig".
About this time, we elected to change our development model from 'none' to Objected Oriented Development and Rapid Application Development using DSDM (Dynamic Systems Development Method). We engaged a consultant, Paul Allen who worked for Select Software at that time. As the person responsible for the implementation I worked closely with Paul and he taught me a lot about processes and process improvement. Our pilot project failed dramatically for various reasons, and I left the company before they threw me out, as it was quite clear that my final job title was going to be scapegoat.
I learnt a lot from that experience, but when I started my new job as a process improvement specialist in 1998 for a large global outsourcing company on a major British manufacturing account it quickly became clear that I was now in a different league. Quality wasn't just a buzzword; it was taken SERIOUSLY. Getting SW-CMM Level 2 was a priority objective and goal, along with maintaining ISO9000 certification.
Since then, my own role grew in size, influence and diversity so I got to see things in many different parts of the organisation. I later moved into consultancy and saw things from the outside looking in, rather than purely inwardly focused. And a dozen years later I have rather a different view and a much better understanding of the reality of Quality in the enterprise. Very few of the quality and process improvement people I used to work with still have jobs with that corporation. Much of the cash spent on improvement initiatives has largely been flushed down the pan and the company has little to show for it. A few groups have been successfully been steered through CMMI L2 and L3 assessments, but regular reorganisations tend to dilute even that achievement - not to mention the loss of tens of thousands of developers and other staff. Quality is a necessary evil that has to be tolerated rather than embraced. It rarely appears on meeting or review agendas any more, and the higher in the organisation you go, the less likely the chance of it being mentioned. I've seen exactly the same happen at other companies, small and large, so this isn't an isolated case.
So where did it all go wrong and how can we get back on track to where we really ought to be after years of investment, research and more failure than success? Over the next few entries I'll look at Quality Perceptions, Management Responsibility, the Audit Process, Quality Metrics, and Quality People, and examine the issues and provide some ideas on resolution.
Thursday, October 22, 2009
5 Facets of Change - Update
I've now made the changes to the 5 Facets of Change tool and this entry provides a quick summary of the modifications. I felt this was better than repeating much of the previous material.
I've created a Quicktime movie of an Apple Keynote presentation which contains all the details, and this can be downloaded from my website.
The central topic is now called Define the Change, and the five facets which support this are:
The other key change is that the Changeability sub-heading is now part of Manage the Change rather than a part of the central theme. This is in keeping with the idea that any feasibility study needs to be part of the Start-up phase of the initiative. Otherwise the words in the previous blog entry still apply.
Clearly there is overlap between the different facets in terms of who, what, when and how, and different projects will have different emphasis in each of the areas. However, any change programme needs to consider all of these facets, and failure to do so will almost certainly lead to problems.
I hope this is useful - let me know if you're able to use it or if you have improvement suggestions. I'm planning to create a toolkit to support the 5 Facets which will include templates, checklists and other supporting materials to assist change managers and change teams. Watch out for more news.
I've created a Quicktime movie of an Apple Keynote presentation which contains all the details, and this can be downloaded from my website.
The central topic is now called Define the Change, and the five facets which support this are:
- Lead the Change
- Communicate the Change
- Manage the Change
- Deal with the Change
- Relate to the Change
The other key change is that the Changeability sub-heading is now part of Manage the Change rather than a part of the central theme. This is in keeping with the idea that any feasibility study needs to be part of the Start-up phase of the initiative. Otherwise the words in the previous blog entry still apply.
Clearly there is overlap between the different facets in terms of who, what, when and how, and different projects will have different emphasis in each of the areas. However, any change programme needs to consider all of these facets, and failure to do so will almost certainly lead to problems.
I hope this is useful - let me know if you're able to use it or if you have improvement suggestions. I'm planning to create a toolkit to support the 5 Facets which will include templates, checklists and other supporting materials to assist change managers and change teams. Watch out for more news.
Subscribe to:
Posts (Atom)
Posts
