When Is a Bug Really a Bug? (And When It’s Not)

In many software projects, the line between a bug and a change request is often unclear—and this ambiguity can lead to delays, disputes, and increased costs.

In software development, few topics create as much debate as defining a "bug." From a client's perspective, a bug is anything that doesn't work as expected. 

From a supplier's perspective, however, a bug is often dismissed as a missing requirement, conveniently reframed as a change request to avoid responsibility. This discrepancy leads to frustration, delays, and a growing sense of mistrust between the two parties. 

So, where do we draw the line?

Client vs Supplier: What Counts as a Bug?

Clients rely on software to function intuitively and predictably. When something disrupts their workflow or doesn't meet reasonable expectations, they rightly label it as a bug. Conversely, suppliers frequently hide behind vague requirements, using loopholes to avoid fixing issues unless explicitly documented.

This disagreement often shows up in simple, real-world scenarios. For example, consider an online form designed to collect UK phone numbers. Is that a bug if a user can enter letters instead of numbers? The client would argue yes—it prevents valid data entry and should have been accounted for. The supplier, in contrast, might claim that since validation rules were not explicitly stated, they are not responsible. This kind of evasiveness only serves to frustrate clients and degrade trust in the development process.

Implicit vs Explicit Requirements in Software Projects

Software inherently includes implicit requirements. Much like a cookbook doesn’t instruct the reader to fetch a pan before cooking, some aspects of functionality should be assumed. However, suppliers often exploit ambiguity to deflect responsibility, insisting that anything not meticulously spelt out is outside the scope.

Taking this a step further, consider high-level system-wide requirements, such as accessibility compliance. If a client states that a website must adhere to Web Content Accessibility Guidelines (WCAG), does this mean they need to specify every single place it applies? No reasonable supplier should need such micromanagement. Yet, when accessibility issues arise, suppliers often attempt to classify them as change requests rather than take accountability for meeting industry standards.

The Risk of Blurred Boundaries

When suppliers dodge responsibility by blurring the distinction between a bug and a change request, projects slow down, costs rise, and clients are left with a system that doesn't meet their needs. This kind of behaviour not only undermines collaboration but also erodes confidence in the supplier’s ability to deliver a quality product. Clients expect professionalism, not excuses.

A Practical Approach to Resolving Bug Disputes

So, how do we navigate these challenges and hold suppliers accountable? Here are some guiding principles:

1. Clients Shouldn't Have to Spell Out the Obvious: Suppliers should apply industry best practices and anticipate common-sense expectations.

2. Refusing to Fix Clear Issues Is Bad Faith: If a reasonable user would expect certain functionality to work in a certain way, the supplier should address it without excessive debate.

3. Minor Fixes Should Be Resolved, Not Argued Over: Simple fixes, like adding basic validation, should not become lengthy discussions about scope.

4. Transparency and Accountability Matter: Suppliers should not weaponize requirements documentation to avoid doing the right thing.

Conclusion

The line between a bug and a change request isn’t always clear, but clients shouldn’t have to fight tooth and nail to get a functional product. Suppliers who play games with definitions to dodge responsibility only harm their own credibility. Instead of hiding behind technicalities, suppliers should prioritize collaboration, efficiency, and above all, delivering software that works as expected.

If something clearly isn’t working but turns into a debate instead of getting fixed, you’re not alone.

I help people cut through unclear requirements and focus on getting systems working properly.

If issues feel harder to resolve than they should be, take a look at my TechFix service.

Over-Promise and Under-Deliver: Why Projects Fail

In the competitive world of technology and software, promises are currency. Companies promise innovation, efficiency, and transformation to secure deals. But what happens when those promises exceed what can be delivered? "Over-promise and under-deliver" is not just a cliché; it’s a costly pitfall that affects everyone involved in a project.

Over-promising in software projects often leads to missed deadlines, increased costs, and failed delivery—especially when expectations are not aligned with reality.

Let’s explore the repercussions of over-promising, how to identify it early, and what you can do if you find yourself in such a situation.

The Problem with Over-Promising

To win projects, suppliers often overstate the capabilities of their solutions. They may promise features or timelines that their product cannot realistically deliver. This overconfidence can stem from various factors:

• Lack of Suitable Products: The solution isn’t fit for purpose and requires significant modification.
• Underestimating Costs or Timelines: Sales teams downplay the complexity of the project.
• Knowledge Gaps: The supplier doesn't fully understand the client’s requirements or their own product’s limitations.

For the client, the gap between expectations and reality can lead to frustration, wasted time, and wasted resources. For the supplier, the cost is stressed teams and tarnished reputations.

Here are some of the most common impacts:

The Impact on Clients

Clients pay the highest price when promises fail to materialize. Here’s how:

1. Wasted Resources: Clients often deploy additional staff to compensate for shortfalls, increasing costs. These resources are diverted from other projects or responsibilities.
2. Frustrated Teams: The client’s employees, often the first to notice issues, scramble to fill gaps, resulting in stress and burnout.
3. Diminished Trust: Stakeholders lose faith in both the project and the supplier, damaging relationships and future collaborations.

The Impact on Suppliers

Suppliers also bear the burden of over-promising:

1. Disjointed Handoffs: Sales teams, who made the lofty promises, often move on to new deals, leaving delivery teams to face the fallout.
2. Pressure on Delivery Teams: Developers and implementers work under intense stress, trying to retrofit unsuitable products to meet commitments.
3. Reputational Damage: Failing to deliver tarnishes the supplier’s credibility, affecting future sales and partnerships.

Early Warning Signs of Project Failure

Spotting over-promising early can save a project from disaster. Look for these red flags:

• Missed Deliverables: Early milestones are delayed or skipped entirely.
• Shifting Blame: Teams start pointing fingers, and excuses become frequent.
• Compounded Delays: One delay leads to another, creating a domino effect.
• Rumours and Discontent: On-the-ground staff discuss missing features or limitations compared to the promised solution.
• Gaps in Requirements: Functionalities of the old system are not replicated in the new solution.

What to Do When a Project Starts to Fail

If a project veers off track, several options are available. None are ideal, but understanding the trade-offs can help you choose the least damaging path:

1. Pull the Plug: If the project is beyond salvageable, cutting your losses may be the wisest choice.
2. Accept a Reduced Scope: Scale back expectations to align with what the supplier can realistically deliver.
3. Learn and Move On: Document lessons learned and apply them to future projects.
4. Refocus on Minimum Viable Functionality: Strip the project to its core essentials, ensuring at least some value is delivered.
5. Deprioritize: Shift focus to other initiatives, letting this project take a backseat while still attempting to salvage some outcomes.

How to Prevent Over-Promising in Projects

The best way to avoid these challenges is through thorough preparation and due diligence:

• Validate Supplier Claims: Insist on real-world examples and case studies that demonstrate the supplier’s ability to deliver similar solutions.
• Engage Your Team: Involve your staff early to assess proposals and match them against actual needs.
• Define Requirements Clearly: Document precise requirements and ensure the supplier can meet them.
• Set Gates and Checkpoints: Break the project into phases with clear milestones and validation steps.
• Prioritize Transparency: Establish an open dialogue with suppliers to ensure alignment and realistic expectations.

Conclusion

Over-promising and under-delivering isn’t just a project management issue; it’s a systemic problem that creates stress, wastes resources, and undermines trust. By recognizing the warning signs and taking proactive steps, organizations can protect themselves from falling into this trap.

The key takeaway? Due diligence is your best defence. Understand what you’re buying, involve your team, and ensure the supplier can deliver what they promise. In the end, realistic expectations lead to successful partnerships—and projects that deliver real value.

If your project doesn’t match what was originally promised, you’re not alone.

I help people cut through unrealistic expectations and get things back on track.

If things feel like they’re drifting away from the original plan, take a look at my TechFix service.