Quality Management in IT – Matching the Quality to the Stage of the Organization’s Development

Imagine at the initial stage of a project analysis, your colleague asks you what quality you expect. You most likely say right away: “the highest quality!” And this would not surprise anyone. Is it, however, the best possible answer? Do you always want the sweetest cookie, or the fastest car?

This article will tell you:

• what quality is
• how quality management can be referred to the development model of an innovative business
• if it is a good idea to start off with poor quality in IT projects

________________________________________

What is quality?

The issue of quality was pondered over already by classical philosophers. Plato wrote: “quality (poiotes in Greek and qualitas in Latin) is a certain degree of perfection”

This very approach should communicate to us that, not only is quality something gradable, it’s also something highly relative. If we also focus on the very idea of management, it doesn’t say either that all the aspects and factors should be indiscriminately augmented. Instead, the means should be adapted to the goals for things to “happen” effectively. Hence, taking into account definitions, we learn that rather than pressing blindly for the best quality, we should try to attain the quality that is most suitable.

But how to translate quality management into the daily practice of running IT projects?

Quality management vs the innovative business development model 

The world we live in is increasingly volatile, complex and uncertain. Many experts refer to it as the world of VUCA (for Volatility, Uncertainty, Complexity, and Ambiguity). This calls for highly adaptable methodologies, i.e. Agile methodologies. The process of running an IT project involves a few methodologies simultaneously based on agility, e.g. AgilePM and Scrum used by ourselves. 

Increasingly, Agile methodologies are also used in the development of companies or their management. They stem from the world of start-ups but concern each type of innovative initiative undertaken in a small or big organization. I mean particularly the Customer Development or Lean Customer Development methodology. 

For those interested in learning the details of these methodologies I recommend the books “The Startup Owner’s Manual: The Step-By-Step Guide for Building a Great Company” written by Steve Blank and Bob Dorf or “Lean Customer Development” authored by Cindy Alvarez.

In a nutshell – in the Customer Development methodology, the aim is to quickly verify hypotheses on the market and to gradually improve and develop everything that concerns the product/ project (for those who work in Agile, it must sound familiar ;))

Customer Discovery

It will come as no surprise to you if I write that all business development starts with formulating hypotheses about clients, their needs, customer communication channels, and finally the MVP (Minimum Viable Product), which allows us to verify these hypotheses with clients.

Customer Validation

Validation often leads to pivoting, which need to be fast and inexpensive. Only after we have actually verified that our product is the right one for selected clients, do we develop the ultimate business model (e.g. according to The Business Model Canvas model described by Alexander Osterwalder) along with the sales and marketing plan. And then we put the product on the market.

The next two phases are about business scaling. That is Customer Creation, which is about winning a sufficient number of clients for the product to be placed on the market beyond the “early adopters” group. When we are ready to conclude that our sale actions are effective, we build an organization that will provide products on a repetitive basis. In this way, we reach the Company Building phase.

Customer Development phase vs the quality of IT solution

How can it be related to the product code creation?

In the first two phases, the probability that the project will be a success is smaller than that it will actually prove a mistake or will require revision and changes. Practically everything may go wrong, from the wrong business or technological concept, to a bad team line-up, to financial difficulties. Everyone who has participated in an innovative project or built a start-up has experienced that. It is normal.

Hence, in this phase it is often not the quality that matters but the smallest possible production cost of the MVP. It may result in the code being “non-viable” and only one person will really know it. It may also prove unstable and non-efficient with no embedded tests. Briefly speaking, it will incur a big technical debt, its author will be ashamed to have produced it and red lights will be flashing in SonarQube to show that software is good for nothing.

Yet a quickly and inexpensively provided MVP, through which we have verified the respective solution, is often the most reasonable approach – with a few provisos. They boil down to the mutual understanding and cooperation between the technical and business part of the team, and the team’s readiness to perform a given task.

Many experienced developers avoid such an approach disheartenment because of bad experiences from the past – “we made a quick-and-dirty project at the business team’s request, and later, they told us to maintain it”. I have witnessed such situations myself when the project was evaluated to be functional and easily implementable, and, later, at the development stage, frustration and mutual reproaches arose. Yet, with a common understanding of the goals, we are able to produce the prototype, being aware that entering the scaling phase means creating the system from scratch, without adding a new functionality. And this if often the best solution.

If we believe that the system will be fit for purpose – we can make an attempt at creating a high quality product “right away”, as hypothetically the total cost of producing a good system is lower than that of making gradual improvements. However, in IT, producing in advance is very often a bad idea as the VUCA world is full of changes and it is best to grow functionality gradually while minimizing the cost of misguided ideas.

Another problem with a project burdened with technical debt is that good programmers do not want to create a low quality code, as such work does not help them develop. However, if the team cooperates and is aware that this is the cost that needs to be incurred to develop a high-potential application with good prospects – and everybody sees the benefit – they are usually ready to take such an approach.

Quality at the business scaling stage

When creating and testing the business idea, one should constantly remember to keep costs down and pay attention to the ongoing cashflow rather than the ultimate profit. What usually looks encouraging in an Excel spreadsheet might never live up to reality, and the budget will be gone.

Once we start commercializing the product, we make a brand promise to the client. We declare we will deliver quality and value. If we offer low quality, the client might walk. A broken brand promise is something that clients do not forgive.

This is why, from that moment on, it is necessary to drastically change the approach to the quality of the application, when the cost of its development and maintenance starts to soar rapidly.

That forces a reflection. We have to realize that delivering and maintaining a system module is increasingly expensive for us. What’s worse, income and other costs grow faster and faster. And we realize that a faulty system, loss of income and loss of clients cost us more than the higher (and more expensive) quality.

Is it always worth starting with a lower quality?

To wrap it up, we start off with a lower quality when we are doing a truly innovative project and we are not sure about its success. However, when we are automating a process that has already been in use or we are replacing an inefficient legacy system with a new one, it is necessary to apply a high quality right away as we are already at the company building stage.