Chapter 13

Managing Project Quality

In This Chapter

Understanding the importance of quality

Creating the Quality Management Strategy

Looking at quality at stage and team levels

Checking and controlling quality

Using the Quality Review technique

Managing projects is about delivering on time and within budget – that’s what you often hear. But that just isn’t true. Whatever’s the point of delivering a load of unusable garbage on time and within budget? Project management is about delivering on time, within budget . . . and to quality standards. Quality is a vital third dimension.

The PRINCE2 project management method is actually rather good at managing quality. Unfortunately, the chapter in the official manual is a bit obsessed with definitions and processes, so it doesn’t explain too well how quality works. See whether you think this chapter makes a better job of it.

Given the obvious importance of quality in projects, its frequent neglect is a bit strange. But the problem is that people always think they’ll get away with it. For this reason, quality is often the first casualty and an easy target if a project comes under pressure.

Given the strong focus in many organisations on only time and cost, you may need a bit of determination to push for good quality management. But in some projects quality is the most important element. In fact, even in projects where quality seems to have a low profile, it is often more important than you think. If a project delivers on time and to budget but the deliverables don’t work properly, people are still complaining about it two or three years later and long after the problems have been fixed. In contrast, if a project delivers a couple of months late but everything works perfectly, two years later everyone has usually forgotten it was late.

The project to build a new air traffic control system for the south of the UK came under severe criticism for being late and over budget. But if you’re in a passenger aircraft approaching London Heathrow – the busiest airport in the world – and you have to choose, would you rather they got the air traffic control system completed on time and within budget, or that they’d got it right? In some cases quality is overwhelmingly the most important factor.

Product Planning with Quality Built In

In Chapter 14 you can read about the powerful approach that PRINCE2 uses for planning that’s ‘product-led’. This is a very logical approach, where you define what you’re going to produce – the deliverables or products – before you try to list the activities and resources you need to build them. But apart from being powerful in its own right, the product-led approach to planning also opens the door to very precise control over quality and this is the key point you need to take on board to understand quality management in the PRINCE2 method. You can’t specify quality for an activity very easily, but you can specify measurable quality criteria for a product. In PRINCE2 projects you list these quality criteria on the Product Descriptions, which you use to define every product.

Product Description. You write a Product Description for every product identified at project level, and then again when the products are broken down into more detail in every stage. The Product Description defines what the product is but also sets down the exact standards that products must meet (quality criteria); how you measure them (quality methods); boundaries for quality, such as upper and lower limits of machine performance (quality tolerance); and who performs the quality checks (quality check skills needed and also responsibilities for the actual checking). The set of Product Descriptions also includes a Project Product Description for the whole project; usually the final deliverable. Chapter 14 has much more detail on products, Product Descriptions and the Project Product Description.

Just because this section is short, don’t underestimate the huge precision that PRINCE2 brings to quality by adopting the product focus in its approach to planning and control – it’s an extremely powerful aspect of the method.

Taking Quality Seriously, Very Seriously

Having established that quality is very important, you must take it very seriously in your projects. Organisations can easily play games and give the appearance of delivering quality when actually they’re not. Compliance with international quality standards is an example of this mindset. How many organisations start with ‘We want the quality certification label, now what’s the minimum we have to do to get it?’ rather than ‘We care about quality so let’s get the certification as evidence of that’? How many senior managers sign every page of quality manuals without actually reading the pages? You mustn’t allow such games in a project – you have to get quality right.

Delivering appropriate quality

PRINCE2 is extraordinarily practical regarding quality and doesn’t suggest that every project needs ‘top quality’. Instead, the method focuses on appropriate quality. Not every project is safety-critical, where human life hangs in the balance – like the air traffic control example earlier in the chapter. If your project is ‘quick and dirty’ then PRINCE2 helps you deliver at that level. Equally, if your project really is safety-critical, then it helps you deliver at that level too.

Overstating the quality level you require often leads to two problems. First, you pay for high quality when you just don’t need it. That affects the Business Case because of the costs, and it also affects the time you require, because the extra work lengthens the project. In turn, that also means that bringing the business benefits on stream takes longer, which again affects the Business Case. The second problem is that, where you set the quality level much too high, a common reaction when the pressure’s on is to abandon quality completely: ‘Well, never mind, we’ll do the next project properly.’

Quality costs money, so don’t overstate the level you require. But don’t understate it either, because poor quality can turn out to be even more expensive in the long run. Have you ever bought something cheaply only to regret it later when it doesn’t do what you want? And do you end up buying the more expensive but better-quality item you should have bought in the first place? Of course not, but you probably know people who do.

The Quality Management Strategy sets down, amongst other things, just what level of quality you need to achieve in the project. That strategy forms part of the Project Initiation Document (PID). The strategy is in the PID because the level of quality, as well as the way you achieve it, varies from project to project. If quality was always the same for every project, you wouldn’t need to put a strategy in the PID. (For more on the PID, please see Chapter 5.)

Sticking to quality

Abandoning quality is a common problem in the IT community. When discussing quality on one site someone asked me, ‘Haven’t you ever heard of live testing?’ This is where you go live with some vital computer system, and then you see whether it works or not. Rather amusing, but not so for another computer company whose senior sales staff commit to short deadlines in order to win business, but those deadlines don’t allow enough time for testing. This company installs systems on customer sites that almost always fail and the supplier has to do the ‘bug fixing’ in full view of customer staff. This lack of attention to quality is seriously damaging the company’s reputation and if the company doesn’t get things under control soon it may lose its leading position in the marketplace, because its competitors have a more quality-led approach.

I’m not saying that after you decide a level of quality you can’t reduce it. If the project comes under pressure, you can indeed lower the quality to save time or money. But that’s a conscious decision involving the Project Board; you don’t reduce quality just because a team left some of the tests out.

Specifying Criteria for Project Acceptance

Although there’s power down at the ‘rivet-counting’ level with the products, PRINCE2 also works at the higher level to help you set down quality for the whole project and especially for any final deliverable. It does this at two levels, both of which are written into the Project Product Description.

Customer quality expectations

The Customer quality expectations are, as the name suggests, what the customer side of the project is looking for. These expectations tend to be a bit on the vague side. ‘We need it to go fast’ or, ‘It needs to be durable’. In writing the Quality Management Strategy – more of that in the next section – these expectations are translated into something more measurable, the Acceptance Criteria.

Acceptance criteria

Acceptance criteria are for the whole project and must be measurable. They can be new as the Quality Management Strategy is written, or some may be refinements of the customer quality expectations. The idea is that the project will be accepted if the criteria are met. The criteria can include timings, such as the delivery date of the project.

IKEA, the Swedish furniture manufacturer, has display cases in its showrooms showing products being tested. One display I saw in a UK store was a machine opening and closing a drawer. An electronic display showed how many times the drawer had been opened and closed and you could see it clocking up with each movement. That gives a measurable definition to a customer quality expectation of ‘durable’. IKEA design their drawers so that they still function without problem after a stated number of movements, which is a mind boggling number.

Writing a Quality Management Strategy

The Project Management Strategy sets down the level of quality you’re going for in the project, what control mechanisms you use, and who’s responsible for making sure that you actually deliver the correct level of quality. ‘Strategy’ is an important word here. The strategy doesn’t contain the fine detail of exactly what tests you do and when because it’s much too early for that: You create the Quality Management Strategy in Initiation (the first stage of the project, which is for planning only) and before you even produce the Project Plan. You cover the tactical planning of exactly what and who and when in your more detailed planning of each stage.

When thinking through the Quality Management Strategy you need to watch out for any constraints. These can come primarily from two directions and may override anything that the user actually wants (the Customer Quality Expectations). The first constraint is the Project Approach that you produce in Start Up (for more on Start Up, please see Chapter 4). The Project Approach may include things such as safety measures and other standards with which the project must comply, and so you must take them into account in the Quality Management Strategy. The second direction is any organisational standards, and in turn these may be influenced by other quality standards such as the International Standards Organisation ‘ISO’ series.

Quality Assurance and Quality Control. Where you see the word ‘assurance’ in PRINCE2, think ‘audit’ and you have the right concept. Quality Assurance is an independent check of the whole project. An example is if your organisation has a quality department with staff who check up on quality throughout the organisation, including its projects. Quality control is the actual testing or checking of something.

Here are a few suggestions of things you need to think about when working through some of the sections of the strategy.

Introduction

Although the PRINCE2 manual suggests that the next heading in the strategy, the Quality management procedure sets down variance with the organisational or programme quality management standards, it can make more sense if you mention it in the context of scope as well; covered in this section. The project strategy may have limited scope because for the most part, the project will follow the organisation’s standard approach.

Tools and techniques

If you need to specify industry standard techniques, you don’t need to copy them all into the strategy. It’s quite okay to just reference other standards.

Records

As with other strategies, the manual suggests that you set down here composition and format information for registers, this time for the Quality Register, but that’s not usually needed as it’s self-evident what the composition and format is; just look at it! The content of the Quality Register is covered later in this chapter as is a bit more on other quality records you may need.

Timing of quality management activities

Timing here, for things like quality audits, can be ‘random’ but then you need to make quite sure that ‘random’ doesn’t turn out to be ‘never’. To avoid a problem, you can specify a minimum number of audits or a maximum time period between audits.

Roles and responsibilities

Don’t get tied up in knots here, the manual explanation isn’t particularly clear. Logically this section can only refer to responsibilities at a high level, though reading the manual you might wrongly conclude that it refers to all quality management activity including product testing. If you think about this, you can’t yet specify responsibilities for quality management activities at a product level because you haven’t even come up with the Project Plan yet, let alone the Stage Plans where the testing needs become clear.

Instead, this section must be high level but points out particular resource needs that’ll be useful to know when you come to do the project planning. For example, you may identify that you’ll need to have an external safety inspection of the building works that you already know are to be included in the project. You may then need to put on your plans that the building inspection needs to be booked in Stage 3 in order for the inspection itself to be carried out in Stage 5.

Planning Stage- (and Team-) Level Quality

In contrast to the strategic nature of the Quality Management Strategy, planning at stage and team level is tactical. You work on this mostly during stage planning, so you repeat this work right through the project, stage by stage. The quality activities are built into the Stage Plan although, regrettably, the 2009 edition of the PRINCE2 manual has withdrawn a heading of ‘Quality Plan’ where a note could be put to say how quality is being tackled in that particular stage. It’s regrettable because that heading helped keep a focus on quality throughout the project and prompt some specific thinking about it when doing the stage planning. You should still do the thinking though!

This tactical level of planning sets down exactly what testing you need, and who does it, how, and when. Clearly, you can’t specify these details in the Quality Management Strategy, because at that time you don’t know the details of the stage products, the requirements for testing them, or the exact availability of the staff resources to do the testing.

You can take quality planning right down to team-level plans. This is unusual though, and I’ve never yet seen it used even on big projects. The Stage Plan will usually be enough, but the team level is there if you need it.

Controlling and Auditing Quality

Quality control is the testing that you do to check that a product meets the required quality criteria set down in its Product Description. Quality control applies to management products such as the Project Plan and Risk Register just as much as to specialist products – the things that the teams build.

The type of quality control or test depends very much on the nature of the product being checked. If the product is a document, you may well use the Quality Review technique (see ‘Checking Products with Quality Review’, later in this chapter), or you can use informal quality review where a colleague checks the document over. If it’s a product like a bridge, you can get someone (else) to drive over it in a tank.

If quality checking is at all dangerous, always delegate it. Remember you’re an important PRINCE2 expert and you need to live in safety and comfort to check documents, think important thoughts and do other vague but essential project stuff back at headquarters. Send an expendable team member to do the dangerous things. If you’re a team member reading this and have just received a dangerous assignment, obviously your manager bought a copy of this book before you did.

Controlling quality

The PRINCE2 method always did have a bit of a problem with language that isn’t exactly friendly if you’re a business user of the method, not a project professional. Sadly, the 2009 edition of PRINCE2 has introduced even more for you to get your head around.

Quality control involves the actual testing of products, but also the documentation and, if required, any further actions needed to get a product formally approved. For the testing though, the method has now introduced two categories of test, one with two sub-categories – value for money then.

In-process and appraisal

The two higher-level categories are ‘in-process’ methods and ‘appraisal’ methods. In-process is the easiest to understand from the name and simply means testing that is done while a product is being built. For example, when building parts for a machine, the technician measures with callipers at intervals to make sure that the part is cut to the right size. Appraisal refers to checks after the product is finished to make sure it’s okay.

Appraisal in turn splits down into two sub-categories of ‘testing’ and ‘quality inspection’. You can think of these simply as objective and subjective testing. Testing is objective; it’s a matter of fact and often of measurement. So, is the paper A4? Is the cover of the report blue? Quality inspection is subjective; it’s a matter of judgment and even of opinion. So, is the report understandable? Is the teenager’s bedroom tidy?

Auditing and the Quality Register

You can manage quality very effectively by setting up an audit trail for quality testing and checking the quality controls. Of course, the following conversation never, ever happens in your organisation’s projects, but you may overhear people on the train from another organisation talking like this:

Project person 1: ‘Oh, by the way, I never saw the test results of the reverse separation flange ignition to make sure it was firing up okay.’

Project person 2: ‘Oh rats! I meant to remind the team to do that test, but then I forgot all about it and they must have too. And now they’ve built the flange ignition into the main transverse combustion housing, which is due to be shipped out tomorrow so we can’t get at it – not without taking it all to bits again anyway, and we’re up against the deadline as it is.’

Project person 1: ‘Well, it was a pretty important test. How long would it take you to take it out, test it, and then rebuild the housing?’

Project person 2: ‘Three weeks minimum.’

Together: ‘It’s going to have to stay where it is and let’s hope it works.’

In a PRINCE2 project you simply can’t forget a test. The Quality Register is a clever but simple mechanism that ensures you don’t. As part of planning each stage you write Product Descriptions for every product you will build in the stage, each of which includes a section that specifies how you test the product. After these descriptions are complete you can copy all the tests from these Quality Method sections into the Quality Register. Then, when you do activity and resource planning for the stage, you can add in the test dates and details of the people to do the testing.

As the stage progresses and the tests are done, each one is signed off in the Quality Register and the Error Sheet is usually filed there too, even if it’s a nil return, where no errors were found by the testers. If some corrective work is needed to a product then a re-test, that work is now listed in the Quality Register as well, and signed off when it is done.

Now, here’s a clever bit because lots of people now check that register. While the work is being done to build and test the product, the Project Manager, Team Manager, and Assurance staff check the log regularly to see that the tests are being done. When the products in the work assignment are all complete, the Team Manager checks the register one more time to be sure that all the tests were done for those products. When he hands the completed products back to the Project Manager – you’ve guessed it – at End Stage a further check is done to assure the Project Board that the quality was delivered. Each of these checks takes mere moments. So, for a particular product, the three tests were done and signed off, and error sheets signed and filed. Thirty seconds, maximum, but highly effective to spot if a test got missed out.

The Quality Register is a very effective audit trail: It’s quick and simple to set up, incredibly easy to maintain, and takes mere moments to check. This is a method at its best – fast, effective, and light years away from the dull, dry, and wrong impression that methods are about filling some forms in and having to mindlessly follow a lot of boring steps.

Now for a clever bonus in PRINCE2. Three registers are set up during the first stage of the project where the planning is done (the Initiation Stage). But of these, the Quality Register is set up first and immediately, right at the start of the stage. That means it’s available for use to audit the testing of the management products being developed in the Initiation Stage for the Project Initiation Document and for the next Stage Plan. Now that’s neat.

Making sure of assurance

You have to check that someone actually does the tests you require. You can do this simply by using the Quality Register, but you may want something more than that. I made unkind comments earlier in this chapter about people signing things off when they haven’t even read them, much less checked them. Quality Assurance and Project Assurance (the audit functions) may have to be a bit more probing then than just merely checking that tests have been signed off in the Quality Register.

Where Project Board members aren’t doing their own assurance, they should talk very specifically to their Project Assurance staff about exactly what will be checked and how. Ultimately the Project Board is responsible for the project and for delivering the required quality and they must be assured that it has all been checked. (See Chapter 12 for more on assurance.)

Checking Products with Quality Review

PRINCE2 doesn’t have much in the way of project techniques and it expects you to find and use suitable ones. But it does cover Quality Review, which is a useful technique, provided you do it well. If you don’t do it well it quickly becomes a sham and a waste of time.

A Quality Review is a meeting you use primarily to check products that are documents. People involved with the product ‘walk it through’ (hence the common alternative name of ‘quality walkthrough’) section by section to see whether anyone found any errors and, if so, how severe they are.

Roles in the quality review

Four roles are used in the review technique. People are appointed to these roles for each Quality Review as part of stage planning, when you establish the need for the review and plan the resourcing of the stage.

Chair: Someone with skills in running a meeting who checks that the product is ready for review, and then runs the meeting.

Presenter(s): The person or people who can talk knowledgeably about the product under review and send it round in good time before the meeting. It’s often the person or people who actually produced the product.

Reviewer(s): A person or people who can say whether the product is right or not.

Administrator: Someone who helps arrange the meeting and then notes down any errors found and details of any corrective work needed.

These roles have absolutely nothing to do with the Project Board, so be careful not to confuse them. Project Board members don’t do any of the work of the project. If someone on the Project Board is qualified to take part in a review, then that’s a completely separate role to his Project Board work.

Finding, not correcting, errors

Quality Review is about finding and noting errors, not correcting them during the meeting. Where Reviewers find errors before the review meeting itself, they can send details to the Administrator, who puts them on the agenda for discussion on how severe they are.

Don’t allow error correction in Quality Review meetings. Doing a quick fix is almost certain to miss out some of the implications and lead to more problems. The Quality Review meeting takes place just to find any errors, but the Project Team fixes them.

Staying ‘ego-less’

Quality Reviews are not about ego. If the producer(s) of the product are also acting as Presenters in the review, they mustn’t be defensive and the Reviewer(s) mustn’t attack. The focus is simply on finding any errors so that they can be put right. If Reviewers go on the attack, then the Presenters are likely to defend. But the review isn’t about attacking people or defending reputations. It’s simply about checking to see if a product is right or not.

Be particularly careful of young and junior team members who are involved in a review. They tend to be far too proud of their work, having worked extremely hard on it, and they can feel hugely disappointed and very protective of their product if anyone finds an error. They can then sometimes try to rush a review meeting on to the end before anyone finds another problem with their precious work.

When working as a full-time Project Manager in IT, I used to devote a fair bit of energy to getting the right concept of Quality Reviews into the heads of junior team members, albeit kindly I hope. I used to explain ‘We don’t make our reputation out of error-free Quality Reviews. We make our reputation out of delivering computer systems that work. If someone finds an error in one of our documents, they’ve just helped us deliver a system that works.’

Signing off – the three options

At the end of a review meeting the members must agree what the outcome is. It may be one of three logical alternatives:

The product is fine and the team has done a great job: The product can be signed off at the end of the meeting and the review result put in the Quality Register.

Errors were found that must be corrected, but they’re not serious: The errors are noted on an Error Sheet and the required action listed in the Quality Register, and the meeting closes. When the errors have been corrected the product is taken back only to those who found the errors in the first place. If they’re happy, they sign off that entry on the Error Sheet. When all errors are signed off, the product is signed off.

One or more errors have been found that are more serious and require some effort to change: Because this affects the whole product, the review meeting decides that individuals can’t sign off the errors (as in the case of less serious errors), but rather that everyone needs to see the product again to make sure that it’s now correct. The product must be put through Quality Review again after the corrective work.

Recording Quality

If you’re going to check that quality has been delivered, then clearly you need something to physically check. This is where the records come in. As always, be careful with records because you don’t want a paper mountain or the electronic equivalent. But you need some form of record. This section is last in the chapter because most of the possible documents covered here have already been mentioned in earlier sections.

PRINCE2 quality records

PRINCE2 expects that quality requirements are recorded at a strategic level, product level and then an audit trail that quality activities were carried out. The Quality Management Strategy is the strategic document, then Product Descriptions for quality criteria for individual deliverables, then the Quality Register to list quality activities together with confirmation that those activities were carried out. These are all explained earlier in this chapter.

Generic quality records

These records aren’t specified by PRINCE2, but you’ll probably need something in this area. Here are a couple of examples.

Test logs

You can’t put huge lists of very detailed tests into the Quality Register. Instead you’re likely to have dedicated test documents such as test scripts, and then log the results of the tests. The test log is a common document for doing that and provides a checklist to ensure that every test is done, and an audit trail for others to see that the test was done and what the result was.

Error sheets

Already mentioned earlier in the chapter, Error Sheets are great. Someone has asked what is worse than biting into an apple and finding a worm. The answer is, biting into an apple and finding half a worm – guess where the other half is! What is worse than finding an error? Finding it twice. You hit a problem and then realise that it was spotted earlier but somehow it got forgotten and slipped through without being corrected. The Error Sheet makes sure that all errors are listed, albeit simply, and that they have now been put right. You can use it in informal review – peer-level checking – as well as formal review. It’s also helpful to retain ‘nil returns’ so that you have a record that the check was done and a confirmation that in this test no errors were found.

Correspondence and meeting records

If there’s discussion on the quality of a product, this may need to be recorded. It may be simply a copy of emails, memos and letters but it could include minutes of meetings held to discuss and decide on quality issues.