How do you handle clients who don't understand or forgot their own (sane) requirements?

Question

At my workplace we had the following problem:

A customer wanted some major customizations to our product. We implemented them (about 2 man-years work) and delivered the product. Many of the customizations consisted of complex business rules, which were very hard to grasp but eventually we did.

The problem now is that the users are often complaining: This calculation is wrong, this value is wrong, those two values contradict each other, ...

Almost always we proved that the values were correct and that the user did not understand the logic behind them by performing long, tedious manual calculations.

So this is not the usual problem, that the product does not do what the customer wants. It's quite the opposite, the product does exactly what the customer wants, but the customer does not understand or forgets their own specifications. And most importantly, there is nothing to fix! (Except perhaps the end-user documentation, which we weren't responsible for.)

• Have you even encountered any situations like this?
• How do you handle those cases?
• Is there any way to prevent them?

Answer 1

I don't think you can really prevent this.

The key is how you will handle these situations:

• don't freak out
• assign another team member to re-evaluation the customer's concerns/specs
• when going over the spec, try to get different member's of customer's team to go over it as well: QA,customer reps,sales reps,owner/CEO, etc (if possible).
• ask the same question 3 times (three different ways, like the police do) to make sure you are getting the same answer each time.
• get the customer to explain the feature back to you

I think Joel Sposky's functional spec is great at mitigating these issues, but in the end, the better developer/business person will come out strong on how they handle the conflict, not just in preventing it.

Answer 2

Did you even encounter any situation like this?

Frequently

How do you handle those cases?

Get the user to invest in more training

Is there any way to prevent them?

• Make sure you have extensive user oriented tutorials.
• Make sure the users are sufficiently trained.
• Make sure user management buys into the idea of sufficient training

Answer 3

I once worked on a system that had en extremely complex pricing model. When we finally had the pricing correct we still had a regular stream of complaints of "incorrect" pricing. For a period of three years or so we had one or two complaints a month without ever having to fix any software faults. Each complaint cost us a fair amount of time and resources to analyze and explain. In the end we created tools that the users could use to diagnose and analyze the pricing for themselves - including a lot of the underlying data and explanations of why various decisions were made, and the bug reports slowed down to a trickle.

This tool probably should have been part of the original system, but no-one foresaw those problems.

Answer 4

Yes! I documented the hell out of the specifications for one particularly troublesome customer so that I was always in a position where I could say: "As shown on Page XX, it is operating as expected." In the end, after many, many calls, they finally just settled down, secure in the knowledge that their application worked correctly.

With respect to calculations, I had a group that doubted a series of human performance equations despite the fact that I provided a laboriously documented, step-by-step proof. In the end, I made them a bet: $1,000 to anyone in their group that could prove my derivations wrong. There was no risk for me because I knew I was right. The offer was so unusual that the division head of the hospital got word of it and the guy sowing doubts about my software got shut right down.

In the end, the only way to move past it (avoiding it is impossible) is to apply loads of patience and lots of handholding. There is simply no other way.

Answer 5

If you can find a user from the customers who will act as a "champion". Normally this might be your project sponsor, but in your case it sounds like you want to find someone who is pretty technically astute, not neccesarily a manager.

Then work with that person intensely so that they understand the behavior of the software, and can validate that it is correct. Then they can help with the explanations to the rest of the users, because they will be more "trusted" than your staff is.

Answer 6

I invite you to look at the agile manifesto, and scrum methodology. Those methodology can answer the third bullet. (Is there any way to prevent them)

To prevent miss understanding between the customer and the real user you should have the real user in your team of software developer. Also in scrum it is suggested to have small delivery of software (sprint (2-4 week). So that the customer can see if it's truly what he want.

Ex. If the customer want a login screen on is website. In the first sprint you will deliver the login screen tested and working. Even if after the user login nothing but a underconstruction page is displayed.

This way the customer and user will be able to see if the feature is well done and is want they want.

I suggest you to read a lot about agile methodology.

Answer 7

I've had this problem on a government project where we were calculating revenue amounts based on some insane rules (all of which were codified in the state statutes). In addition, this was a replacement of a previous system. We had a couple of problems:

1. The rules from state law were not necessarily the rules the personnel were familiar with. As time went on and employee turn-over happened, I guess people forgot or communicated the rules incorrectly.

2. Complete ignorance of the rules by the employees.

3. The rules programmed into the old system were often wrong.

The first problem was worse than the second, and the third was the worst. We had to show, from the state law, how the rules were to be applied. As you can guess, the state law can be quite esoteric, so it ended up being math problems on a whiteboard. After a couple of months of this, the users finally figured out that the new software was right and the old software was simply wrong. Each time, however, we had to do some analysis, make sure it wasn't wrong, then show the users how either their understand of the rules was incorrect, or the old software was incorrect. It took a decent amount of patience, but it all worked out.

To handle this kind of thing, you need patience, a good working rapport with your users (which begins on day one of the assignment), and open lines of communication.

Answer 8

Taught but interesting question... This kind of situation is hard to prevent since many customers will not read carefully your documents and even less will accept to create test cases.

If you cannot prevent it, thought, you can smell it : many different answers for a clear question, answers that change without apparent reason, customer that never have the time to validate your documents (or your demo, your test cases, ...).

Accepting such a situation is often one-way ticket to the nearest wall. For you and your customer.

What to do then ? It depends... If your customer is not the one who ask for the software, go talk to the one who ask for it. If your customer is the one who ask for it, it may not be the one who will pay for it. Try to talk to the one who pay. In either cases, it have to be put clearly on the table : vague specs or changing specs are not specs. Imagine building a bridge without knowing where nor for what !

This being said, customer most be "educated" - they often don't know how a software can help them. Often, they don't know what to ask and they don't know what a spec is and why it is important.

Good luck!

Answer 9

1. Did you even encounter any situation like this? Yes and yes. way to often.
2. How do you handle those cases? calmly, take notes, when the user/customer has finished explaining whats wrong I read back the details I have noted down. A discussion of the details now follows.
3. Is there any way to prevent them? Prevent this no. Users seldom know what they want and even less often they can't recognize what they wanted when it has been implemented.

Here's what I follow: When you get a request for a new feature or fix make sure to write down as you understand it, have another developer approve(read through it and confirm it makes sense). Then have the user or customer representative read it and approve it. make sure that any changes go through procedure, make sure to date these documents and have a specific user take responsibility for the feature. Remember they are just as responsible for the feature as you are. Have the user create test cases which you will base your implementation on and initial tests. If the customer presents contradictory opinions later, you always have their approval on the original specs and test cases created by the user. It does take a lot of work from your side and the customers, the benefit is that the probability the feature implemented will be the feature the customer wanted is higher, and will in the end save time.

Answer 10

Shorten the development cycle to small increments and involve the user in testing regularly. This way, the user has a vested interest in the product's success, and issues will be addressed early on (either by educating the user or by correcting the code).