Quality planning

We plan in quality management for the same reason that we plan in any other activity, in order to have a sensible, efficient and structured approach to a task. The chief purpose of quality planning is to produce a quality plan, that is, a description of how the project is going to achieve its quality requirement, and also what those requirements are. Like the overall project plan, of which the quality plan is a part, the quality plan serves two purposes: as a plan, and also as a communication tool, especially to engage key stakeholders in the quality management process.

Key Idea

Quality plan

'The quality plan is a vehicle for mitigating risk ....' UK MOD Def Stan 05-97

A quality plan need not be long or complicated or expensive to produce. For small or simple projects, a single paragraph may suffice. Consider the quality plan shown here, used by a London-based company that ran a project to set up a new division to offer training courses to the public. It shows that a quality plan can be short and simple and straightforward. It also shows why it is useful to have a quality plan written down there can then be no doubt in the minds of those involved what is expected in terms of quality, and everyone is clear what the quality objective is: 60% or more 'Yes' votes. Of course in more complex projects, the quality plan will need to be more substantial.

Example of a quality plan

The quality objective of the new training division is to provide training in XXXX to a level of quality such that delegates and their managers feel that the training was well worth the fee and they will recommend colleagues and friends to attend our courses. We will measure customer satisfaction by using anonymous feedback forms, to be distributed at the end of every course, and the key question will be 'Would you recommend a colleague or friend to attend this course, given its cost? Yes / Maybe / No'. A 60% 'Yes' recommendation after the second pilot course will constitute success for this project. Before giving the first pilot course to the public, our instructors will all:

1. undergo a one-day course in adult instructional techniques,

2. see themselves on video delivering the course in a dress rehearsal,

3. have been approved as competent to deliver the course by the project director,

and the project director shall satisfy themselves that the dress rehearsals meet a sufficient qualitative standard for proceeding to running public courses.

Let us walk though the steps in the quality planning process, as depicted in Figure 8.1.

Figure 8.1. The quality planning process

The most important and most commonly used inputs and outputs are in solid ovals, others are in broken-lined ovals. Similarly, the tools and techniques that are most essential are printed in black, the others in grey. Many industries and companies have their own quality planning techniques, and these are recognized under 'Additional quality planning tools'. Although that i s in grey, where your organization or industry has such tools and techniques, use them. In the inputs, it is obvious what the project management plan and the scope statement are. The PMBOK terms 'Enterprise environmental factors' and 'Organizational process assets' may be a little cumbersome and obscure, but the notes attached to each of those, above, explain what they are, and they are both useful categories of inputs to the quality planning process in many cases. Although the diagram above shows 'Enterprise environmental factors' in a broken-lined oval, implying that generally it is not the most important input to quality planning, an exception of course is in any regulated activity or safety-critical project, where the relevant regulations or legal requirements affecting quality must be used as inputs; in many cases the raw regulations and laws will have been incorporated into in-house procedural manuals, and so should be available as 'Organizational process assets'. The quality management plan is the most important output. It can be sufficient for the update to the project management plan to insert the quality management plan into the relevant place in the project management plan. A quality checklist is very useful, where appropriate, but derives from the quality management plan or the principles in it. Adapted from PMBOK Guide (p.184)

Inputs to the quality planning process

Begin your quality planning by getting together the inputs. The quality plan will be part of the project plan, and quality management is an integral part of project management, so the project plan is an input: do not plan quality in isolation from the rest of the project plan. The scope statement is a vital input to quality planning, because if something is out of scope then you do not need to plan or manage its quality. For example, if the scope of a project to build a database is to build a proof of concept database which will not be used for operational purposes, then there may be a whole raft of quality requirements, for instance to do with longevity, maintainability and data security, which can be ignored. Continuing the example, there are many people in organizations whose job it is to enforce various IT standards on databases, and the quality plan coupled with the scope statement can be an effective way to communicate to them, in a professional and positive way, that in this project those standards and procedures can be ignored. Equally, when something is in scope, the consequential requirements for quality need to be understood and input to the quality planning process. So the scope statement is a key input to the quality planning process.

Figure 8.1 lists two other inputs to the quality planning process: enterprise environmental factors and organizational process assets. Organizational process assets are simply assets your organization has that may be useful as inputs to the quality planning process, such as the following:

• The organization's quality manual, quality plan, quality processes.

• Lessons learned from previous projects or other activities relevant to your project.

• In-house quality experts.

• In-house expertise related to key areas of your project.

• In-house manuals and procedures, including those specifying how your organization is to comply with regulatory and legal requirements.

• Databases and library documents containing standards, policies and procedures.

This input, organizational process assets, illustrates a general point, not just for quality planning but for project management too: do not make a long, expensive and bureaucratic affair out of it. Indeed, if you have to choose, choose too little rather than too much. Judgement and a sense of urgency and efficiency are indispensable; an unthinking rules-based approach is at most one step short of disaster. What does this mean? In respect of finding organizational process assets for use as inputs into quality planning, it means have a quick look around your organization for things that might be useful, and glance quickly through what you find to get a sense of whether it is likely to be useful to your particular project. The loss-making companies and failing government departments of the Western world are full of failed grey men and they usually are men who given half a chance will waste weeks and months on pointless documentation and regurgitation of irrelevant details and unnecessary process models. Don't get involved in them, and don't let them clog up your project. Have a quick look in the obvious places for input, do a quick assessment, and bend and adapt it to the needs of your project. Of course you should keep your sponsor informed of what you are doing, and enlist their help in deciding where to look for organizational process assets.

The final input is enterprise environmental factors. This cumbersome term means things like:

• Standards that you have to meet because they are mandated by a regulator, a law or an industry body.

• Other standard operating procedures and guidance specific to the application area of the project.

• Norms and generally expected standards in your organization, or of key stakeholders, which while not directly relevant to your project may create expectations or opportunities to shine for your project.

Tools and techniques used in the quality planning process

Once you have gathered together your inputs you are ready to create your quality plan. The main tool is common sense, otherwise known as cost benefit analysis. There is no point doing quality management if the cost of doing it, in bureaucracy or whatever, exceeds the benefits. To take an example not from project management, if a fire breaks out, trapping you in your office, you want to use the fire extinguisher if there is one and try to escape immediately rather than hanging around conducting risk assessments and working out quality plans, because there is no benefit to doing them; the only possible benefit in that situation is to get you out of danger. That argument can be described as a cost benefit argument. A constant danger in real life where quality management is involved is that the costs of doing quality outweigh the benefits. It need not be so. It is your job as project manager to ensure that if there is a quality management aspect to your project it creates greater benefit than cost.

Do not be put off by the term 'cost benefit analysis'. It does not need special financial skill or complicated spreadsheets, or any spreadsheet at all. It can simply be a matter of writing out a few rows, one for each benefit of using quality management in your project, and describing in words the costs and benefits of so doing. Table 8.3 is an example, from a hypothetical project to build a database for managing legacy documents needed to investigate insurance claims.

Table 8.3. Example of cost benefit analysis in quality planning

	Possible quality objective	Cost	Benefit	Comment
1	Contents of database should have same explicit and implicit structure and conventions as our other key corporate databases.	If we use our own staff: overtime costs, one day of training each, but some delay to project because of their limited availability. If we use temporary staff: contractor costs, two weeks of training plus background checks for each a higher cost option.	Confidence that the data are structured and represented in a way that our organization and customers understand. Reduced risk management and insurance costs.	Cost estimates derive from August pilot. Deciding factor is whether we can afford delay in project right now stakeholders are saying we can.
2	Follow ISO 17799 for IT security.	Minimal. We work that way anyway. The only costs will be some extra documentation and auditing.	We have to do this to meet the requirements of our joint-venture partners, who are paying for the database.	Not a material cost.
3	Provide two large screens instead of a single standard-sized screen for each database user, to increase ease and comfort of use.	Initial, rough cost estimate is 15,000.	Improved ease of use: the August pilot showed very strong operator preference for two large screens. Reduced risk of health and safety compensation costs arising from operators using small screens.	Less than 5% variance in cost, probable that benefits from faster working will more than recover this cost. Health and safety litigation risk is small, but last year we lost a similar case at a cost of over 1m. Probably worth going for double screens.

Table 8.3 shows the cost benefit argument set out in a qualitative, but objective and verifiable way. Like any plan, the quality plan must have clear objectives, and these are called quality objectives. This is simply saying that you should be clear about what it is you are trying to achieve in quality. Table 8.3 is an example of how not all quality objectives are directly related to the customer. One of the quality objectives concerns the comfort and health and safety of the employees who will use the database. This may have an indirect effect on the end customer, but the primary effect is on the employees, to ensure that they have a comfortable and safe experience when inputting data into the database. This is a valid quality objective. Once you have a qualitative cost benefit case, such as the example in Table 8.3, you can extend it if necessary, and perhaps add more quantification.

Key Idea

Quality objectives

Quality objectives should be written down. They need not be long, in fact, the shorter and simpler the better. They should be clear and SMART, that is:

S pecific,

M easurable,

A cheivable,

R ealistic and with

T imings.

The other tools and techniques shown in Figure 8.1 for use in quality planning are essentially special kinds of cost benefit analysis, except that benchmarking can also help to generate options for quality objectives. Benchmarking means looking at what others are doing in the same or similar areas and how well they are doing it, so that you can try to match it. The underlying logic is that if someone else can do it, then you can too, potentially. Benchmarking applies to quality planning in two ways: you can find out what quality objectives others are working to, and you can find out what standards they are meeting or trying to meet for certain objectives. Remember that benchmarking can be both external, that is, against organizations other than your own, and internal, that is, against other parts of your own organization than the project you are managing.

Cost of quality is a refinement of the general cost benefit analysis. Suppose we are running a war and we are using jet aircraft to fight the war. The jet engines break because of quality problems, causing our aircraft to crash. We can (a) do nothing, and keep buying new jets and training new pilots, (b) redesign the jet engines so that they break less often, (c) increase our engineering and maintenance capability, so that we service the jet engines more often, (d) buy a whole set of new jet engines from Clockland, a neutral country with a great engineering tradition. Each of these options has different costs, which need to be judged against the cost of existing quality, that is the cost of keeping on buying new jets and training new pilots. This thinking may lead to generating another option let us call it (a.i) which is to buy better ejector seats and parachutes perhaps we can live with the quality of the jet engines if we can stem the loss of pilots. Just as there is a cost structure in products and services and organizations, so there is a cost structure in quality, and one of the main benefits of the 'cost of quality' approach is that it helps us to understand the cost structure of quality. This enables us to generate options for planning quality.

There are many other techniques and tools that can be used in planning quality, such as design of experiments, linear programming, and brainstorming. Do not be constrained in what tools and techniques you use, be pragmatic: if you have a useful tool or technique, use it. Usually there will not be time to learn a new tool for your project. Use what you already know how to use, or, even better, delegate the task to experts on quality in your organization if they are available. Quality planning is no different from planning as practised in general management; it is merely planning techniques applied to the specific field of quality management. You are likely to find that the tools that are most effective for you are the ones you are already experienced in.

When planning quality, use objective, factual data as inputs to the planning process.

Quality planning outputs

The main output of quality planning is the quality plan. This is not separate from the project plan, but is a section of it. Project planning is an iterative process, so you will start the quality planning process with a version of the project plan that has no section on quality management, and end up with an updated project plan that includes a section on quality. This section is the quality plan; they are not two different things.

Quality plans vary in size according to the size and type of project. A small simple project may have no quality plan or a plan of a few lines. Large complex projects in safety-critical environments may need large and complex quality plans. Even the shortest quality plan should include the following:

• Quality objectives for the project.

• A list of quality standards, tools or techniques to be used.

• A statement of how quality will be measured and what metrics will be used.

If the quality plan is anything more than the smallest kind, it should also include:

• Names of independent reviewers who will be reviewing quality.

• The approach that the project will take to quality assurance.

• The approach that the project will take to quality control.

In large or complex projects there can be great benefits to having peer or external reviews. Even if such reviews are intended to do no more than provide a fresh pair of eyes to look over certain aspects of what the project has done, this can be very valuable. Such reviews fall naturally under the heading of quality management. In some industries and companies external reviews are mandatory. Where there are to be such reviews, the quality plan should describe:

• How the external or peer review will work.

• The objectives of having a peer or external review.

• Its scope.

• Who will be doing the review.

• At what stage in the project it will be carried out.

Having set quality objectives, the project will need to measure performance against the objectives. If it can't be measured it won't be managed, as the saying has it. The quality plan should specify the metric to be used to measure quality. In the context of quality management a metric is a system of measurement. (Note that it is not the measurement itself.) An example of a metric is given by the following instructions:

At the end of the training course for inducting new staff onto the project, the instructor shall hand out the standard end-of-course questionnaire, read the class the rubric printed on the top of the questionnaire, emphasizing the anonymous natures of the questionnaire and feedback process, and ask the class to complete the questionnaire and leave it in the sealed box before leaving the room. The results will be collated and analyzed by the quality management department and fed back to the instructors.

This example leaves much of the detail of the metrics implicit in terms such as 'standard ... questionnaire', but for this organization it states what the metric is and how it will be deployed on the project. Another example is as follows:

After the final build, the database will be tested by BreakIT Corporation, Inc., the independent software testing organization, who will perform stress and volume testing on a Monte Carlo basis to determine the number of users at which performance starts to degrade, and the quantitative profile of degradation, especially the rate of increase in response time delays of entering new data and screen refreshes with respect to the increase in number of users of (a) the main user screen at levels of 50, 75 and 100 users, and (b) the data entry screen in the range from 20 to 60 users in five user increments. BreakIT will also record any other test results that in their expert judgement are likely to be significant, and will produce a written report of their test findings.

Quality metrics are an essential part of the quality plan. Other possible outputs of the planning process are checklists, a process improvement plan, and a quality baseline. Checklists are a simple but effective tool for improving quality, and are worth using wherever appropriate. Short, simple checklists are best. Where the project plan includes a section for the process improvement plan, updates to it should be an output from quality planning, but in practice this applies only to large and complex projects. The quality baseline is simply the baseline for quality, which is vital because otherwise the metrics will not have any practical meaning. Baselines can be very simple, for example: 'Baseline for SQEP project team members: In April 2006 at the start of the project two of 18 members of the project team had the skills and experience that will be necessary by the December 06 primary test target date.' Or, as an engineering example: 'Mean time between failures for the Mk.IX jet engine systems at the start of the project is 92 days; pilot death/downgrade rates from mid-air Mk.IX failure is 51%.' Both of these examples are baselines that enable improvement, or worsening, of quality to be measured.

Top of Page