Where are we?
In simple projects it is useful to highlight quality as a topic in its own right. However, in Praxis, quality is deemed to be inherent in all processes and procedures.
You now have a better idea of the work involved in the project and need to start thinking about how we can maximise the chance that everyone (and especially the sponsor/users/boss) will be pleased with the outcome of the project.
The quality assurance environment
The first thing that you need to consider during the definition phase is the quality assurance environment. Quality assurance (QA) is created by building a management environment within which a quality project is almost guaranteed (it cannot be actually guaranteed, because we mess up this carefully built environment by putting human beings into the situation!).
The corporate project management environment should contain the following:
Methods, standards, guidelines, process maps: guidance to help project managers follow good practice.
Templates, examples: templates and examples of forms that the project manager may wish to use.
Project support: corporate facilities to help the project managers in areas such as risk management, stakeholder management, scheduling and so on.
Training: coordinated training, with follow-up support to make sure that all project managers speak the same language and adopt the same philosophy.
Software and systems: for planning, resource allocation, management of issues, risks and changes, for communication and project control.
Corporate data: to guide project managers when estimating new projects.
With the right management these corporate facilities will not add to the overheads, but actually save project management costs. These facilities form the QA (or Governance) environment, and will increase the chances of every project delivering its business benefits.
If your organisation doesn’t have all of these support facilities do not despair, as long as you strive to create a quality environment then you may still have a quality project.
If QA is concerned with creating a management environment, then quality control (QC) is concerned with making sure that the environment is working, and that the project is going to produce acceptable intermediate and end products (which in quality management is the term often used instead of ‘deliverables’).
It is too risky to wait until the end of the project to carry out the first check on the acceptability of the work. Even on a small project there will be opportunities to make sure that things are going well in terms of quality. Remember, from your customer/sponsor’s point of view, getting the right thing slightly late is probably more desirable than getting the wrong thing on time.
A project quality plan will contain a section where you can spell out the ‘testing’ methods you will use to make sure that things are being produced correctly, and this is described below, but here is a simple example of intermediate products.
For example, if your project is to carry out some research for your boss, and put the results into a short report so that the boss can take some action over, say, email security, don’t wait until you publish the report to find out if it is what is required. There are at least two intermediate milestones in this project that you can use to get checks of quality, as follows:
Report headings approved: almost as soon as you start draw up the structure (just the section headings) of what you intend to produce, and get the boss to approve it. The report should not contain any surprises in its structure, so get the structure approved at the outset.
Emerging findings approved: as soon as you have collected your data, and analysed it, you can book a short meeting with the boss to approve your initial or emerging findings; it would be unfortunate if you completed a report but missed something that was vital to your boss, so get early approval of your approach.
Final report published: by this stage the publication should be a triumph! Seriously, most of the surprises and misunderstandings will have been dealt with in a low-key manner.
There is obviously a strong echo of milestone planning here and this is exactly where milestones pay their way. In the quality plan you can set out how and when you will get approval for your intermediate products.
The project quality plan
This is not a plan in the meaning of a schedule, but is a collection of management documents that, when added together, improve the chances of a specific project delivering its business benefits. Quality planning is undertaken when the project schedule has been produced. This means that the project manager can now see the detail of how the project objectives and scope will be delivered and all final and intermediate products (deliverables) have been identified.
There are four possible sections in the quality plan. They are all optional, as not every project needs all of the standard sections.
The sections are:
- Quality targets
- Product review method
- Approaches to be used
- Implementation strategy
The detailed project quality plan sections will include the following:
These must be identified in conjunction with the customer/user/sponsor. In fact it is the user/customer who owns the priorities and measurements that describe the quality targets. The quality targets can be divided into three main categories, namely time, cost and scope (which, in this context, can be called ‘fitness for purpose’).
The customer must prioritise between these three categories, and it should be realised that if one of these categories is squeezed then the other dimensions will be affected. Measures for time and cost can be defined fairly easily, but scope needs more care.
The measures for fitness for purpose can be defined using the acronym FURPS, as follows:
Functionality: what does the customer need the new service or facility to do for them and in what priority order?
Usability: how much work might the customer be willing to do to learn how to use the new facility? How much training is acceptable?
Reliability: can the customer accept a period of breakdown of the new service? Does this vary in daily or weekly or monthly cycles? Are some parts of the new service more critical than others?
Performance: how quickly must the new facility perform either in raw time terms or in terms of effort to accomplish a business transaction?
Serviceability: how much will the customer be prepared to spend in keeping the new facility running? How often will maintenance be required? If it does break down how quickly must it be fixed? Will the customer wish to look after the maintenance themselves?
The various dimensions of fitness for purpose, as defined by the customer, should have clear measures identified as part of their definition. The dimensions should also be prioritised, again by the customer.
Product review method
This is the detailed description of how you will get your intermediate products approved. You can identify who will carry out your checks, when, and even how it will be done if there is a particular method to be used. For example, at one extreme you may have to call in an external testing authority to pass something as acceptable, or it may be as simple as a desk check by one of your colleagues.
Approaches to be used
In this section the sponsor and project manager agree on the regulations, guidelines, standards and techniques that will be employed on this project (for example, Health and Safety Laws, Government Regulations, Union Agreements). If a company standard is not to be followed then this must be discussed, agreed and documented.
This section may not apply to every project. However, where this is a factor then the approach to implementation must be documented here. The reasons for strategies such as ‘parallel runs’, or ‘pilot Implementations’ must be given, together with any extra costs or risks associated with such approaches. The effect of such strategies may have on the achievement of business benefits must also be spelt out here.
These may give rise to extra activities to be incorporated into your schedule, with their associated resources and costs. It would be foolish to identify extra activities and then not carry them out because they were not in your schedule. Remember, some of your ‘independent checkers’ may have busy lives of their own, so you must plan in advance, and maintain their involvement in your project just like any other key resource.
The quality plan will provide proof to all interested parties that you are not driven solely by the time clock, but that you have taken due notice of the quality requirements of your customers.
If your project has particularly important requirements for a quality outcome then this must be defined at the outset and an environment created within which it will be likely to be achieved.
If you are planning to have some of your intermediate products checked by a qualified person, then this checking should be identified at the outset, and built into the project schedule.
During project definition identify the corporate QA environment
Make sure you are fully aware of regulations, standards and so on which will affect your project.
During project definition identify your project’s specific quality management requirements
Identify targets and measures for quality, and agree them with the sponsor.
During project planning make sure you incorporate the quality plan activities into the schedule
…and make sure you inform and mobilise the key players.
Review the efficacy of the quality plan at each project review point
…and make sure that the quality checks are not unduly driven by the timeclock.
These links to the Praxis web site explain how the concepts introduced in this chapter can be applied to projects that involve more people and more complex relationships.
An article explaining the Praxis approach to quality (and it doesn’t actually recommend dropping quality!!)
A group of topics relating to the creation of a quality environment.
An explanation of assurance on medium complexity projects and programmes.
An explanation of planning on medium complexity projects and programmes which incorporates quality planning.
An explanation of control on medium complexity projects and programmes which incorporates quality control.
Thanks to Mike Watson of Obsideo for providing this book