The client pays for error fixes in IT systems.
This is a standard procedure, commonly used by software providers and implementers. This approach stems from the fact that solving issues is an integral part of ensuring system functionality. Regardless of the model in which the project is organized (Waterfall or Agile) or how it’s billed (Fixed Price or Time & Material), code errors will certainly appear and will be included in the implementation costs.
Another question is whether you’re aware of this from the start, or if you learn how and why it works this way only during the course of the agreement. Want to avoid unpleasant surprises and unexpected fees during your next implementation?
Read on.
What is a Bug?
A bug, or error in the system code, is unexpected software behavior that prevents it from working as intended. These issues may appear in various forms: from minor visual problems, to incorrect functioning of specific features, to severe system failures that prevent further use. They also arise from diverse causes, such as coding mistakes, unforeseen interactions between different system components, or incomplete or unclear project requirements.
Where did the term “bug” come from?
The term “bug” in reference to a software error has an interesting origin, tied to the early days of electronics and computer science. One of the most well-known and frequently cited sources of the term “bug” is a story from 1947, when a group of engineers working on the Mark II computer at Harvard University discovered that a device failure was caused by an actual moth.
The insect was found stuck in an electromechanical relay of the computer. After removing the moth, the engineers recorded in their notes that they had “debugged” the system. This particular bug was even pasted into their work journal. Since then, the terms “bug” and “debugging” (the process of finding and fixing errors) have been widely used in reference to all kinds of errors and problems in computer systems.
Types of Errors (and Ways to Minimize Them)
It’s hard to imagine a scenario where software errors could be completely avoided. While careful design, testing, and implementation aim to minimize them, completely avoiding errors is practically impossible. This is due to several factors, often beyond the full control of development teams.
Here are a few causes that lead to software errors.
- Logical Errors: These happen when a developer makes a mistake in code logic, e.g., checking if a number is less than zero instead of greater than zero, which leads to incorrect results. In such cases, fixing the error involves changing the condition from x<0 to x>0. To minimize the risk of logical errors, consider using the practice of Code Review. This involves having a third party, usually another experienced developer, review the code to detect and fix logical errors early, before handing off the completed functionality for further testing.
- User Interface (UI) Errors: These types of errors often involve inactive buttons that do not trigger the intended response, misaligned text or images, or other issues affecting the system’s visual aspect. To reduce the number of UI errors, require a Usability Testing phase. Usability testing should be conducted in several ways:
- using automated testing tools, e.g., to check the interface’s responsiveness across different browsers and devices
- manually, by experienced software testers
- involving the Product Owner (the client’s project coordinator), before releasing changes into production, in a designated test environment
- Security Errors: Sometimes, bugs also lead to security vulnerabilities, allowing unauthorized access to confidential data or giving control over the system to unintended users. To prevent these issues, it’s recommended to conduct regular security audits and follow Secure Coding principles. In addition, use tools for automatic code scanning and perform simulated attacks on the system in controlled conditions.
- Critical Failures: Certain errors can cause the application or even the entire operating system to crash. A recent example of such a critical failure is the faulty driver in antivirus software from CrowdStrike. To prevent these kinds of situations, rigorous software testing for performance and stability is essential, especially in scenarios involving heavy loads (Load & Stress Testing). Additionally, it’s crucial to keep in mind that even after the implementation phase, ongoing monitoring and regular updates (Upgrades) are necessary. These measures are needed because technology constantly evolves, and over time some solutions may become less resistant to hacking or incompatible with newer platform components.
- Errors from Adding New Features: In complex systems, even minor changes can impact other existing areas, like a set of connected vessels. Furthermore, errors that arise in this way can be difficult to detect. Regression testing and/or automated tests can help in these cases.
- Business-Level Errors: Sometimes, the software functions according to requirements, but in real-world use, it turns out that the system doesn’t meet expectations or struggles with practical scenarios. These types of errors often result from gaps in the specification or shifting business needs. To counteract them, consider the following:
- Thorough requirements analysis: Though remember that even this doesn’t guarantee a bug-free system, as during such a workshop, the client may simply not be aware of all system operational aspects.
- Agile methodology adoption: This allows for adjusting the final version of the system based on real-world feedback from end-users.
Implementation Methodology and Project Rules
When analyzing the question of bug fixing in IT systems, it’s essential to understand the methodology used in the development work. In short, Waterfall is a traditional, and somewhat outdated, method of organizing work in IT projects. It’s typically applied in extreme cases, where it’s deemed necessary to create extensive documentation and agree on a fixed price for a system aligned with the specified requirements.
The risk here lies in the fact that a rigid description and detailed project timeline must be put together before starting any work. If the project takes less time than anticipated, the client still pays the agreed amount. However, there’s no possibility of introducing new needs or refining existing ones during the implementation. If new requirements arise, an amendment to the existing contract must be drafted to outline the terms of these adjustments, or the contract needs to include a specialized procedure for handling changes. This can become a complex and challenging formal process.
Because even in moderately complex projects, it’s impossible to predict every detail, and needs may evolve quickly, there are practically no Waterfall projects that don’t require a budget increase or change management.
A much more common and generally recommended approach to collaboration in IT projects is Scrum. This methodology organizes tasks into two- to four-week periods, called Sprints, and charges are calculated based on time and resources (Time & Material) used to achieve a specific outcome. According to Scrum’s rules, the client’s representative — the Product Owner — is actively involved in the implementation project alongside the development team. The Product Owner oversees the entire process, delegating tasks, evaluating their value, coordinating, communicating regularly with the provider, testing, and approving all changes.
Bug Fixing During Implementation
As described above, collaboration and billing differ between Waterfall and Agile/Scrum approaches. In both cases, however — whether for functional development or bug fixing — the client ultimately pays. The client may be more or less aware of this arrangement.
- In the Waterfall methodology, the cost of bug fixing will be factored into the agreed-upon fixed price by the provider.
- In Agile/Scrum, the entire process becomes much more transparent. The client pays only for the actual time and resources devoted to the project, including bug fixes.
Difference Between User Story and User Story Bug
To better understand billing for bug fixes, it’s also useful to distinguish a few additional (Scrum-related) concepts. The implementation of software in Agile/Scrum is based on User Stories. As the name suggests, these are user scenarios that describe a recognized need.
A User Story is a concise description of a function to be included (implemented) in the system. It describes, in simple, non-technical terms, what the user wants to achieve, the type of system solution involved, and the benefits gained from it. Additionally, criteria are defined that a User Story must meet to consider it complete. These criteria also outline technical methods to achieve the goal.
The User Story format typically looks like this:
As a [user role], I want [feature] so that [business goal/benefit].
Example User Story:
As a recruitment team member, I want the ability to indicate multiple items in a proposal so that I can present candidates with pricing for all individual recruitment services in the proposal, as well as a total for the entire package.
Criteria:
For each proposal, there should be the ability to add multiple proposal items with the following attributes:
- Service Name [Select from catalog]
- Quantity [Floating-point number]
- Unit Price [Currency field]
- Total Price [Currency field]
The total price of all items should be automatically calculated in the proposal in the Proposal Total Value field.
User Story Bug
A special case of a User Story is when an error is encountered, and the goal is to eliminate it. This is referred to as a User Story Bug. A User Story Bug pertains to a situation where an existing function contains an error or problem impacting the user experience.
For a User Story Bug, the development team focuses on repairing existing functionality instead of building a new solution. A User Story Bug is reported when the software does not meet the criteria defined in the original User Story or behaves unexpectedly.
Example User Story Bug:
User: John Smith
Performed Steps: Created a proposal and added 3 items at amounts of $100, $200, and $500
Received Result: The total value of the entire proposal is $800
Expected Result: The total value of the entire proposal should be $800
| User Story | User Story Bug |
| Purpose: Defines a user’s function or need. | Purpose: Indicates an error in existing functionality. |
| Focus: Describes new functionality to be implemented. | Focus: Describes a bug that needs fixing. |
| Priority Setting: Based on business value or urgency of the need. | Priority Setting: Generally higher, especially if the bug impacts key functions or user experience. |
Difference Between Critical and Non-Critical Errors
Errors in IT systems can also occur after the implementation phase or during pilot deployment, which means the system is being used in production by the entire organization or a part of it. The terms for resolving such issues are usually outlined in a separate Service Level Agreement (SLA).
At this stage, we no longer refer to User Story Bugs but rather classify issues as critical or non-critical errors. Their classification depends on the impact on system functionality or security.
Critical Errors
A critical error is one that severely impacts system operation. This type of error means the application, system, or key functions stop working in a way that prevents normal usage. Critical errors can cause crashes, data loss, security risks, or make it impossible for the user to continue their work.
Examples of Critical Errors:
- The system no longer allows users to log in.
- A CRM system fails to correctly record client data.
- A mobile app crashes upon startup, making further use impossible.
Repair Priority: Critical errors are addressed with the highest priority and usually require immediate intervention to restore full system functionality as quickly as possible. At eVolpe, it’s common practice to commit to resolving critical errors within one business day (within 24 hours of the report).
Non-Critical Errors
A non-critical error is one that causes minor issues in the system but doesn’t prevent normal operation. This means that the software works, though it may display annoying irregularities. These errors can affect the user experience but do not stop the application from functioning.
Examples of Non-Critical Errors:
- The system displays a misformatted table, but the data remains accessible and correct.
- The “Save” button functions but doesn’t show confirmation after clicking.
- An icon in the mobile app is incorrectly displayed, but the feature it controls works properly.
Repair Priority: Non-critical errors are typically given a lower repair priority. The team may choose to address these issues at a later time if they do not significantly impact overall system functionality. At eVolpe, a commonly used SLA clause commits to resolving non-critical errors within five business days.
Difference Between Fixed Price and Time & Material
The last set of concepts worth adding to your vocabulary in the context of IT system implementation or service are: Fixed Price and Time & Material. These represent two contrasting models for payment in IT projects.
The Fixed Price model is typical of the Waterfall methodology. Here, the project price is determined in advance. The client and provider agree on a detailed project scope, schedule, and budget before beginning any work. A detailed documentation is also created, reflecting the terms agreed upon.
Some sources claim that this payment model means you don’t pay for errors, but that’s not entirely accurate. In practice, software errors are unavoidable. This is due to the high complexity of IT projects and the intricate interconnections between system elements, where adding a new feature might unpredictably impact existing functionality.
Because of this, implementation companies typically include a buffer for potential error correction in the Fixed Price to ensure project profitability. So, even though it won’t be apparent on the invoice, you might end up paying for bugs that didn’t occur because the provider accounted for them in advance.
In the Time & Material model, the client pays for the actual work time (hourly or daily rate) and resources used during the project. This approach is far more flexible and typical of Agile/Scrum methodology. Requirements can change at any stage since there usually isn’t a detailed document to strictly adhere to.
Instead, an adaptable Product Backlog is maintained, consisting of User Stories, often managed in a project system like Redmine or Jira. This allows only the most currently necessary features to be worked on, while outdated requests can be omitted if market conditions change.
The entire process also operates within an agreed budget, with the Product Owner (the client’s project coordinator) and Proxy Product Owner (the provider’s coordinator) deciding how and in what order to allocate resources.
Because the client actively participates in the project and approves completed User Stories after testing, bug fixes in Scrum are also billable. The payment follows the same principle as developing new features, using the Time & Material model.
How to Avoid Paying for Errors in Scrum?
Worried about blowing your budget on error fixes in Scrum? Choosing the Waterfall methodology won’t shield you from this issue. In fact, with this traditional project approach, you may end up paying for errors that never occur. In the Fixed Price model, providers typically include an extra cost for unforeseen issues, so you’re effectively paying for potential errors even if they don’t happen.
Additionally, in Waterfall, it’s impossible to define every requirement and scenario 100% accurately, even with detailed documentation. As a result, if a feature isn’t clearly described, the provider may refuse to fix an error—even if the client finds the system’s behavior undesirable. This can affect both business requirements (e.g., the system works according to specification but is not user-friendly, requiring multiple unnecessary steps) and functional requirements (e.g., field X was intended to be non-editable for everyone, but another section of the documentation allows administrators to edit all records). Both parties then incur additional costs to clarify these issues, which the provider likely factored into their buffer.
Using Scrum, you’ll manage your budget much more effectively. You actively participate in building the entire system—from defining requirements to selecting, approving, and testing the system—and maintain full control over project spending. The development team provides ongoing cost estimates for User Stories in the Backlog. This lets you decide what to develop or fix based on informed cost estimates for each function.
While unforeseen factors may occasionally lead to higher costs, you may also pay less if the team completes a task faster or suggests an alternative, cost-effective solution. If you’re concerned about the pace of expenses, you can simply pause additional work orders. The system will continue functioning with the features developed so far, which isn’t an option with Waterfall. In Waterfall, even if you suspect the provider isn’t meeting obligations early on, you typically must still fulfill the implementation contract.
Warranty on Custom Code Elements
Firstly, ask for formal assurances from the implementation firm you’re working with. Scrum contracts often include warranties on custom code elements, covering a period for free bug fixes. For instance, at eVolpe, a standard 3-month anti-bug protection is often provided, so you pay nothing for bug fixes on custom code within that timeframe.
Pay Attention to Rates and Team Composition
It’s also beneficial to discuss the development team’s composition. Experienced developers tend to make fewer mistakes, identify errors faster, and resolve them more effectively. However, a team made entirely of senior developers might face more conflicts, lack fresh perspectives, and become frustrated by simpler tasks that usually fall to junior developers. Naturally, hourly rates for senior and mid-level developers differ from those of juniors.
The recommended approach is to balance team experience and cost in a Time & Material setup.
Tip from eVolpe: Before signing an implementation contract, negotiate the rates of individual team members rather than setting an overall budget cap. Remember that the team includes not only developers but also IT specialists, a Proxy Product Owner (analyst), a Scrum Master, and, in complex projects, a Project Manager.
Error-Avoidance Strategy
To avoid paying for error fixes, it’s best to try to prevent them in the first place. Although it’s impossible to completely eliminate errors in software development, you’ll face far fewer issues if you take the testing and approval stages of each functional increment after every Sprint seriously.
- Appoint a Product Owner
Alongside an experienced development team, you’ll benefit from having a dedicated, decisive Product Owner from your company. This individual acts as the bridge between the provider’s implementation team and the client, ensuring the final product aligns with your expectations. They should not only be technically proficient but also well-versed in your organization’s specifics and processes, with authority to make decisions that will guide the software’s development. Their active involvement in the project, especially during the design, testing, and approval of new features, is critical to the implementation’s success and reducing errors. - Utilize Scrum Tools
Another way to reduce errors is to make the most of the tools Scrum provides. By adhering to Scrum principles, you gain numerous ways to react to issues as they arise. During Sprint Reviews, you can evaluate what the team has accomplished in the last two weeks, connect directly with developers and analysts, assess progress, and see how the system’s current version performs. Each Sprint starts with Sprint Planning, where User Stories for implementation are selected, determining what can be delivered in the next cycle and how it will be done. The team finalizes execution methods, and the client approves the work scope. Progress is tracked daily in Daily Stand-Up meetings, where current statuses and potential challenges are discussed. Additionally, Refinement meetings focus on new requirements suggested by the client, clarifying and estimating them before they’re added to the Backlog to be addressed in future Sprints based on priority. After the Sprint Review, a Retrospective is held to identify best practices and solve any process issues, enhancing the project team’s effectiveness. Each of these steps allows for early bug detection, which helps minimize the risk of later adjustments. - Mind the Process!
A best practice in software development is self-testing, or having developers test their own code as they create it. Another common method is Code Review, where a third party (usually another experienced developer) checks the code. Only after confirming that everything functions as expected does a feature move on to formal testing by qualified testers. The testing team then performs both manual and automated tests, considering user perspectives and verifying the solution’s behavior in various conditions, like across different device types. Their main task is to catch any errors before presenting the solution to the Product Owner. If discrepancies are found, the issue goes back to the developers, who make further adjustments to safeguard the system for the future. - Test New Features
As the final link in the testing chain, the client can rest assured that no new functionality will go into production without their approval. Before this, the Product Owner tests each new feature in a testing environment. Only after this rigorous testing does a feature get incorporated into the official system accessible to end users.
Summary
Errors and fixes are an inherent part of the IT implementation process, and clients always bear the cost in one way or another. In Waterfall, error repairs are included in a Fixed Price budget, which is paid regardless of the issues that arise. In Agile/Scrum with a Time & Material model, the system’s cost is flexible and depends on what the Product Owner commissions and how much time and resources the development team spends.
Both new functionalities (User Stories) and error fixes (User Story Bugs) are billed similarly. Key factors for avoiding error-related costs include:
- Client engagement in the implementation process
- Close collaboration between the Product Owner and the development team
- Utilizing Scrum tools (particularly meetings)
- Testing solutions both manually and automatically
To minimize error-repair costs, it’s advisable to include additional clauses in the contract that ensure:
- An experienced development team
- Specific rate levels
- A warranty period for custom code elements
Do you like what you read?
Sign up for our newsletter to get exclusive insights, expert tips, and curated content delivered straight to your inbox. Stay ahead of the curve with the latest trends, industry news, and actionable strategies to elevate your agency game. Join our community of like-minded HR professionals and never miss out on valuable updates again.
