How to distinguish between a “bug” and a “change” in IT projects, and why does it matter in T&M billing?

In many IT projects, the question arises: “Why is every additional correction or modification considered development work and must be billed separately? It’s a bug, after all!” In practice, however, there is a fine line between a bug and a change request. Below, we explain the basic differences and why this is so important in Time & Material (T&M) billing.

What is a bug?

A bug is an unintended, incorrect operation of an application or its functionality resulting from the incorrect implementation of the requirements described in the specification. To put it simply: something was supposed to work in a certain way (as specified in the documentation or agreements), but it does not work correctly.

Examples of bugs:

• The form was supposed to save data to the database, but it does not.
• The login page does not display an incorrect password message, even though this was part of the agreed requirements.
• When entering a number into the basket, an incorrect calculation result appears, even though the correct logic is described in the documentation.

In the T&M model, if a given functionality is clearly specified in the specifications and its implementation is inconsistent with these specifications due to the contractor’s fault, it can be considered an error to be corrected within the project quality standards.

What is a change request?

A “change” is “the addition of new functionality” or “modification of existing functionality” that was not originally specified in the project arrangements or specifications. Sometimes, during the course of a project, new ideas or business needs arise that were not discussed at the outset.

Examples of changes:

• The customer wants an additional e-mail confirming the purchase, which was not previously included in the project.
• Suddenly, it turns out that integration with an external system is needed because new business circumstances have arisen.
• It becomes necessary to adapt the project to new legal regulations that were unknown at the start.

Each modification of this type constitutes additional work, which must be properly planned and “settled in the T&M model”.

“Cross” dependencies and their impact on settlements

Many conflicts and misunderstandings in IT projects result from so-called “cross-dependencies”. These are situations in which the introduction of a new functionality or modification of an existing one affects the operation of other elements of the system.

Example scenario

1. “The customer requests a change” – for example: “We want to add a new section to the home page that will showcase featured products. We didn’t have this in the original scope, but we thought it would be a great marketing addition.”
2. “The developer introduces a new section” – to do this, it is often necessary to add new fields to the database, modify the page template, change the CSS layout, etc.
3. “Consequences elsewhere” – it turns out that changing the page layout causes shifts in existing sections (e.g., the product recommendations section has “moved around”), and refreshing the list of featured products conflicts with the previously implemented sorting mechanism.
4. “Customer submits a request” – the customer notices that “something has gone wrong elsewhere on the website” and “sorting is no longer working properly”. From the customer’s perspective, this looks like an error (because something is not working as it did before).
5. “Reality” – this is not an error in the original function, but a “consequence of a new change”, i.e. a development request (adding a new section).

In the example described, the customer may say:
“Since it broke because of the new section, it’s a bug that you should fix as part of your previous work!”

In practice, however, this is “additional development work” – these dependencies should have been taken into account and implemented. As with any new functionality, the time the team spends on adapting the entire system is a normal part of development work and must be accounted for in the T&M model. It does not matter whether the developer did it all in the first attempt (z) or did 80% of the work first (x) and then 20% as a result of the client’s intervention (y). Overall, it is work on the project as a result of the requested change.

T&M (Time & Material) model – why does every hour matter and why is it profitable?

In the “Time & Material” model, we charge for the “actual working time” spent on project development. This means that:

• When we introduce a new feature, we estimate the time needed for analysis, implementation and testing.
• If additional work arises during the process (e.g., cross-consequences in other areas that need to be corrected), this is also time that must be billed.
• There are no so-called “free corrections” because every hour of a specialist’s time is a real cost, and the Time & Material model does not assume the calculation of project risk as in the case of a lump sum.

A practical example of time-based billing

Let’s assume that the implementation of a new section could originally take 10 hours, but:

• The programmer completed it in 7 hours and the work looked finished after testing.
• After implementation, it turned out that the section affects other elements of the system, which requires an additional 3 hours of work to adjust it.

“In total,” it still comes to 10 hours to be invoiced. The problem arises when, after the first 7 hours, the client decides that the next 3 hours are “errors in your previous work” and should have been done within that time. However, in reality, this is not an error, but a natural consequence of implementing a “new” (previously unforeseen) functionality that requires additional work and often arises as a result of testing by the client on other devices and resolutions. It is important to understand that this is still work on the same change request and there would probably be no problem if the programmer had done everything in 10 hours on the first attempt, but work on products is often the work of both parties involved in the project and it is a process that involves iterations.

What about flat-rate billing?

In the case of a “flat rate”, the situation is slightly different. If the contract specifies a single amount for the entire project, then:

• The “scope” of responsibilities and functionalities to be implemented is determined.
• Most often, a “buffer” is included in the lump sum for possible unforeseen project situations (but up to a certain limit).

If new requests or scope extensions arise during the project, an “annex” or a new contract is usually signed for work beyond the originally agreed scope.

Why is it so important to precisely define functionality?

Many misunderstandings arise from the discrepancy between “what we considered to be a finished feature” and “what the client really wanted to receive”. The more precisely the requirements and ideas about the final product are described,

• the lower the risk that something will be considered an error when in fact it is the result of an unforeseen change.
• The easier it is to account for the actual number of hours worked on the project.

Summary and recommendations

1. Distinguish between an error and a change from the outset:
   – Error: non-compliance with a clearly defined, existing original requirement.
   – Change: new functionality, modification of requirements exceeding the agreed scope, or inclusion of comments as part of a change request being developed.
2. “Remember about cross-dependencies”:
   – When a new feature affects other areas of the system, work on it often requires additional adjustments in those areas.
   – This is a normal part of software development, not a mistake that “comes free of charge”.
3. Every hour in the T&M model is subject to billing:
   – There are no “free” corrections, because every additional hour of a specialist’s time is a real cost.
   – If it turns out during the process that additional hours are needed (and this is not an obvious error in relation to the previously agreed requirements), they are billed separately.
4. Lump sum vs. T&M:
   – Flat rate: one cost for the whole, but with a predetermined scope and buffer. Changes exceeding the agreed scope often require annexes.
   – T&M: you pay for the actual time and materials. Each new requirement or modification increases the amount of work and is billed additionally.
5. “Ensure precise communication”:
   – Clearly explain the differences between an error and a change.
   – Point out that the cross-functional consequences of a new feature are still part of the development work.

Thanks to a reliable approach and a clear distinction between an error and a change, cooperation between the agency and the client becomes clearer. Let us remember that in IT projects, many functionalities overlap, and introducing a new one often entails the need to adapt existing elements of the system. This is not an error, but a “natural part” of product development, which should be properly accounted for in the T&M model.