In Project Management, there is “QUALITY and QUANTITY” – Check and Analyze

“Check and Analyze,” which is what it all gives us.

After planning and acting, it’s time for reflection. In various methodologies, it is called differently: retrospective, feedback, or “lessons learned“. One thing is for sure: keeping an eye on project metrics and statistics allows you to:

• on the one hand, to verify that everything is going according to the plan and our expectations,
• On the other hand, it allows us to identify the areas with the greatest problems and predict what problems we can still expect.

The third step in the Deming cycle – “CHECK.”

The third step of the Deming cycle, i.e., “Checking,” certainly requires some experience, good knowledge of your own team, as well as a reliable assessment of the facts. Without it, it is difficult to say whether having one critical bug means that the functionalities are in very good condition, or maybe nobody tests them and it has not been possible to identify other bugs, or maybe this one error means that you cannot log into the application.

Some methods and methodologies, such as Scrum, impose periodic checks on what is happening in our project and whether there are any spaces for corrections and improvements. However, even if we work in less agile projects, analyzing the current situation is a matter of developing good habits by periodically checking the situation in the project (whether at certain intervals or after reaching certain milestones) and after the project is completed (by doing a post-project flashback, which will serve as a collection of experiences and practices useful in future endeavors).

How does this relate to our records?

Example 1 – costs of errors detected by the customer

For example, we decided that it is important for us to know how many errors are detected only by the client and how this translates into our costs. In the example below, you can see that the errors detected by the client account for 15% of all errors, but the cost of handling them (for simplicity in hours) is more than 1.5 times higher than for internal erors.

Percentage Average bug fix work [hours]

Errors detected by the client – 15% 3.1

Errors detected internally – 85% 1.9

First, we need to answer two questions:

1. Is this metric useful for us?
2. Does this metric provide any important information that gives room for improvement?

Perhaps we will find that such data is satisfactory for us, and in the next releases, we will only monitor it if the percentage of errors detected by the client does not increase. But perhaps today, we recognize that these statistics are disturbing, and we want to work on greater detection of errors at the stage of internal tests, and thus on reducing the cost of error handling (“Cost of Poor Quality”)

Example 2 – cost analysis

After implementing a certain stage of the project, we summarized the costs broken down by the type of work that was performed.

Type of work Labor intensity [osd] % labor intensity

Analytical work and documentation 304 16.54%

Implementation and tests 521 28.35%

Correction of defects 528 28.67%

Administrative work on environments 213 11.59%

Management 273 14.85%

Together 1839 100%

In the example comparison, the almost equal costs of software development (implementation and testing) and the costs of defect improvement are alarming – undoubtedly, this is not a situation that can be ignored. The obvious conclusion: “programmers put out low quality code.” But are you sure?

For me, this data would be insufficient – it would induce me to look for other metrics that would help analyze the situation more precisely: where are all the errors really justified? Weren’t some of them really changed? Or maybe we were liquidating the technological debt from the previous issue?

Summary

In fact, at the “Check” stage, we look at not only the data itself but also the metrics we use: whether they adequately measure our process and our product, whether they allow us to identify areas for improvement, and whether they lead us to actions that will improve the quality of our work. Because that’s what it’s all about – continuous improvement. 

Also Read : Project Management Tools Overview