How do you manage customers with regards to changing requirements? [closed]

Question

Steve Yegge's wisdom notwithstanding, most developers are faced with requirements which were gathered from non-technical customers. Sometimes there are project managers who deal with the customers and translate their requirements, other times not. In any event, the fact that the requirements will change is an inevitability.

Most of what consititues "good programming practice" has to do with developing systems which are adaptable so that they can withstand changing requirements. Principles like YAGNI, DRY, loose coupling, etc. contribute to this. Iterative development processes such as Agile also attempt to address the concern of trying to hit a moving target, and of course having a system under test makes it infinitely more feasible to make changes.

Nonetheless, it seems that for many of us changing requirements can not only hurt the quality of our software, but can also drain our motivation and make us want to stab someone.

This question is about how to manage the customer to make it possible for them to change their requirements in the ways that they need, while discouraging arbitrary or frivolous changes. How do you do it?

• Do you have project managers to insulate the devs from the customer?
• Do you have a formal change management process? Change managers?
• How difficult is it for the customer to get a change when they really need it?
• Conversely, how easy is it for a customer to get a change when it's "frivolous"?
• How much detail do you give the customer when explaining the cost of a change?
• How quickly are you able to give the customer this information after receiving a request for change?
• What factors can torpedo the process (e.g. PM's who can't say no to the customer?)
• What works for you?

Answer 1

If you are looking for the ideal world where the customer never changes his mind or you get the ideal spec - you are in the wrong business. That being said, the most effective mechanism I have found for managing customer expectations and change requests is to institute an accurate system of measurement.

This is how I run my team:

1) We start with user stories. The customer is involved in writing them and the development team estimates how long each user story will take in a relative manner.

2) Using prior experience I take these relative estimates (story points) and create a rough schedule for when major milestones of the project will be complete.

3) Within these milestones we run 2-week iterations. The customer is involved in setting the approval criteria and whether or not the story has been approved. A simple burn down chart shows the customer how close we are to meeting the launch goal.

4) Often time during the approval sessions the customer will request a change because the feature did not turn out how he expected it (even though it met his original approval criteria). At this time you generate a new story with a new estimate. You can also adjust your milestone dates appropriately. This then puts the ball back into the customers court:

• Often times they realize their change request isn't worth it (they'd have to get approval from their boss) and we'll kill the new feature
• Sometimes it is important so we'll delay the due date to get the feature in
• And finally, there's always the option to kill another not so important feature that will take an equivalent amount of time.

The key is not to run away from change requests, but to establish that every change request has consequences on the product. There's no such thing as a free lunch.

Answer 2

I work as indpenedent developer and so contact with customers directly. It's normal that most of the time they have no idea what they actually want. So we start slowly and I give them prototype early on to play with and then the changes will be gradualy made. If I think that customers wants "frivolous" change then I tell him that this change doesn't work or is not needed. If it is 5 min of work then I might even do it anyway.

It helps to add later on to the contract some maintenance clause to get money for those small changes that will come up later on. For bigger changes you just charge by the hour.

Answer 3

Managing the customer is hard, and it is something that very easily can go wrong.

I find that as early as possible you need to gain the trust of the customer. For me I think you can do this by:

• Ask the customer to appoint a product manager - who is clear thinking enough to communicate the requirements he/she wants, and look to build a strong working relationship with him/her.
• Really try to understand their business - you don't need to be a domain expert, but you need to know where the customer is coming from.
• Ask pertinent questions about what they want - don't assume what they ask for (at first) is what they really want.
• At first welcome all changes. This is not the customer being annoying and fickle, it as an opportunity to better understand what the customer really wants. If this costs you time/money, then you may need to accept it as a loss leader.
• Deliver a prototype early, and incorporate as much customer feedback as practicable.
• Give the customer a kick arse product.

Once you have done this, and the customer trusts you, then you will be in a position to start knocking back unreasonable changes, or ask for extra payments/time for things that were previously considered out of scope.

Of course, you won't be able to build this sort of relationship with every customer, some are idiots (in this case see if you can have a different product manager appointed) but you should always do as much as you can to build an effective working relationship.

Answer 4

You can’t expect customers to know what they want at the start, so you must be adaptable. But also you need to stop change for changes sake.

This is for ‘internal’ customers.

I have found that bargaining with the customer is an effective way to go. They can have whatever feature they want if they wait for it, or if they sacrifice some other (yet to be implemented) features. This forces them to think about the value of the change they are asking for in relation to the system as a whole.

Sometimes this works well and a good compromise is reached. Other times the customer throws their toys out of the pram and goes however high they have to get the feature implemented and quality is reduced.

If the customer is paying, it is a different ball game. They need to be made aware that change costs, and that the cost increases as the product nears completion. This means that you have to do a lot of up front analysis about what you will deliver and make sure the spec is agreed upon. So then you can measure what has changed. This may not be the most effective solution for either party but it does keep things cut and dry. So they are not dissatisfied and you don’t end up doing loads of work for free.