when a bug for client is really a new feature [closed]

Question

I read what-payment-structure-do-you-use-for-small-projects and I wonder how you guys are dealing with bug vs. feature. I once had a situation where a client wanted static reports. Then near the end of the project after most of the work on reports had been done he said he had always wanted dynamic reports. That change was not easy, because framework we choose did not support dynamic reports. It was a weird situation, because client had a programming team, so they should have known. Maybe it was just a lack of communication skills.

How do you guys deal with clients trying to make you add features, because they forgot, change their mind, or were misunderstood?

I mean big features, not small ones.

EDIT:

He stated that the budget is fixed and can't be changed and that this feature (like every) is critical and without it they wont accept the system. (just worst case scenario)

Answer 1

In my experience, having been on both sides of this issue, this is usually more about economics than it is about programming, process, or project management.

We, the client, often say "it may be a feature, but if we call it a bug, maybe we can get them to do it for free."

In the end we, the programmer, charge or don't charge based more on whether it will help or hurt our chances for future work. We, the client, dangle the carrot of future work as the incentive to get the programmers to do the extra work for free.

I don't believe any of that will change just because we have a better process for saying "this is a bug" or "this is a new feature."

Answer 2

It is important that both sides understand what they're getting for their money very early on in the process of software development. The Agile methodology is an excellent tool for managing this process. If you have your team's velocity, you can fairly accurately determine how many features it will be possible to add during each iteration. Estimate the tasks, and keep the customer involved in prioritizing what features are to be added and what things are less important. Be sure to have a customer demo after each iteration to show the working functionality you both agreed would be working at the end of the current iteration. Should the customer want another feature or significantly change one that you have already agreed upon, estimate the number of story points necessary (units of work used in Agile) to make this new change or rework a current piece of functionality. This will help them remove another feature that they consider less important than the current one they have just suggested. This keeps everyone happy and there are no surprises when the product "ships"