Skip to main content

The Confusion Between Software “Metrics” Vs “Matrix”


When I was studying in class 10th, 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)
Labels:
Location: Mumbai, Maharashtra, India

Comments

Post a Comment

Popular posts from this blog

Focus on Verification (V&V) to Transform Your Organization

When I was a quality manager in my earlier job in an MNC (Multi-National Company), a lot of my team members were quite misinformed about the “Power of Verification” in a software development process. I went through a lot of reflection around my own experience working on multiple projects related to doing “software verification” exercises. I gained profound understanding of how organizations can gain immense benefit just by understanding the true power of this activity (if done correctly). For the uninitiated, let me give a brief understanding about what “Verification” means. As part of ensuring quality of any software, the whole development process can be split into 2 simple parts – Verification & Validation To put this simply, “Verification” is always done before software code is developed & “Validation” is always done post development of software code. A “Verification” activity means, doing detailed analysis and reviews for – Customer Requirements Software Architectur...
Post a Comment
Read more

Understanding "Emotional Intelligence" (or EQ) to Build Great Teams

Let me tell you… This has been my favourite subject of all! Not that I may want to do research in psychology but understanding people and how they behave so differently in different situations - just puts me in awe! So… What is EQ? A very nicely written post from psychcentral ( Psych Central Link ) aptly explains EQ as well as its 5 categories (or components), which are – Self-awareness Self-regulation Motivation Empathy Social Skills With even more detail, positivepsychologyprogram ( Positive Psychology Program Link ) provides even more details with the 4 dimensions of EQ, which for ‘emotions’ are – Perceiving Using Understanding Managing For further exploration on EQ, starting with Wikipedia ( Wikipedia Link ) is a great idea, since it also talks about the 3 models of Emotional Intelligence (or also referred to as EQ). The above 5 categories are coming from the “Mixed Model”. I am quite influenced by the ‘Mixed Model’ than other models. It is much more comprehensive and connect...
Post a Comment
Read more

Reduce Your App Development Costs by More than 50% by "Simply Preventing Bugs"!

"Be a yardstick of quality. Some people aren’t used to an environment where excellence is expected.”— Steve Jobs Everybody loves to avoid a disaster, but there is a “proactive” effort to do activities that can prevent a disaster from happening. Most of the executives do not want to “get involved” in such “proactive” efforts, simply due to the love of fixing urgencies Or having a mindset that it’s not important.   I remember, when once I was working with the Quality Assurance team on a product. The development team simply refused to spend efforts on the most essential “unit testing” for their developed components! The intent was to release the software to the QA team as soon as possible and focus more on so-called “core development”. Over the years, looking at multitude of projects failing in-spite of highly experienced resources, reasonable time and the intent, I have uncovered that, prevention is the “Most Important” and “Ignored” part of software development. Why should we ...
Post a Comment
Read more