The Confusion Between Software “Metrics” Vs “Matrix”

When I was studying in class 10^th, I asked my English teacher a very basic question about why two words in English sound the same but mean different. That time, we never had a separate subject on “phonetics” and I was quite unaware of this part of the English subject then. She smiled and very smartly told me that – “English is a ‘funny’ language” and went away! I was amused by her answer the whole time. Only later I learnt that in English there are so many words with a spelling, that are used “as per the context” to mean different than their similar sounding words with a different spelling.

In quality assurance and in general in project management, many testers and project managers make the same mistake with a misunderstanding and confusing these 2 words – “Metrics” and “Matrix”. They use them interchangeably!

• Metrics in the quality management context means “to measure” (check its meaning here - https://www.dictionary.com/browse/metric) and …

• Matrix has different meanings based on where it is applied but it has nothing to do with measurements (check its dictionary meaning here - https://www.dictionary.com/browse/matrix)

Metrics in software development helps project managers and / or quality heads to measure the health of a project at various stages of development (if correctly understood and applied).

How we can use various metrics (or parameters to measure the project health) is a different topic altogether. I will talk about the various aspects of these in a separate post.

But let us get this correct. We always use the word – “Metrics” and NOT “Matrix” in either project management and / or in quality assurance (or software testing).

Now, that the confusion is clear, let me add my 2 cents on why “Metrics” becomes important for projects. There is a famous quote in project management which is – “If  you can’t measure it,  you can’t manage it”. Although the quote is not completely correct, it still has an important message for us to understand how measuring something over a period can be so much helpful in myriad of ways.

Metrics or “to measure” something important in a project or quality assurance can help the managers to keep track of the project health or project progress or testing progress. 

Many project managers simply apply a set of metrics because somebody told them to (as it is an industry best practice) or simply because they read about that ‘metric parameter’ in a blog or a book or a reference without understanding a gamut of impacts of the parameter – “for their context”.

Hence, I always recommend an executive team or management to do the following when it comes to metrics:

1. Always, and always… First, understand well your “own business / project context”.
2. Based on #1 above, identify your “goals” or “objectives”. These can be different when it comes to a business and different for a project with a definite timeline.
3. To achieve the identified goals / objectives, identify the simplest of metrics (maximum 3) that “can be measured” using simple tools and with very less efforts in a consistent basis. If you can automate metrics collection, there is nothing better than that.
4. Add additional metrics over-time as you understand the business (or project) context in detail and then design the simplest and most appropriate dashboard for continuous tracking purposes.
5. Finally, evaluate the “effectiveness” of a metric and do not hesitate to remove or modify a metric to suit your “own business / project context”.

- Written by Anand Nanavati (SupraDigit Solutions)