Delivering Superior Quality on a Project

Introduction

Mention the word 'quality' to some project managers and you'll hear an audible groan. The term comes loaded with connotations of gold plated solutions, unrealistic customer expectations and misdirected effort.

Project managers understandably respond to the pressure to deliver on time and somewhere close to budget. Quality can often end up as the poor relation to these two very obvious measures of success.

However, once the project team has packed up and an organization has to live with the fruit of its labors, what usually matters most? For the majority of projects, we believe that the quality of delivery is by far the most important dimension.

Imagine you're running a project to build a house and direct most of your attention to timescales and costs. It's unlikely that your customer will say, 'The roof leaks and the foundations are suspect, but the house was finished when you said it would be and you came in on budget. Good job!' However, if quality plays an important part in your plans, the client might say , 'OK, you kept me waiting for two months and it cost me a bit more than I expected, but the house is just what I wanted. For a builder, you've done a pretty good job!' In our experience, the euphoria of an on-time and on-budget delivery is very short-lived if the results are substandard.

You might have heard folks talk about the 'cost of quality'.

However, we think it's more a case of the 'cost of no quality'. You probably know of a piece of work that was carried out as a rushed job to meet some critical deadline, which then turned out to be not so critical when all kinds of problems were found. No doubt considerable time and expense were then expended putting things right. This kind of experience illustrates why compromising on quality is usually counterproductive. Far from being an unnecessary overhead, chasing quality will keep you on track to hand over a solution that delivers lasting customer satisfaction.

==

You know quality is poor when…

_ The person responsible for quality on your project was given that role because they didn't seem capable of doing anything else.

_ You rely entirely on an external 'quality team' to make sure what you deliver is up to the job.

_ Quality checks are put on the 'only do if time left' list - behind organizing the end-of-project party.

==

What does quality mean? The term quality means many things to many people. Sometimes it's used in the 'gold-plated' sense we referred to in the opening of this chapter. However, for a project we apply a more pragmatic definition: meeting expectations and requirements.

Plumbing in the hotel industry provides us with a neat way of illustrating this slant on quality! Say we have the job of supplying taps to one of the finest hotels in the world, which is seeking to attract customers who are used to the finest things in life. The specification for the taps would include practical things like the ability to turn on and off, and long-term reliability. Being a very upmarket hotel, gold plating or some other sign of opulence would also be essential. Now imagine that we're supplying taps to a budget chain of hotels. The ability to turn on and off, and reliability, would still be relevant requirements - but the requirement for any luxurious embellishment would be an expensive frivolity.

So, in our world, quality hinges on what extent something is fit for the purpose for which it is intended - not that it has any special worth or extra degree of refinement. In fact, by our definition, both over-engineered and under-engineered solutions are poor quality. Ultimately this requires a good understanding of what the customer needs, not just what the customer wants.

++

Quality is all about delivering something that's fit for the purpose for which it's intended.

++

Agreeing what's fit-for-purpose The biggest problem with the pursuit of quality is in making it a tangible, measurable concept. After all, how can you be expected to deliver quality if it's specified in vague terms? Delivering something that's of good quality or appropriate quality is as difficult as clapping with one hand.

We know from experience that it can be difficult to reach agreement as to what fit-for-purpose really means. This is because a project manager may well disagree with the customer's view of what's essential. This isn't to say you shouldn't be prepared to debate the necessity of their requirements, but you must remember that ultimately it's the customer's final decision as to how fitness for purpose is specified.

Getting a clear and reliable definition of what constitutes fit-for purpose on your project is crucial for its success. We therefore want to take a closer look at exactly what we mean by fit-for-purpose in the project context. Much hinges on reaching a reasonable agreement with your customer about the essence of what is needed.

==

PM Wisdom: Poor quality leaves behind a bitter taste that lingers longer than the warm glow generated by achieving a tight deadline or a cheap price.

==

Fit-for-purpose baseline Put simply, your objective is to deliver your project with your customers accepting that what you've supplied is fit for its intended purpose. To achieve this you'll need to agree a specific set of deliverables before you start work. This needs to be more than just a simple list and should be a rich description of all of the important features.

It's usually difficult to establish the fine detail of what's required for a project - especially in the early stages. Your first attempts to nail down what the customer wants are likely to be sprinkled with extra features that can't be accurately claimed as essential. Your role is to help your customers to sort out the genuinely mandatory (the must haves) from the really important and nice-to-haves.

A useful technique for steering your customers through this discussion is to introduce some kind of prioritization. You can then let your customers list everything, even the bells and whistles, as long as they attach their rating of how essential each item is. The next step is to work with them to agree which are absolutely essential for the project to meet its objectives.

Reaching a perfect agreement isn't a reasonable expectation: it's not necessary either. As long as the specification isn't inundated with superfluous extras, there's no problem with accepting a few extra treats. It's far better to let a couple of extra features creep in - even if you're convinced they're not entirely necessary - as long as the bulk of the requirements are pitched correctly. After all, in the end it's your customers' call as to what's deemed essential and what's not.

The resulting mandatory requirements equip you with a minimum fit-for-purpose baseline. As a brilliant project manager, you'll want to deliver considerably more than this.

- - -

Fit-for-purpose baseline top tips

_ Ensure the people who agree the quality baseline are also involved in the project sign-off. This will achieve a consistent view on what's fit for-purpose.

_ The definition of a mandatory requirement is that if it's not met, the whole delivery has to be rejected. Use this acid test to encourage your customers to be reasonable about what's listed as essential.

_ Agree the relative priority of optional add-ons. Treats aren't of equal importance and you may have to sacrifice some in favor of others.

_ Help your customers to understand the cost of items that are of marginal benefit. Encourage them to consider dropping anything that's poor value.

_ Anything included in the fit-for-purpose baseline is non-negotiable. If time or cost pressures become acute, some treats will have to be dropped.

- - -

Negotiating around quality

One of the biggest problems you'll face is an inflated set of mandatory requirements - in fact this happens on nearly every project. It's not unknown for everything to become essential. This distorts the definition of what fit-for-purpose means, and increases costs and timescales. It also removes scope for maneuver if times get tough, because too many treats are seen as non-discretionary.

Sometimes this happens innocently, when customers confuse what they'd like with what they really need. Other times, the reasons are more calculated. Keep an eye out for typical problems in this area:

_ Lack of experience in stating what's needed. There's a good chance that the people responsible for providing requirements will be doing this without much experience. So they'll need some guidance on how they should go about describing what they need. They'll also need to understand the implications of loading on requirements that aren't strictly necessary.

_ Different perspectives from the top and bottom. Most projects have to serve a variety of masters, striking a balance between achieving high-level goals and delivering something useful for people working at the coal face. People at an operational level tend to overstate what they can't live without and more senior personnel tend to see too many things as just nice-to-have.

_ Taking a negotiating position. Given that most projects are known to falter in one way or another, many customers anticipate their project will fall short of whatever's agreed up-front. Therefore they (craftily) overstate their requirements, so they can be negotiated back to where they wanted to be in the first place.

Whatever the reason, it's important to coax customers back into realistic definitions of what they really need and what they'd like.

Facilitate a meaningful discussion on this and try to tease out the facts. However, remember that it's the customer, not you, who makes the final call on what fit-for-purpose means for a project. Accept that the interpretation of quality inevitably involves some degree of subjectivity. After all, you won't be able to persuade the owners of Dubai's seven-star Burj Hotel - reputedly the most luxurious in the world - that lavish bathroom fittings are a nice-to-have optional extra!

[[ It shouldn't happen to a project manager (but it did): The explanation of the importance of prioritizing requirements went down extremely well with one receptive customer: 'This is a much better way of doing things.' The project manager approached the rating of the requirements list with confidence. She started at the top and worked her way down. The first requirement was rated as a 'mandatory'. This was quickly followed by 'mandatory' for the second. And the third, and so on, until all the requirements were universally rated as essential and non-negotiable. The customer was delighted with the requirements prioritization exercise. Like giving up a bad habit, it's easier to gain agreement to the theory than to put it into practice. ]]

Measuring quality

There's an old saying that 'if you can't measure it, you can't manage it'. On a project, if you have some clear and well-thought-out measures for assessing what's fit-for-purpose, it's going to be easier to spot things going wrong and to act accordingly. So how do you go about doing this? Our starting point is that a project's success will largely be assessed by the things it delivers, rather than the activities it does to deliver. So, quality measures must focus on project outputs. These include both the final deliverables and any intermediate ones that are required along the way.

The most basic question is whether all of the planned deliverables have been produced. The next level of assessment is to take a close look at what's been produced to see whether they conform to specification.

A great way to do this is to use quality criteria. These are tests that should be applied to a deliverable to see whether it's fit-for-purpose.

We recommend you phrase your quality criteria as succinct and specific questions. These will encourage an objective and focused assessment of what's been produced. For example: 'Have the foundations been dug to sufficient depth to support the planned two-storey building?' Quality criteria should be defined up-front as part of specifying a project deliverable. That way, the people who are working on your project will know how their efforts will be assessed. This in turn increases the probability that what they turn out will be fit-for purpose.

==

TIP: When you're defining your quality criteria, don't just think short term. It's easy to overlook some of the things that might matter once the project has been wrapped up. For example, you might want quality criteria to check the ease of maintenance once the project team has been disbanded.

==

Quality reviews

A key principle of project quality control is that measures are taken at frequent intervals - especially early on. It's essential to reduce the cost of any rework by intercepting problems when they'll be both easier and cheaper to correct. Bizarrely many projects never have enough time to get things right first time, but always find enough time to do it all over again.

As a general rule, we recommend you arrange three quality reviews during the production of any important deliverable:

_ Before anyone even starts work. Get the key players together to review the specification of the deliverable and the quality criteria that will be used to assess its fitness for purpose. It's amazing how much misunderstanding and ambiguity this uncovers. Far better to have a hand-wringing session before work starts, than trying to rectify a major misunderstanding once work is well under way.

_ At the earliest point during construction when the first sensible measure of quality can be taken. This is an ideal opportunity not only to check that things are heading in the right direction but also to clear up any outstanding issues in connection with the deliverable specification or its quality criteria.

_ As development of a deliverable is completed or is nearing completion. A final checkpoint that will, hopefully, reveal only minor deviations from specification. If major deficiencies are uncovered at least they're known about sooner rather than later.

If the deliverable passes its quality review, work can proceed as planned. If the deliverable falls short, you'll need to agree the rework required and then make sure that this is incorporated in the project schedule.

One tip is to arrange for quality reviews to be built into the flow of work. There are usually several points in a project where deliverables are handed over like the baton in a relay race. At each of these handover points we recommend the deliverable is verified as fit-for-purpose by whoever is on the receiving end of the delivery. This person will have a vested interest in ensuring the quality is right and this is their best opportunity to draw attention to any flaws.

+-+-

It shouldn't happen to a project manager (but it did) . . .

One project team introduced metrics into its quality control process and started rating each delivery to track quality trends. All went well for a time.

The metrics provided a useful tool for spotting problems early. Then suddenly the metrics indicated a sharp and unexpected decline in one area. After investigation by the project manager, it transpired that a few individuals were using the marking system to settle personal vendettas. They were routinely marking deliveries from certain of their colleagues harshly - no matter how good the quality of the work.

Quality reviews are like knives: useful devices but dangerous weapons in the wrong hands. Make sure they're always objective and constructive.

-+-+

Right people, right skills, write quality

It's totally counterproductive to receive misleading feedback - be that misguided and irrelevant critiques, or a glowing bill of health that subsequently proves misplaced. To find out how well your project is really doing you'll need to ensure that the right people undertake your quality reviews.

Be sure that you get the right match between the reviewer's skills and experience and the type of review being requested. For example, a common pitfall is to provide a customer with a document to review that's full of jargon. Then when things fall apart they'll say that it seemed OK to the mat the time, but they weren't really sure what they were looking at.

It's the project manager's responsibility to make sure that either deliverables are presented in a way that matches the reviewer's skills and experience, or some practical help is given during the review process by someone who can highlight and explain the most important review points.

Encouraging a thorough review

Having got the right people involved, it's essential to ensure each reviewer is thorough and doesn't resort to a quick run through. People tend to be busy and don't always devote enough time to the task. This leads to vague comments like 'it looks alright to me' or even worse the dreaded 'nil-return'. The value of a review is directly proportional to the effort put in and gentle cajoling will pay dividends.

Implementing a degree of formality to reviewing deliverables, particularly documents, is a good way of encouraging thorough reviews.

The key is to ask for a sign-off as this creates a different mindset for the reviewer. Consider the two following options for requesting a document review:

1. 'Can you give this a look over and let me know if you spot anything wrong. If I don't hear from you, I'll assume it's OK.'

2. 'I need your review of this report using the attached comments sheet and sign-off by email. Once it's signed off it will be base-lined and any subsequent changes will be subject to our change control procedures.' The first brief will probably result in a cursory glance; the latter is more likely to result in a thorough review of the document.

- -

TIP: Even if a review is undertaken through correspondence, try to get everyone together for a final run through of comments received.

Interaction will help flush out any issues and put maximum pressure on each reviewer to perform an active review.

- -

The people producing the deliverables must always be involved in the review process to ensure everyone understands the outcome. All points raised during a review must be acted on or there must be a solid reason why not.

It's also a good idea to agree the relative importance of the problems and issues that are identified. This will enable the project team to invest its time in fixing what really matters, rather than being diverted to superfluous fine-tuning. However this is one occasion where we like to see a degree of pedantic criticism (e.g. highlighting grammatical errors in a written document) as long as this is not the only type of comment received. It tells you that the reviewers have been paying attention! External assurance

Although you'll always want to see the pursuit of quality integrated into your projects, it's wise to consider additional quality assurance checks run by people outside of the team. In fact, within some organizations or industries external reviews are a mandatory requirement.

A fresh pair of eyes on a project is always a welcome addition.

Scheduling external quality assurance checks also encourages you to take a step back from the day-to-day whirlwind of management and take another look at intrinsic quality with the help of an independent viewpoint. Even if no formal assurance team is available, you could always ask another experienced individual you respect to provide an informal review of your project.

Sometimes formal assurance points will be predetermined. If not, you'll have to decide where they'll be most effective. The key to this is to identify the largest 'pinch points' in the project. The litmus test for any assurance point is to think about where the effort is most likely to be outweighed by the cost of not undertaking the review.

- - -

Factors to consider when you're planning your external assurance points:

_ Mandated assurance points. Are any assurance points mandated within the organization or industry? If not, are there any industry best practices for assurance that provide a useful pointer?

_ Points of 'no return'. Are there any points where the consequences of having to backtrack, now or at a later date, would be serious?

_ Points where funds are committed. Are there any scheduled payments or other financial commitments? What checks should be made before funds are committed?

_ Natural break points. Most projects consist of a number of distinct phases. Are any of these break points a useful place to take an assurance review?

- - -

As with internal reviews, the value of any external quality assurance review depends on the skills and experience of the reviewers involved.

Unfortunately many organizations seem to have a policy of using quality assurance departments as a retirement home for individuals whom they believe have outlived their usefulness anywhere else. Nevertheless a positive attitude to working with an assurance team can pay dividends.

They're often unfairly maligned, just like project managers!

Summary

Issues with timescales and costs are easy to spot and therefore get immediate attention. Shortcomings in quality are not always as obvious and can lurk beneath the surface. Often they emerge only when the final delivery is rejected by the customer, having been labeled as substandard.

Your customers will judge your project by whether what it delivers is fit-for-purpose. It's important to agree what's mandatory for the project and translate this into a baseline that defines what's truly non negotiable. You'll also need to help customers pin down what they'd like the project to deliver and to encourage them not to over-inflate their essential requirements.

Brilliant project managers know the cost of failing to meet customer expectations. They also recognize it's far more cost-effective to invest effort up-front to prevent this from happening in the first place, rather than dealing with the consequences of handing over something that's not up to the job.

Brilliant project managers also realize that their long-term reputation stands or falls on what they deliver. So, unless you're planning on putting on your running shoes the day before your project delivers, work with your customers to define quality and make achieving this your primary goal.

Summary bullets...

_ Quality doesn't have to be a vague, intangible concept. Define what fit-for-purpose means in specific and measurable terms.

_ Be prepared to accept that your customers have the final word on the difference between what they want and what they really need.

_ Build quality reviews into your daily routine. Check your deliverables are fit-for-purpose at every step along the way.

_ Be open to the contribution that an external quality assurance team could make.

_ There's no point in delivering something that no-one wants - even if this is achieved quickly or cheaply. Never let time and cost pressures compromise your minimum fit-for-purpose baseline.