![]()
1
Introduction
The old adage âif a jobâs worth doing, itâs worth doing wellâ admirably demonstrates the difference between having quality and not having quality. âHow well does the job need to be done?â is a question that might be asked at the start of any project, since the amount of quality required is a direct consequence of the answer.
Quality is a perception, however. It can mean one thing to one person and something else to another. For this reason it is often difficult to reach a natural consensus on the meaning of quality, so it is hardly surprising that in projects where quality is not given specific attention the final deliverables may be less than expected.
So, what exactly is quality? In everyday life, we do not always need to have an exact definition of quality. It can, for many purposes, remain vague. It is a word used liberally. People speak of âquality timeâ in terms of time away from work. I received a travel brochure the other day advertising âquality breaksâ; but what does it really mean? There were no qualifying adjectives: the brochure did not say âgood quality breaksâ or even âpoor quality breaksâ, though we assume it implies the former.
As a word, quality is indefinite, yet it is often used in everyday language as a qualifier to denote something higher in status, luxury, excellence or perfection. Manufacturers frequently extol a âquality productâ, persons of high standing in society have often been referred to as being âpersons of qualityâ and workmanship may be spoken of as being of high or low quality.
In terms of luxury, we often talk of a âquality carâ, meaning a car that has a higher specification than the basic model and a more luxurious finish. The basic model, however, can also be a quality car if it meets the requirements of the person desiring it, i.e., it is fit for purpose.
For projects and programmes, however, quality needs to be defined. Put simply, if it cannot be defined, it cannot be managed. This is why the definition of quality is such an important early task for projects and why Chapter 2, Quality definition, gives it particular focus.
In business terms, quality is generally defined to mean âfitness for purposeâ. For projects, this basically means âmeeting requirementsâ. If someone comments âThis is a quality piece of workâ then that person usually means that the work has been done well. This comment on excellence may also relate to expectations. âI was expecting you to fit only the radiator, but I see that you have also made good the surrounding plasterâ is a comment demonstrating how expectations may be exceeded. Is this latter âfit for purposeâ, however? Yes, if the requirement is not compromised by the additional work; no, if the additional work took longer or cost more and the customer had not budgeted for this.
This demonstrates that client requirements should never be taken for granted. Even the most obvious expectations need to be clarified. The Millennium footbridge across the River Thames in London had to be closed for several months not long after its grand opening because pedestrians crossing the bridge caused it to wobble alarmingly. For a busy river crossing in a capital city, a requirement not to wobble would seem obvious. However, when embarking on projects and programmes it is often best to state the tolerances required for even the obvious. Assume nothing and there can be no arguments later.
There are few hard and fast rules for managing quality in projects. All the methodologies state it should be managed, but good, practical guidance is often lacking. Experience shows that it is certainly worth managing, however, since besides quality being a visual result of the end product, it is also an enabler. It contributes to how a project is managed, how resources are marshalled, how time is scheduled, how costs are controlled and how expectations are set and achieved. This is why projects should not ignore it, and not just because it may be seemingly difficult to grasp as a concept or manage as a practical undertaking.
Quality is not confined to a particular project stage. Like risk management it is all pervasive. It appears in every work package and every action. It is not a function that makes one stop and say: âToday I am going to tackle qualityâ. Rather it causes one to think âAm I tackling this piece of work in the right way? Does it meet or exceed expectations?â Quality should, therefore, be part of a project teamâs mindset.
There are, of course, discrete stages of a project where quality is more obviously exposed, such as product testing. Here it is possible to switch on particular quality procedures to check that deliverables are attaining the desired level of quality. Apart from these instances, however, quality, in terms of process, must be the retention of a mental checklist, continually applied to every action, by every member of the project team.
Risks of not having quality
Why do so many projects not manage quality? One reason, I believe, is that many find it difficult to sell the benefit of managing quality, and to justify managing it in terms of effort and cost. This is probably truer of softer business projects, where fixing the quality of deliverables is less tangible than, say, the construction of a bridge.
Often the best justification is to list the risks of not having quality. History is full of projects that failed through poor quality. However, the risks to a project of not having quality are usually not immediate in effect, a fact that is regularly used as an excuse for not needing to promote quality in the first place.
The long-term effects of not having quality, however, are particularly far reaching. This can frequently result in an often open-ended increase in time and cost. For example, the initial cost saving of, say ÂŁ15,000, on not producing a user manual to a set level of quality, can result in a much larger ongoing cost over an indefinite period, in terms of wasted effort, negative productivity, dis-enchanted users and increased calls to the support desk. A direct cost of having disenchanted users is a delay in the provision of benefits.
Cost and time, therefore, appear strongly in any compilation of the long-term effects of not having quality, and consistently manifest themselves as:
-
increasing the time in which benefits can accrue
users take longer to learn the product, longer to become productive in using it and, therefore, longer to become innovative and creative through its use
-
increased costs through âfire-fightingâ
a reaction to unplanned workload through the sudden and costly need to provide additional resources, in terms of fixing problems and providing additional training, documentation and support
-
increased time and costs through inefficiency
poorly planned processes, which cause delays, errors, etc.
Therefore, a risk of not having quality frequently relates to the end users. There are many developed products that become redundant in the eyes of users almost as soon as they are installed. The failure is not necessarily through the technology of the product itself but through a lack of understanding of the rapidly changing requirements of the users. Fashion is a key consideration of lifespan amongst product consumers.
The usersâ perception of what will be delivered is a good indicator of how well any marketing exercise has been carried out throughout the life of the project. The end product should at least match expectations in terms of meeting usersâ requirements. It should be usable and work as they expect it to work. If theyâve been told nothing, their expectations will be set by rumour and the âgrapevineâ, often to negative effect.
A project that embraces quality focusses strongly on the users themselves: their needs, their expectations, their acceptance and productive use of the product and fashionable tastes. Such a project also considers the full range of stakeholders, many of whom will not be users, but may be sponsors, sellers, manufacturers, investors, etc. A properly scoped and executed Communication Plan is, therefore, a vital component for ensuring the right level of expectations of quality.
Justifying quality for projects
A key difficulty that often arises for project teams is maintaining quality under pressure. Even though a project business case may have set out good reasons for attaining a certain level of quality, there will be occasions when a project team will be under pressure to curtail aspects of quality in order to meet specific deadlines. This is fine, if the curtailing is done formally through change control, but not if unapproved operational shortcuts are made. The continual maintenance of quality is, therefore, important during a projectâs lifespan. This is why the role of Quality Manager, or similar, is an essential role for any project where quality will play a significant part.
The link from quality to change control should always be strong. I often find that projects without good change control also exhibit poor quality. Poor change control usually results in scope creep, which is a major cause of project delay and cost overrun. Therefore, good change control is itself a quality function. The risks of not having it are legion.
The link between quality and risk management is equally strong. In fact, a good risk register will include risks associated with the...
