In this chapter, we will discuss creating, updating, and releasing a Quality Management System (QMS). We will also learn which teams the QMS is created for. For some, not only might QMS represent a new word, but its purpose might be unfamiliar, as well. If that’s the case for you, it is recommended that you read about QMS from a CMMI appraisal perspective (see Chapter 6) because that will make it much easier to understand in the context of this chapter.
QMS is the combination of the policies, processes, templates, checklists, and guidelines which are used on a daily basis by employees or staff to create the software products/applications delivered.
4.1 Who Is QMS for?
To create the QMS for our employees and organization, we need to assess all the teams for which processes are needed. In fact, we have to create this for all the teams that are involved in delivering the software product or application.
A question could come to mind here: “Who will create the QMS?”
In earlier chapters, we discussed the SEPG and SQA/quality groups that will drive the process initiative cum compliance as a team in the organization.
Ownership of QMS resides with SEPG group to create, update, and release QMS to all the employees/staff.
Another question that might come to mind is this: “When does the SEPG group initiate the creation of the QMS?”
The answer is simple. It does so before we start building the software products or applications.
Also, the act of creating new processes or updating existing processes is initiated when an organization wants to implement CMMI practices. (This was discussed in Chapter 4 in the gap analysis exercise, where existing processes were reviewed against the CMMI model. After gap analysis, we come to know about the processes which are required to be created, both new ones and some existing ones that need to be updated or modified.)
Here’s the most important point about QMS: all the processes must suit the need of your delivery and support teams, or else these processes won’t be used and the expected results won’t be achieved.
Hence, the SEPG team’s main responsibility is to always identify the opportunities which could be analyzed to improve our processes.
Let’s examine what goes into creating a QMS.
As stated in the model, we have to establish the organization’s quality goals and objectives.
These quality goals and objectives set the organization’s business objectives. For example, one goal is to provide on-time delivery of our software product/application to our clients.
Hence, as per the model, we need to define goals and objectives for the following teams:
Software development
Software maintenance
Software engineering process group (SEPG),
Quality Group
Training Group
However, organizations can have goals and objectives for their other teams/groups which are supporting or involved in the software product/application delivery.
So, who initiates the goals/objectives exercise, and who are all the parties involved in creating it?
The SEPG group has to initiate this important exercise with senior management first, so it can identify the key goals that management/leadership team wants to set for the business, delivery, and support teams.
This exercise with the senior management is called a goal question metric (GQM). It helps to identify the business goals and objectives.
4.2 Interpreting a Goal Question Metric
If we have a goal for delivering on time or improving the delivery time, then we may need to ask the question, “What needs to be done or achieved to deliver on time?”
Once the way to achieve the goal has been identified, we need to link it with a metric to measure and assess goal accomplishment (see Figure 4-1).
Figure 4-1. A snapshot of a sample GQM
Goals would be communicated by senior management for software delivery/ engineering teams, SEPG, and the quality and training groups.
Once the goals/business objectives are communicated, the SEPG team shall help in defining the associated metrics/measures to achieve them. The SEPG team shall hold a meeting with the delivery and functional team heads to discuss the required metrics/measures, their unit of measurement, data source, computation formula, frequency of data collection, and so on (see Figure 4-2).
Figure 4-2. A snapshot of a delivery team (sample) business objective with metrics
Note
In the Target Range column, Min Value and Max Value have to be derived from past projects’ performance data in order to determine the Measure for Schedule Variance.
If performance data for past projects is not available or the organization has just started its operations, then the organization can analyze available industry standards/benchmarks for their identified measures.
If an organization cannot find suitable standards, then it can define or set its own target range for each metric/measure to start with. After a period of time based on the observed performance, Target Range (Min Value and Max Value) could be updated or improved.
Business objectives and associated metrics/measures may vary from organization to organization. Hence, each organization can define its objectives/measures based on its needs (see Figures 4-3, 4-4, and 4-5).
Figure 4-3. A snapshot of the SEPG team (sample) business objective with an associated Measure
Figure 4-4. A snapshot of the quality/SQA team (sample) business objective with an associated Measure
Figure 4-5. A snapshot of the training team (sample) business objective with an associated Measure
By following the preceding sample snapshots of business objectives and measures, an organization (or its teams) can define its own relevant objectives and associated metrics/measures.
4.3 Creating Policies and Processes
We need to initiate the creation of policies and processes (e.g., procedures and SOPs). Once the GQM, business objectives, and metrics/measures exercise is done, the SEPG team will focus on the creation of policies and processes. (As pointed out in the earlier chapters, the SEPG and quality teams will drive the creation of QMS (i.e., its policies, processes, templates, checklists, guidelines, etc.—some organizations combined their SEPG and SQA teams).
As per the CMMI, the policies of each process are important. Hence, first policies shall be created, as these policies help organizations seek the required commitment from the employees/staff to follow the process approach in executing project/product delivery tasks (see Figure 4-6).
Figure 4-6. A snapshot of (sample) policies, for reference purposes
If an organization has planned for a CMMI level 3 implementation, then policies have to be created for all 18 process areas. If an organization has planned for a high maturity CMMI level 5 implementation, then policies have to be created for all 22 process areas.
In the preceding snapshot, the following columns are covered:
CMMI process areas, as per the CMMI model
A QMS process name, which is given to the process that will be followed by the organization
Also, note that serial no. 1 includes three process areas in the “CMMI Process areas” column; however, the “QMS process name” column has only one process mentioned. This is because the project management process is defined by referring to the three process areas.
Hence, it is not necessary that we also create 18 (level 3) or 22 (level 5) process areas. We can group two or three CMMI process areas into one process.
Now let’s look at the processes which we need to create as part of the QMS based on the CMMI model (see Table 4-1).
Table 4-1. The QMS Processes to Be Created
Sl No. | CMMI Process areas as per model | QMS process name within organization | Remarks |
|---|---|---|---|
1 | Project Planning Project monitoring and control Integrated project management | Project Management Process | Three CMMI process areas can be grouped together into one QMS process (i.e., Project Management) |
2 | Risk Management | Risk Management Process | |
3 | Requirements Management | Requirements Process | Both Requirements Management and Development process areas could be grouped into one QMS process (i.e., Requirements Process) |
4 | Requirements Development | Requirements Process | |
5 | Technical Solution | Design Process | Here, one Technical Solution process area is covered in two different QMS processes |
6 | Technical Solution | Code & Unit Testing Process | |
7 | Product Integration | Build and Release Process | |
8 | Verification | Review Process | |
9 | Validation | Testing process | |
10 | Configuration Management | Configuration Management Process | |
11 | Measurement & Analysis | Measurement & Analysis Process | |
12 | Process & Product Quality Assurance | Quality Assurance Process | |
13 | Decision Analysis & Resolution | Decision Analysis & Resolution Process | |
14 | Organization Process Definition Organization Process Focus | Process Management Process | Two CMMI process areas can be grouped together into one QMS process (i.e., Process Management) |
15 | Organizational Training | Training Process | |
16 | Supplier Agreement Management | Supplier Process |
4.4 Creating Templates, Checklists, and Guidelines
For each QMS process, there will be associated templates, checklists, and guidelines which need to be created. Table 4-2 covers some sample items for a QMS implementation.
Table 4-2. A Sample QMS for Level 3 Practices
Sl No. | QMS process name within organization | Template(s) | Checklist (s) | Guideline(s) if any |
|---|---|---|---|---|
1 | Project Management Process | 1. Project Initiation Note 2. Project Kick Off 3. Integrated Project Plan 4. Estimation 5. Work Break Structure (excel) or Microsoft Project Plan (MPP) 6. Status Report 7. Minutes of Meeting 8. Action Log 9. Project Closure Report 10. Project Lessons Learned | 1. IPP Review Checklist 2. Milestone Review Checklist 3. Project Closure Checklist | |
2 | Risk Management Process | 1. Risk & Issue Log | 1. Risk Identification Checklist | |
3 | Requirements Process | 1. Requirements Understanding & Clarification 2. Business Requirement Specification 3. Software Requirement Specification 4. Requirement Traceability Matrix 5. Change Request Log/Tracker 6. Change Request Form | 1. Requirements Elicitation Checklist 2. Requirement Review Checklist | |
4 | Design Process | 1. High Level Design 2. Low Level Design 3. Make Buy Reuse Analysis Report 4. User Manual | 1. Design Review Checklist | |
5 | Code & Unit Testing Process | 1. Unit Test Plan 2. Unit Test Case 3. Unit Test Report | 1. Unit Test Plan Review Checklist 2. Code Review Checklist | Coding guidelines—.net, java, C, C++, PHP, and so on; an organization can create these based on its project work |
6 | Build and Release Process | 1. Build Note 2. Release Note 3. Product Integration Plan | 1. Build Review Checklist 2. Final Delivery Checklist | |
7 | Review Process | 1. Review Report To log the Review comments | 1. Review Checklist To add the comments which must be verified during the reviews | |
8 | Testing process | 1. Test Plan 2. Test Case 3. System Test Report 4. Defect Analysis | 1. System Test Case Review Checklist 2. System Test Plan Review Checklist | |
9 | Configuration Management Process | 1. Configuration Status Accounting | 1. Configuration Audit Checklist | |
10 | Measurement & Analysis Process | 1. Quality Objectives 2. Project Metrics Report 3. Department wise Metrics Report i.e. SEPG, SQA & Training | ||
11 | Quality Assurance Process | 1. Annual Quality Plan 2. Audit Plan 3. Audit Report 4. IQA Summary Report 5. List of Auditors 6. Process Compliance Report 7. SQA Monthly Summary Report 8. SQA Metrics Report | ||
12 | Decision Analysis & Resolution Process | 1. DAR Template | 1. DAR Guidelines Provides guidance to perform DAR by using various methods | |
14 | Process Management Process | 1. SEPG Plan 2. SEPG status report1 3. QMS Release Note 4. Pilot Plan 5. Deployment Plan 6. Process Improvement Request Form | 1. Tailoring Guideline Provides guidance and informs staff at which phases tailoring is allowed | |
15 | Training Process | 1. Annual Training Plan 2. Monthly Training Plan 3. Employee Skill Record 4. Training Request Form 5. Trainer Database 6. Trainer Evaluation Form 7. Attendance Sheet 8. Training Needs Analysis 9. Training Feedback Form 10. Training effectiveness and evaluation 11. Training Closure Form 12. Training Metrics | ||
16 | Supplier Process | 1. Vendor Selection Note: Remaining templates would be similar to those used for monitoring the projects; please refer to Sl No. 1 | 1. Vendor Selection Checklist |
For implementing CMMI level 4 and 5 practices following QMS- processes, templates, checklists and guidelines will be created (see Table 4-3).
Table 4-3. A Sample QMS for Level 4 and 5 Practices
Sl No. | QMS process name within organization | Template(s) | Checklist (s) | Guideline(s) |
|---|---|---|---|---|
1 | Quantitative Project Management | 1. Project Quality and process performance objective 2. Control Charts 3. Prediction Model | 1. | 1. Guideline to evaluate alternatives for selecting the subprocesses 2. Guideline to select measures and analytic techniques |
2 | Process Performance | 1. Process capability baseline 2. Process performance model | 1. Guideline to create process capability baseline 2. Guideline to create performance model 3. Definition of measures and their rationale for selection | |
3. | 1. Pareto Analysis 2. Fish bone Analysis 3. 5 Why's | 1. Guideline to perform RCA | ||
4 | 1. List of improvements 2. Improvement proposal analysis 3. Improvement implementation plan and tracker 4. Improvement validation reports | 1. Guideline to select the improvement areas and their rationale for selection |
Until CMMI level 3 is achieved, the following QMS templates, checklists, and guidelines will be created. These might be sufficient to have from the implementation perspective, but each organization may create less or more of these items, based on its simple or complex work nature.
4.5 Updating QMS and Release QMS
In the preceding section, we learned, as part of the QMS, which processes, templates, checklists, and guidelines need to be created. In this section, we will learn about updating and releasing the QMS.
You might wonder whether it is important to know when the QMS gets updated, or why the need arises to update it.
4.5.1 The First Update
Before CMMI implementation, every organization always has some of the processes which it follows to deliver its software products or applications; however, when an organization decides to implement CMMI model/practices, the QMS gets updated in a full-grown manner.
4.5.2 The Second Update
Once the QMS is functional and processes, templates, checklists, and guidelines are in use by the staff/employees, there are always going to be improvement requests which will be reported by the staff for SEPG analysis. This is because it is only by using the processes that we can judge whether the processes created are useful and adding value. These improvements could be small or big in nature. For example, even a very small change required in one template or one checkpoint needs to be added in a checklist. In other words, it may lead to changes in current processes, templates, checklists, and guidelines, or it may be required to create the new ones.
After analyzing all of the received process improvement requests, the SEPG team will work on them and eventually update the QMS. It is an important exercise, and it may require a lot of effort by the SEPG team and other staff members who get the opportunity to work on the QMS update. As a result, the organization/staff receives the improved processes, templates, guidelines, and checklists.
4.6 Releasing the QMS
Once the work is done on updating the QMS, the time arrives to release the update version to the employees/staff.
The QMS release is done in a planned manner by the SEPG team, with the help of the SQA team. Some processes which are updated or created new get piloted before their release because it is important to know whether or not they will work. This prevents a lot of defect generation, so the defects are never passed into the system. This also saves lot of effort and rework in correcting such defects.
To communicate about the impending QMS release, the SEPG shall update one QMS release form. This form will contain information about what has changed from the previous version of QMS, as well as what has been added to the new version of the QMS. For example, the previous version of the requirement process was v1.0; after the update, v1.1 will be released. The same applies for templates, checklists, and guidelines.
The SEPG has to communicate to all the employees/staff about the QMS release, even if only a few members/staff had shared the process improvement request. This will ensure that everyone in the organization is aware of how to use and follow the new processes, templates, checklists, or guidelines.
4.7 Summary
In this chapter, we learned about creating, updating, and releasing a QMS. Along the way, we also learned what will become part of the QMS as per the CMMI model, as well as which departments the QMS is created for. Finally, we learned when the QMS gets updated and what goes into the QMS release.