We have previously mentioned time, cost and quality as key factors in project management. Assessing performance in terms of time and cost is relatively easy but quality is harder to define and measure. A high quality project may be one whose outputs:
- Meet the specification
- Meet stakeholder requirements
Or alternatively one whose outputs:
- Are fit for purpose
- Satisfy the stakeholders
These don’t all mean the same thing. The chances of the initial specification being correct or indeed of the stakeholders being able to adequately articulate their real needs are slight. We warned earlier of the dangers of hitting the targets but missing the point. Managing quality is about keeping an eye on the bigger picture and aiming for outputs that are in line with the second definition.
Elements of managing quality within a project include:
- A formal project management framework
- Adoption of recognised standards where they exist
- User acceptance procedures
- Impartial evaluation
Many projects have some form of external quality assurance role built into the project structure. This could be external to the organisation e.g. a third party consultant or simply external to the project. Ideally such an assessor should be impartial and have experience of project management. Remember this person is only evaluating quality the project manager is responsible for quality.
For each phase of the project you are likely to need to define acceptance criteria that allow you to determine whether the deliverables have been produced to an acceptable standard.
There could be many elements to the acceptance criteria and it is likely that there will be required quality standards for many sub-products in addition to the final project outcome. As an example, a project to streamline a business process may have as sub-products: a set of paper forms for capturing data, a computerised information system with requirements for each data entry screen and a set of report outputs.
Acceptance criteria can take many forms, but a few examples could be:
- Target date
- Functions required
- Performance levels
- Running cost
- Security levels
- Level of skill required to operate
User acceptance testing
In many projects, particularly those that involve system implementation or process review, the assessment of product quality can be made via a formal user acceptance test (UAT).
A formal UAT involves defining a ‘script’ that gives an end-to-end test of the business process or system. UAT is usually an iterative process rather than a one-off as users work through the script and document any errors or issues. When all the issues are resolved the test is formally signed-off. When implementing a system the UAT scripts are likely to be largely based on the test scripts used to select the system in the first place.
Defined and measurable acceptance criteria and formal sign-off procedures, based on fitness for purpose, are important if you are to avoid the scope-creep associated with users trying to introduce ‘nice-to-have’ features at the last minute. Involvement in UAT also helps to give users a feeling of ownership and to manage their expectations of the project. An outline of suggested roles and responsibilities can be found in our user acceptance testing guidance notes.