methodology - How to deal with poorly informed customer choices

Question

Here's a scenario I'm sure you're all familiar with.

1. You have a fairly "hands off" customer, who really doesn't want to get too involved in the decision making despite your best efforts.

2. An experienced development team spend hours discussing the pros and cons of a particular approach to a problem and come up with an elegant solution which avoids the pitfalls of the more obvious approaches.

3. The customer casually mentions after a quick glance that they want it changed. They have no understanding of all the usability / consistency issues you were trying to avoid in your very carefully thought out approach.

4. Despite explanations, customer isn't interested, they just want it changed.

5. You sigh and do what they ask, knowing full well what will happen next...

6. 3 weeks later, customer says it isn't working well this way, could you change it? You suggest again your original solution, and they seize on it with enthusiasm. They invariably seem to have had a form of selective amnesia and blocked out their role in messing this up in the first place.

I'm sure many of you have gone through this. The thing which gets me is always when we know the time and effort that reasonably bright and able people have put in to really understanding the problem and trying to come up with a good solution. The frustration comes in contrasting this with the knowledge that the customer's choice is made in 3 minutes in a casual glance (or worse, by their managers who often don't even know what the project is really about). The icing on the cake is that it's usually made very late in the day.

I know that the agile methodologies are designed to solve exactly this kind of problem, but it requires a level of customer buy in that certain types of customers (people spending other peoples money usually) are just not willing to give.

Anyone any clever insight into how you deal with this?

EDIT: Oops - by the way, I'm not talking about any current or recent customer in this. It's purely hypothetical...

Answer 1

Make your customer pay by the effort you are putting into designing and developing the solution to their problem.

The more you work, the more you get. The customer will have to pay for his mistakes.

Customer will eventually learn to appreciate your experience and insight in the programming field.

Answer 2

Niyaz is correct, unfortunately getting a customer buy-in is difficult until they have been burned like this once before.

Additionally describe to the customer the scenario above and state how much extra it would cost if you went three or four weeks down the line and had to rewrite it due to a change and then let them use the prototype. It may take a few days to put one together so they can see both options (theirs [the wrong way], and yours [the right way]). Remember they are paying you not only for your ability to program but also your experience and knowledge of the issues which crop up.

Whatever the decision the customer makes, ensure that you get it documented, update your risks register for the project with the risks that the chosen implementation will incurr and speak to the project manager (if its not you) about the mitigation plans for them.

Answer 3

I agree with Niyaz. However at the time the customer suggests the change you should work out what the impact of the change will be, and how likely that impact is to happen. Then ask whomever is responsible (it's not always that customer) for the deliverable if they approve the change.

Making the impact clear (more cost, lower reliability, longer delivery time etc) is very important to helping the customer to make a decision. It's very important to describe the impacts on the project or their business in a factual way, and assess how likely that impact is to occur. "Maybes" and "i feel" are very ignorable.

After that as long as the right people approve the change and as long as they pay for it.. well you did give them what they wanted :)

Answer 4

One thing we have done with some success in the past in these kinds of situations is to hand the issues over to the client.

"OK, you want to change it - this is what will happen if you do that. These are the issues involved. You have a think about how you'd like it to work and then get back to us".

This approach doesn't tend to yield good solutions (unsurprisingly) but does tend to let the client see that it's not a "gut feeling", wild stab in the dark kind of question.

And failing that, it usually makes them stop asking you to change it!

Answer 5

通常这样的情况是由两件事引起的。那些应该给你需求规范的人要么不把心投入到项目中，因为他们对它没有兴趣，或者因为他们真的不知道他们想要什么。

敏捷编程是最好的方法之一，但还有其他方法可以做到这一点。我个人通常使用经典的瀑布方法，所以螺旋和敏捷方法是不可能的。但这并不意味着你不能使用原型。

事实上，使用原型可能是最有用的工具。想想冰山效应。 秘诀是非程序员的人不明白这一点。http://img134.imageshack.us/my.php?image=icebergbelowwater.jpg

“你知道冰山 90% 是如何在水下的吗？嗯，大多数软件也是这样的——有一个漂亮的用户界面需要大约 10% 的工作，然后 90% 的编程工作都在幕后…… 。”——乔尔·斯波尔斯基

生成原型需要时间和精力，但它是收集需求的最有效方式。我的项目团队所做的是，UI 设计师是制作原型的人。如果您给用户一个原型（至少是应用程序外观和感觉的工作界面），那么您将受到很多批评，这可能会导致期望和要求。它可能看起来像 YouTube 上的评论，但这是一个开始。

第二题：

客户在快速浏览后随便提到他们想要改变它。他们不了解您在经过深思熟虑的方法中试图避免的所有可用性/一致性问题。

生成另一个原型。这里的关键是用户希望看到的结果，而不是他们必须听取的建议。

但是，如果所有其他方法都失败了，您总是可以列出为什么实施该解决方案的利弊，无论他们喜欢的特定解决方案是否不是您坚持的解决方案。使文档的该部分尽可能易读。例如：

问题：

公园是所有漂亮女性慢跑保持体形的地方。Johnny Bravo 喜欢享受“大自然的美丽”，所以他希望融入其中……你知道……看起来很强壮，在追尾的同时慢跑。

替代解决方案：

1) 穿上黑色麂皮鞋，让自己看起来尽可能时尚。

2) 穿上一双耐克的。跑步必备鞋。尝试最新款式。

实施的解决方案：

黑色麂皮鞋是首选，因为...好吧，因为辣妈喜欢黑色麂皮鞋。

Answer 6

Or else, if they won't pay for the effort, just avoid putting that much resources into the solution of the problem, and just give them exactly what they've asked for and then think about it after the three weeks have passed.

Somewhat frustrating, yes, but that's the way it'll always be with that kind of customers. At least you won't be losing money.