Section 7.3. Planning Quality

7.3. Planning Quality

The best way to ensure the quality of the project deliverables or results is to plan quality into each step. We've discussed this already to some degree, but let's take a few minutes here to review where this occurs in the defining, organizing, and planning stages.

7.3.1. User Requirements

We discussed user requirements in Chapter 6, so we won't revisit that material, but we will add some important distinctions to it. Earlier we talked about the difference between quality and grade. We said that quality has to do with the number of errors or defects in the final product and grade has to do with the functionality of the results. In the user's mind, the two may be exactly the same thing or the user(s) may have difficulty discerning the difference between the two. What matters is that you and your project team understand the difference between quality and grade and can work effectively with the users to define user requirements that are achievable by the project and project team.

7.3.2. Functional Requirements

Functional requirements describe what the project's deliverables must do. It includes statements and metrics about features, performance, speed, ease of use, workflow, usability (interface, look and feel), data or input requirements, access and security requirements, and output requirements (reports, exports). These are the things the user typically cares most about and these are what create the user's initial impression of quality. If the software product cannot produce reports and all the user cares about is reports, the functional requirements were incorrect or poorly developed (or the user, despite repeated rounds of interviews and questions, failed to mention reports as a "must have" requirement until the project was delivered….). How the reports are generated would fall under the technical requirements, which are derived from the functional requirements.

7.3.3. Technical Requirements

Technical requirements follow functional requirements. After clearly defining functional requirements for your IT project, you and your team can develop the related technical requirements. These can include all necessary requirements and specifications that allow your project team to develop the project's deliverables. These typically include things such as specific hardware, software and network requirements, error handling and logging, capacity, redundancy, reliability, interoperability, scalability, portability, security, storage, and monitoring, among many others. Clearly defining technical requirements in an IT project can only be done after the IT project is initially defined and organized and requirements (including user, functional, business, and others discussed in Chapter 6) have been gathered, compiled, and agreed upon. You may find that you can begin creating technical requirements earlier in the planning process and proceed in parallel with the other planning processes, but make sure you don't get ahead of yourself. Creating technical requirements for requirements that are not yet locked in or agreed to/approved can cause a lot of wasted time and rework.

7.3.4. Acceptance Criteria

We discussed developing acceptance criteria in Chapter 6. These criteria are typically used between a vendor and a client as a method of specifying what makes a deliverable acceptable to the client. This, in turn, is often used by the vendor as the trigger for billing the client for that deliverable or phase of the project. Acceptance criteria specify the essential elements and conditions for the project's deliverables to be accepted by the user. The definition of acceptance criteria clearly can increase or decrease the cost of quality. While you and your IT project team want to deliver the highest possible quality within the requirements of the project, you should use caution here when developing acceptance criteria with the user/client. Overengineering acceptance criteria can mean having to deliver more quality than is needed and at a premium. If ten errors in a million transactions are acceptable, don't sign up for five errors in a million. The incremental cost of reducing errors from ten to five could be huge and it's not required for the project to be successful.

7.3.5. Quality Metrics

Quality metrics are specific, measurable, quantifiable measurements related to the quality of the project. Metrics leave no room for guessing. For example, rather than asking whether the product shipped on time, which might yield a yes/no answer based on someone's perception, you would ask what day and time the product shipped. With an IT project, then, you might specify how much downtime is acceptable or how much uptime is required, or you might specify the failure rate threshold or the average bandwidth or speed that must be met. Metrics are used in both the quality monitoring and quality testing phases of the project, so defining them during the planning phase makes sense. As you develop additional project details, you may revise your quality metrics.

7.3.6. Quality Checklist

The term we use at this point in the project planning is quality checklist, which is a list used to verify that a required set of steps has been completed. Later in this book we'll use the term completion criteria when we begin talking about the specific tasks in the project. Completion criteria are usually listed (as a checklist) within the notes section of each task to ensure that each task was completed according to requirements and specifications. We can use the terms quality checklist and completion criteria interchangeably, but for our purposes, the quality checklist at this point will be much higher-level (less detailed) than the completion criteria you'll develop later in your planning process.

Applying Your Knowledge

These aren't the only tools at your disposal for managing quality in your project, but these are some of the most commonly used. The key is to determine what constitutes a quality result and figure out which processes and measurements will get you there. If you have some analyst types on your project team, this can be a good area to assign them tothey'll relish the opportunity to develop systems and metrics to deliver quality, but watch that they don't overdo it. Keep in mind the tradeoff between quality and time/cost to make sure your project hits the sweet spot.