Git as Quality Management Tool

Introduction  

Since 2021, our company has introduced a certified quality management system (QMS). QM systems help to secure the future of a company by continuously evaluating the context of the organization and acting accordingly to improve its own standing within this context.

When we started installing the QMS in our company, we were consulted by the QAS Company who helped us to get familiar with QM and introduce a certified QM system within our company. During the discussions with the experts of QAS it was soon found, that getting a QM certificate is one thing, but ideally QM should really be lived by the employees as well. Having a dead folder of handbooks, templates, proofs, etc. in order to “survive” the yearly audit should not be the goal of this whole exercise.

It soon turned out, that a lot of requirements within a QM system can quite nicely be mapped to how developers work in their daily life anyways (you might call it DevOps?). For example, the QM standard demands to control documents, i.e. it needs to be controlled who, what, when something in a document has been changed. Other topics concern about quality goals or risk management. This article is about how we utilized Git and GitLab in order to implement our QM system. Of course, similar DevOps tools could be used instead as well (e.g. Bitbucket).

Before getting started it should be mentioned that our approach on QM probably only fits to companies who solely do software development. So eventually, only very small to mid sized software houses can apply those ideas as well. As soon as non-developer employees are involved, applying these processes might not work. A QM system though, is always certified on a certain scope of a company. Restricting the scope to software development would probably also exclude employees working e.g. in marketing or business administration.

QMS documents inside a Git repository  

The QMS standard requires us to control and maintain so called documented information. Documented information is defined as information that must be controlled and maintained by an organization and the medium in which it is contained.

Controlling these documents basically means that rules need to be determined and implemented in order to create, review, approve, update and distribute those documents. A perfect job for Git! Git will allow us to control all our documented information as required by the QM standard. The Git repository could for example contain the following main folders:

• A - QM Employee Guide
• B - QM Process Descriptions
• C - QM Operating Instructions
• D - QM Forms and Checklists
• N - QM Proofs

The folders A - C basically build up the QM handbook which is a customized description of how the company implements its QMS. It is advisable to write the handbook in a plain text format (such as Markdown, reStructuredText or LaTeX) such that changes can easily be tracked via Git.

Folder D - QM Forms and Checklists contain a collection of required forms and checklists (surprise! 😄). Those documents might not always be readable as plaintext as for some tasks within QM, spreadsheets come in more handy (e.g. for supplier evaluation, risk matrix, cost estimation, etc.).

The folder N - QM Proofs would contain evidence documents for repeating tasks that need to be done during the QM cycle. Typically one will find filled out template documents of the D folder, e.g. supplier evaluations, training protocols, customer satisfaction evaluation, risk matrix etc.

Sensitive documents  

The Git repository for the QM system should be accessible to all employees such that they have access to all necessary information which they need to know. Granting access to the staff will also encourage them to actively participate in quality management.

However, there are exceptions where management and employees do not want to expose information to all colleagues. For example, employees might not want other colleagues to know too many details about their competencies. Thus, the skill matrix could be excluded from the repo. Another example might be the management review, which provides a regular overview of the overall state of the company.

Which documents should be excluded from the repository is very individual for each company. For documents which concern personal information about employees it needs to be decided together with all colleagues, how to proceed with them. For sensitive information concerning the company, the management has to decide whether they can be made public to the employees or not.

In such cases, another solution needs to be found. One simple approach is to keep these exceptional documents in a personal QMS folder (ideally with the same folder structure).

How to control those documents  

As already mentioned before, documents concerning the QM system need to be controlled such that it is always known who created, reviewed, approved or changed those documents (and when it was done). All of these requirements are basically fulfilled right away with a Git repository.

The repository however needs to be configured correctly. To allow all employees to access and participate in QM, everyone should have read and write access to the repository. Though it should be avoided that everyone pushes changes in an uncontrolled way to the repository. That can easily be achieved by the following rules:

1. The only branch where employees find the currently valid QMS snapshot is the main branch
2. Only the QM officer (QMO) or QM advisor (QMA) are allowed to modify this branch (i.e. main is a protected branch)
3. Colleagues can participate by branching from main and then creating a merge request into the main
4. QMO or QMA can review, approve and then finally merge the requested changes into the main

Milestones, issues and labels  

Git repositories do not only allow to save documents and track their changes. They typically come with features such as milestone management and issues. Labels can be freely created and assigned to issues. These features can also nicely be mapped and combined to control processes of QM.

Milestones - the quality goals  

During a software project, milestones would be used to describe the implementation of a new complex feature. Typically, the feature is not easily implemented and needs several issues (or tasks) to be completed in order to achieve the milestone.

In QM, a milestone is the equivalent of a quality goal. From the risk analysis we often can derive new or repeating quality goals for the company. These help us to keep the company competitive and on a healthy state. Some quality goals which we defined for our company are for example:

• Training and education of employees
• Keep our IT environment up to date
• Customer satisfaction

Each milestone then can be filled with issues that need to be taken care of in order to fulfill the set quality goal.

Issues, issues and more issues  

Git issues in QM can basically be used to assign and track the status of any task which is necessary for QM. As just mentioned, an issue could be created to complete a quality goal (the issue would then also have a milestone assigned), but does not necessarily require an assigned quality goal.

As an example, issues that belong to the quality goal “Training and education of employees” could sound like this:

• Discuss and decide for next years training for John Doe
• Attend training about TypeScript
• Evaluate effectiveness of TypeScript training

Other issues in QM might not fit to any of the planned quality goals, but anyways need to be taken care of. In this case, there is simply no milestone assigned to the issue. Some exemplary issues which did not fit into one of our quality goals are for example:

• Check first aid box in the office
• Create offer for customer project X
• Enhance QM handbook concerning cyber security
• Ensure that devices have been e-checked

There is a huge variety of tasks in QM which need to be taken care of, such as:

• A measurement that is necessary to comply with a regulatory rule
• A suggestion, finding or non-conformity which was found during an internal or external audit
• Evaluation of a measurement to determine how effective it was
• Customer complaints
• Personnel administrations (feedback meeting, onboarding or offboarding an employee)
• Controlling processes which are defined within the QMS
• etc.

Some of these issues will come up quite regularly. In those cases it might make sense to prepare issue templates. The templates allow users to quickly create a new issue for a certain topic that needs to be taken care of. As an example, in our QM system we defined a process to control the workflow for project acquisition. The process is called “Create Jobs” and the corresponding issue template is as follows:

# Create jobs

A customer asked us to support in a new project or to continue an ongoing project with us.
The issue will guide us through the process "8-2-02 Create jobs" of our QMS handbook.
Aim is to guide through the process from gathering the requirements, clarifying feasibility to
creation and adjustment of the offer.

## Project overview

*Here comes a brief description about the request that was coming in. What is
the project about?*

## Necessary steps

- [ ] Determine customer requirements
- [ ] Check feasibility (in terms of knowledge, capacity, legal regulations, etc.)
- [ ] Estimate the effort
- [ ] Create and send out offer
- [ ] Follow-up with customer and revise offer
- [ ] Document outcome of offer
- [ ] In case customer ordered, adjust capacity plan
- [ ] In case customer ordered, add issue for a recap meeting

When a customer approaches us with a new interest in an offer for a project, we can now simply use this template which will guide us through the process of preparing and sending out an offer. Other useful templates can be created and used for reoccurring tasks, such as:

• Employee feedback meetings
• Customer feedback meetings / Project recaps
• Onboarding and Offboarding of employees
• Training of employees
• Effectiveness evaluation of measurements

As one can see, there is a huge variety of different issues that can occur in a QM Git repository. It is advisable to have someone assigned to each of the issues and that an appropriate due date is set. To quickly be able to find open or closed tasks, it is even more important to define and set appropriate labels to each of the issues.

Labels  

In order to improve the overview of existing issues, labels should be defined and used. Meaningful labels will allow the QMO and QMA to quickly filter and find relevant open or closed issues. In our QMS system, we make for example use of the following labels:

Summary  

As we have seen, using a Git repository as the basis for a QM system is quite useful for:

• Controlling and maintaining documented information
• Representing quality goals
• Documenting measurements and their effectiveness
• Creating and assigning QM relevant tasks (issues)

Essentially, the whole QMS could be managed in one QM repository, even though it is advisable to keep sensitive and confidential documents outside of this repository.

Requiring the employees to use Git though is not very intuitive for employees who don’t code. Hence, such a QM system is only viable in software development companies.