There is a wide range of standard maturity models such as CMMI, TMMI, ^IDEALSM, etc… among others, plus some specific ones such as e.g. for data (DMM), architecture (ACMM), and project management (P3M3).

A Maturity Model is a tool used by business and development teams to measure how well the company or project is doing and how capable they are of applying continuous improvement. This is measured through qualitative data to evaluate long-term maturity and whether it is improving.

Maturity Models have been around for a long time and have often received a negative perception. Some examples include: focus on documentation and plans; certification and the levels to gain competitive advantage; focus on the levels and the assessment process; comparison between teams and companies; etc….

In this blog, I want to talk mainly about how to make a Maturity Model work and more specifically how to improve quality of delivered software and services through a Quality Assurance Maturity Model (QAMM).

One of the key starting points is that a maturity model should not be static. The focus of the QAMM should be to define concrete actions resulting from the evaluation and ensure that quality improves.

The assessment, process and levels are not an end in themselves. The resulting actions that quantitatively improve quality should be the goal. This avoids the focus being on documentation and plans. It is also important that the actions are included by the team or company, and that they are responsible for completing the task.

It is very tempting and usually faster to use a standard maturity model. The main problem is that these models are often very generic and do not address the needs of a company and thus do not lead to concrete actions. Take your time to turn a standard maturity model into one specific to the company. Best to start with the goals you want to achieve and use them to build a maturity model.

When building a company-specific maturity model it is important to keep it challenging but achievable. Feasible because it helps keep motivation high for the teams and the company. The model must be challenging to cause an improvement. This means that quality goals must be challenging. An example defect prevention and quality prediction is part of the QAMM. Another example is his technical tests are a part of the QAMM.

A final important point is what I call personnel touch and active support. Do not send via email or an intranet page the QAMM and ask them to fill it out. People see this as additional work and a lack of commitment (both from the requester and the person who has to fill it out).

Fill this out together with people, ask clarifying questions, “challenge” the scoring without overdoing it, and try to understand their challenges. When creating the quantitative actions, support and help them to do it in a SMART way.

If you are interested or need more info, feel free to contact us.