How to Manage a Customer Who Is Unhappy with Software Quality?

 Many customers demand high-quality software, but do they define "quality" in measurable terms?

A few years ago, I was assisting a project team in reviewing and refining their approach when a customer from my previous organization realized—after project implementation—what they actually needed.

Understanding Quality Expectations

The customer initially expressed concerns about performance but had no concrete definition of what that meant. After some discussion, we helped him articulate a measurable requirement: the response time for the web application should be 1/10 of a second. However, this application depended on multiple external systems.

To clarify further, I asked:

• "Do you expect this response time under a load of 10 users or 1 million users?"
• The customer had no clear answer but optimistically responded, "Maybe more than 1 million someday."

I followed up:

• "Are you prepared to invest in the necessary hardware to handle over 1 million user requests?"
• He was uncertain and had no idea whether the installed infrastructure was based on capacity planning or if it was just an arbitrary setup.

Identifying Feasibility Constraints

I then inquired:

• "Do you know the network latency between this application server and the dependent systems?"
• "How long do those systems take to process requests?"

Initially, the customer had no data, but later, he gathered the numbers. The processing time of the dependent systems, combined with network latency, already exceeded 50 seconds—far from the 1/10 second goal.

I asked:

• "Can you ensure that these external systems complete their processing in 1/20 of a second so the new application has enough time to meet the 1/10 second target?"

At this point, the customer realized his requirement was unrealistic. He admitted, "My requirement isn't feasible, but I’m in a tough situation—users can’t wait this long for a response."

Shifting to a Feasible Solution

I turned to the project team and asked:

• "Did you consider handling this challenge when designing the application?"

Since the new application was essentially wrapping legacy systems, an appropriate strategy was needed to deal with long processing times. I suggested an asynchronous approach, where:

1. The system acknowledges the request immediately.
2. The user is notified that processing is in progress.
3. The user can check the request status via email or a dashboard update.

At that time, asynchronous processing wasn’t widely considered, but today, it’s a common practice.

Key Takeaways

This story highlights a few important lessons:

1. Quality must be clearly defined – Many customers demand quality but fail to specify what they need in measurable terms.
2. Measurable requirements are essential – Ambiguous expectations lead to unrealistic demands.
3. Testing should be derived from requirements – If something isn’t explicitly defined, it can’t be assumed or tested.
4. Feasibility matters – Requirements must be achievable within system constraints.
5. Development teams must take a holistic view – Instead of blindly executing customer demands, teams should educate customers, identify challenges early, and define strategies that ensure long-term success.

By guiding customers toward realistic expectations and implementing thoughtful design strategies, teams can deliver high-quality software that meets both business needs and technical feasibility.