when a bug for client is really a new feature

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

We have the spec in writing and have the client sign off on it, agreeing to pay for the features described in that document. If they change their minds later on something simple, we will usually work in the changes for no extra charge, but anything like what you described would require a new purchase order.

Answer 2

If it isn't in the project plan / written agreement it's out of scope.

Answer 3

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"

Answer 4

Well, simplest answer is that the budget or contract stipulates the requirements. Changes to those requirements have to be submitted as an extra and then go through the same process as the original project. They have to be budgeted for and estimated.

Once all that is done, if the client wants it close to the original launch date (and that's feasible), add extra for overtime hours.

At least, that's what I've done.

Answer 5

I charge them.

Answer 6

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."

--
bmb

Answer 7

It sounds to me like the client may be looking for an excuse to get out of the agreement without paying anything. If he can arbitrarily add features and insist on them for final acceptance, without additional cost, he's got a way to make you break the contract.

There's two obvious ways to avoid this.

One is payments throughout development, so that the client can't wiggle out of much of the payment, and you're more or less compensated from what you've done at any point.

Another is a good contract. For any reasonable software project, a few hours of lawyer's fees is cheap insurance against something like this. If you are confident that you can sue the client for agreed-on fees and win, the client is less likely to make trouble, and if all else fails you can sue.

I don't know what the contractual arrangements are that you're working under (and I'm not a lawyer anyway), but in a situation like that I'd get a lawyer and see what sort of situation I was in. Even if you're in a dubious legal position, it's possible that a letter from your lawyer could help resolve things.

And don't get into that position again.

Answer 8

There is no point in trying to argue them out of the feature. After all, communication issues or not, the mission is to deliver what the customer needs in the software.

I'd go with an Iron triangle argument as follows:
1) Obviously we want to deliver the product you need, so lets work together.
2) We all understand that regardless of how we got to the current point, we can only go forward from where we are today.
3) We also understand that implementing changes will take time and money which has to come from somewhere.
4) At this point your options are these (pick one)
* Replace the work that was planned for some other functionality with the work required for this change to stay on budget and schedule (sacrifice other features)
* Extend the deadline (increase cost/shift deadline)
* Add resources (increase cost)

Warning: Although C makes logical sense if you are doing manufacturing type work (build another 1000 pencils), in R&D work like software engineering it usually is just another flavor of B where you the cost and deadline shift is magnified.

Answer 9

Well, if it's the truth, just go by it. What's to explain if you agreed to one thing and now he wants to do extra? Are you receiving push back?

I would make it clear that we originally designed a static report and that was what was signed off on. It can be extended to dynamic reports and that you can provide a quote if he would like to know the specifics.

I often use the analogy of building a house. Either the client is changing the blueprint, or the finishing materials that are requiring more time, materials to get done from what was originally agreed to.

Hope that helps!

Answer 10

I would recommend making sure that the requirements are ironed out as much as possible, and that both sides understand exactly what is being promised. It keeps the client happy because there's fewer situations like you describe, and it keeps you happy because you don't keep getting yanked around.

Answer 11

There's no right answer - just a few wrong ones. Specs and requirements have more white space than information - there's always room for interpretation and misunderstanding...what it really comes down to is:

• future work - is there future work with this client or potential reference for future work? if so, you give in a bit, try to un-grey other areas of the deliverables that, based on this instance, could turn in the right direction.
• payment - are they holding payment based on this? and is the work still within your buffered budget (you did add a buffer for this type of work - right? well, next time you will - future clients pay for past client mistakes)
• deliver quickly and often - IKIWISI -I Know It When I See It - if it's in front of the client sooner then later, then the 'interpretation'/grey-areas get reduced...iterative deliveries (even incomplete ones) work wonders

After the fact you can't do much, if it comes down to legal action, you lost this client and a good reputation (potential) - be careful in how hard you push it

Answer 12

What I do in this case is look at prior documentation and communications.

For example, if documentation/communication says "Create reports". If there is no specific mention of dynamic reports I would not give in to the client.

If there is any documentation saying "dynamic reports" then the client would be right and I would have to develop the reports at no cost.

If there is communication about "dynamic reports" I would have to look at what the final outcome is. This is where it might get harder because a lot of times a client might as "Is it possible to create dynamic reports?" and a developer might say "Yes, that is possible." (meaning it's possible, but does not mean we will do it). This is where I would have to explain that although discussed it is not in the scope of work. There has to be concrete agreement that a feature will be developed.

If you do not keep documentation and prior communications then I would say you are at a loss and would need to decide if you are going to give the client what they want or risk losing the client.

One of the worse things to me is a client who insists on telephone communications. These clients are the ones who usually play it fast and easy with their requests. What I usually do here is to always do a written follow up with the client on everything that is discussed during a face to face meeting or phone call and require the client to respond to make sure we are on the same page on what will and won't be done.

Answer 13

The question is about two topics: negotiation and project management.

As far as project management concerned you need to manage the risk of customer changing their mind or misunderstanding an agreement in advance. Here is a list of preventitive measures one would normally take in a software development project, it can be used as a checklist when planning or revisiting a project:

• Avoid most of the risks by having a written spec aproved before you start. In case you do smaller iterations have a spec for iteration approved. It doesn't need to be overly detailed but should set customer expectations and serve as a reference point. Detail things you're not certain about in the spec.

• You might have an opportunity some other ogranisation that reports directly to the customer to do certain risky bits.

• Put some contigency time and budget into the plan, exlpain to the customer that any contigency is going to be used only by agreement with them.

• Explicitly offer alternative solutions to customer on the planning stage, discuss pros and cons and document the decision.

• Even if you do waterfall build in several milestones into the project where you will make a litte demo to the customer or clarify requirements. Take that opportunity that customer is still ok with the proposed solution.

• As pointed out by Webdtc always confirm outcome of phone and face-to-face discussions by sending a short summary e-mail.

• Keep deliverables, their acceptance and payments spread out for projects longer than a month. Even if customer pays at the end of the project make sure you get evidence of their approval of interim deliverables.

Hopefully, following these tips won't ever put you into a tough situation when you need to negotiate deliverables with customer post-factum threatened by a non-payment. But if nonetheless you found yourself having to stand up to unreasonable demands the info you would have accumulated by then would have given you very strong leverage. Tips for negotiation:

• Start with understanding the exact reasoning behind customer demand. And exactly what their position is. Confirm with the customer you understand them correctly.

• At this point it can be either your fault (unlikely if you managed the project correctly), customer's fault (sometimes they do change mind their mind) or a cock up on both sides (most likely).

• When it's all your fault most likely you'd need to swallow the pill and learn your lesson. However you'd need to negotiate with customer new deadlines to prevent the problem costing you even more. Always consider suggesting an alernative solution to the problem built on top of the software you've got now.

• When it's customer's or mutual fault start with "no". Push back to let them understand you not absorbing the cost, not fully at least. Don't let them convience you that they can easilly walk away, this is never true. By this point even if they haven't paid you a penny their investment into the project will be sizeable: time spent evaluating bids, taking part in meetings, the effort they made communicating requirements, their and their customer's dependency on the project being completed mostly on time and within budget etc. You still might have to split the costs between the two organisations, but start with "no" to make it clear that they are as responsible for making an effort to timely clarify requirements as you are for discovering what is needed.

Answer 14

I'm in a situation where this happens on a regular basis. We write web applications that do complex tasks, then after we've completed it according to specification the user will then turn around and say "We want not just X & Y, but we want Z too". Z wasn't in the project scope and thus isn't achievable in the current system, therefore it must be rewritten to acommodate for the newly introduced "features".

The way we work around this is simply as follows. Treat the user like they're an idiot, and understand the system better than they do. I know this sounds really mean, and at first when my boss introduced me to this I told him straight that I would never treat a user as such - unfortunately I learnt the hard way and now have to know more than the user to complete my tasks. Mitigation is of the utmost importance, and foreseeing major changes which could be introduced is a skill learnt over time.

I now mitigate for these unplanned, but probable changes.