Project planning: Quality plan
JISC requirement You must develop a quality plan to ensure that outputs are fit for purpose and comply with relevant standards and best practice.
JISC expects you to perform quality planning and quality assurance to ensure that project outputs meet quality expectationsWhat ‘quality’ actually means will depend on the outputs the project is creating, but is generally related to:
- Fitness for purpose (generally means it ‘does what it says on the tin’)
- Adherence to relevant standards and specifications (e.g. to ensure interoperability and accessibility)
- Use of best practice methods and techniques for development
‘Fitness for purpose’ will vary with the project output. For example, if you’re developing software to enable users to perform a task, the software should enable them to perform it. However, it can also relate to how well it allows them to perform a task and factors like usability. If you’re developing a pilot to demonstrate feasibility, it should obviously demonstrate feasibility, but scalability and reliability might be other factors to consider in fitness for purpose.
Why quality and quality planning are important:
- Each output contributes to the success of the programme. Poor quality outputs will limit the programme’s success and could even cause the programme to fail
- JISC shares development outputs with the community. They need to be fit for purpose and of value to the community
- Integration and interoperability are increasingly important in ICT. Outputs need to meet agreed standards so they work together seamlessly
- JISC development is publicly funded and must provide value for money
- JISC projects should provide a lasting benefit to the community and sustainability is increasingly important. Quality is important for sustainability
A quality planning process has been developed to improve and assure the quality of project outputs - Quality expectations The programme defines the standards and level of quality expected from the project.
- Acceptance criteria The programme defines acceptance criteria for major project outputs based upon the quality expectations set.
- Quality plan The project develops a quality plan showing how it will achieve the quality expected and the quality assurance processes it will put in place.
- Implementation During the project, the outputs are developed in line with the quality plan.
- Acceptance of outputs The project submits its outputs, supported by evidence that they meet the quality expectations. Outputs are assessed against the acceptance criteria and accepted (or rejected) by the programme.
Quality expectations that apply will be outlined in the circular/ITT. The programme manager will discuss quality expectations for specific types of outputs with you at the start of the programme. Typically quality expectations will relate to fitness for purpose and compliance with agreed standards and best practice.
Acceptance criteria will relate to what you must do to demonstrate that the expected quality has been achieved. For example, the programme manager might ask for a set of interoperability test results to demonstrate that interoperability standards have been adhered to. They might ask for a report from an external evaluator that assesses fitness for purpose.
Quality and success are both good things, so how are they different? For the purposes of these guidelines:
Quality planning puts in place processes to ensure that project outputs are fit for purpose and meet quality expectationThe programme indicates the quality that is expected and acceptance criteria that must be mets. Quality planning is linked to the acceptance process. In many cases, these are related to the technical quality of outputs (e.g. technical standards and best practice used during development). The project puts in place quality assurance processes to ensure that the desired quality is achieved and tests to provide evidence. Quality planning should demonstrate that the outputs meet quality expectations and acceptance criteria in a straightforward and objective way.
Evaluation measures the success of what you set out to do. For a project or programme, this tends to relate to achievements, outcomes, what was learned, and how this changes things. For example, did the project (or programme) achieve its aims and objectives and fulfil the need envisaged at the start. How do its outcomes change our understanding how things work, what people can do, or how things can be done better. Evaluation involves people making judgements about success, but doing so using objective and systematic techniques.
Evaluation can also be applied to project outputs. Where quality planning would focus on whether the outputs meet quality expectations, evaluation might focus on issues like whether the outputs are useful, wanted by users, and liked by them. In principle an output might be of high quality and pass acceptance tests, but evaluation might demonstrate how useful (or not) it is. As with evaluating a project, evaluating an output involves people making judgements. Peer review might be appropriate to assess whether an output is useful, and surveys or focus groups to assess user satisfaction. Evaluation skills, rather than technical skills, are needed to select appropriate evaluation methods and to assess the results. Where project outputs are concerned, there may be a fine line between quality planning and evaluation, and you should decide how to use either or both depending on your outputs.
The project plan template includes a table that you should use to develop the quality plan. As JISC development programmes result in a wide range of outputs, the programme manager may adapt the template to suit the type of outputs being developed. Think through the methods you need to put in place, the testing you must do, and the evidence that will demonstrate you’ve achieved the quality envisaged
Whatever the outputs, the idea is to think through how you will achieve the quality envisaged. This will involve:
- quality assurance – putting in place the policies, practices, and procedures for achieving best practice and complying with standards
- quality control - checking that you’ve done what you expected to do (e.g. by testing).
Specify the criteria against which the quality of the output will be measured (e.g. fitness for purpose, best practice for processes, adherence to a specific standard or specification, usability, accessibility, validity, etc).
Define the quality assurance methods/techniques that will be used or reference established ones. For example, what processes will you put in place to ensure that software complies with JISC’s draft open source policy, the best practice outlined in Section X, and relevant standards.
Indicate the evidence that will demonstrate that you have achieved the quality envisaged. For example, this may involve test results, benchmarking, or successful completion of external peer review.
Indicate who is responsible for monitoring and ensuring the quality. For example, if you’re developing software, quality responsibilities might be:
- Project Manager Change control, quality of project documentation
- Lead programmer System testing quality, configuration management
- Programmer Unit testing quality
- Academic advisor Usability quality.
You are encouraged to use compliance testing tools wherever appropriateEffective tools are a valuable way of easing the construction and maintenance of standards compliant applications and data. They exist in many areas including HTML compliance, metadata maintenance, accessibility testing and conformance to SCORM standards, and viewing XML schemas. The UKOLN and CETIS websites have numerous references and UKOLN use checking tools on many of their published pages.
You are encouraged to select appropriate tools to assist with software testing and quality control. These might include tools for testing functionality, performance, usability, compliance with standards, coding, etc. The programme manager can advise. See further resources.
See the acceptance process for core project documents and project outputs
Further resources