Managing for Better Quality
There is a high visibility and aural version of this page
(to listen, you will require an aural browser or screen reader).
What is Quality Management?
Increasingly, software users look for suppliers whom they can rely on. They want consistent delivery of products and services that do what they need and expect. This is because business is becoming more and more dependent on software.
Quality Management is the branch of management that gives that assurance. It can:
- win your company a competitive advantage, by building a name for high quality products and services;
- help you avoid project failures and reduce the cost of bug-fixing; and
- enable you to gain the ISO 9001/TickIT or other certificate that customers ask for.
Good Quality Management has to be based on a system. This ensures consistent and reliable results. It also takes care of much humdrum detail, so your people can apply their innovative skills, imagination and flair to creative work.
The following notes give a brief general account of Quality Management Systems (also known as Quality Systems or QMSs). For a discussion of how this relates to software, see Quality Management in Software Projects.
Some Features of a Quality Management System
Customer Focus
"Listen to what your customers are telling you about Quality" [9].
Example: A company receives a lot of complaints about problems that users are having with a new product. The company is proud of the software; it was well designed, carefully coded and thoroughly tested. But the customers find it hard to install because the set-up guide is lacking.
This company should pay attention to its customers. Of course, they want good software, and the company is quite right to follow the best development practice. But the software is not the whole product, or the only bit that matters. To a user, the documentation is just as vital.
Quality Manager
You will very likely have someone who makes quality their special concern. It may be a part-time job.
This person should act as an advisor, coach, evangelist and monitor. Their role is to help the people who make the product, or provide the service, to achieve good quality in their own work.
Quality Manual
If you are going for ISO 9000, you must have a Quality Manual. This describes your system in terms of standard quality concepts. Quality auditors and other outsiders will use it as their starting point.
Procedures
A procedure is something that people do. Often, it need not be written down, depending on your style of organisation. A written procedure is no use unless it is followed in practice.
We define procedures to ensure that routine work is done in a standard way; that different departments can work together and understand each other; and that people need not waste time thinking up new ways to do mundane tasks. They do not give rules for everything; initiative and judgment still count.
Engineering procedures can rely on engineers' professional skill, shared understanding gained by working in teams, and examples of good and bad past projects.
Management procedures define how the work flows through your development or service process, what quality activities you do at each stage, and what records you keep.
Bringing a procedure into use involves a lot of persuasion, listening to feedback and revision in the light of what you hear. If no-one complains, they are probably not using it!
Records
Record keeping is an essential chore. But systems can be designed to ease the burden. Records can also turn out to be useful, even for people - such as many engineers - who do not like keeping them.
Example: A software release procedure might require engineers to fill in a form with details of the software being issued. After early grumbles, they may find it useful to refer back to the details of past releases.
People
Software, more than most types of work, depends on the skill and professionalism of your people.
Trying to manage through rigid rules, that govern everything people do, will not work. Software is too complex, projects often one-off, and unexpected events too common for this.
Example: Companies sometimes have a rule that coding must not start until the detailed software design has been approved by a senior manager. But, often, managers are out of the office when a design needs approval.
It is better to rely on your people to make their own judgments and take responsibility for them. In the example, the manager's approval is quite likely based on the report of a technical review. Why not let the review leader give the approval?
Management
Senior managers make the organisation's policy and set its tone. They must ensure there is a defined quality system.
Managers lead by example, mainly through the decisions they make. They need to give a consistent message.
Example: The Managing Director authorises a pre-release of an incompletely tested product, at the request of the customer. But the company's quality policy says that software must be fully tested before release. Staff see the pre-release as going against this.
You need to make sure that staff understand the reasons for this decision. Quite possibly it can be justified on quality grounds - see Customer Focus - though there are some hard questions to be asked. But you need to explain this to staff.
When things go wrong
Inevitably, things go badly wrong from time to time - no Quality System is perfect. We need to correct them, but also to learn from the mistakes.
Example: Consider again the example under Customer Focus. Here, the company first needs to fix the immediate problem by writing a set-up guide. But the important thing is to put the process right, so that the necessary documentation is produced for every product. Otherwise the problem is bound to recur.
This approach, of analysing and correcting the root causes of quality failures, is one of the main ways in which we can improve quality. For further discussion, see How Software Projects Go Wrong.
Performance Improvement
You need not wait for things to go wrong before taking steps to improve quality. You can measure the quality of the company's products, and how effective its processes are, at any time.
You should collect and analyse such data in a systematic way. The programme needs well-defined goals, rather than amassing huge amounts of data at random.
Setting Up the System
Where Are We Now?
First, to decide on the best approach, you should assess your current system:
- If it has most of the features described, you are probably well on top of Quality. You may wish to look at the pages: How Software Projects Go Wrong; Quality Management System Standards; and The Quality Audit, for further ideas on how to improve it.
- If you are not sure how well it measures up, you could review it against one of the standards described in Quality Management System Standards, or get a consultant to review it for you. Then you will be able to decide how best to move forward.
- If it is not much like what we have described, there is work to do! The key is to do a bit at a time. Aim to sort out one area thoroughly, and get your solution working and delivering real benefits, before you tackle another.
Getting Started
Next, you will need access to knowledge and skills in Quality Management, Software and how they fit together.
One way is to teach yourself. This is excellent, but takes time. These pages, with some of the works cited in the Bibliography, may give you a start.
Another is to employ an in-house expert. The risk is that they could then be the only person who knows how the system works. You need to ensure this knowledge is shared.
You could also engage a consultant. You should adopt one of the above two approaches as well, because consultancy is no substitute for in-house expertise; but it can help you get up to speed more quickly.
Management