Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

We are working on a large ongoing project that has continual feature changes. These features could take as long as 3 - 4 weeks to complete.

This would of course be fine, except the client is always changing its priorities/focus based on pushes from THEIR clients who may want certain features implemented before others.

So, we often have to shift gears in the middle of a major feature build and start a new feature that all of a sudden has a greater priority. We then of course have the time cost of merging everything together at some point, and also the cost of that lost momentum on the original feature.

Our estimates are out the window at that point.

Is there any good way to handle this?

Some options I've thought of:

  1. assume this is the way things will be, and apply a 'distracted client' factor of up to 100% on all estimates (this is dangerous in the case where we can actually complete a feature without interruption)
  2. educate the client on the costs of shifting gears, and perhaps apply a change premium to previous estimates if they want us to change to working on a different feature
  3. refuse to work on more than one feature/release at a time (aside from bug fixes). This is probably not realistic.

I'm looking forward to hearing about how others have tackled this. It can't be uncommon.

share|improve this question
Why 3 is not realistic? It is the way to go, IMHO – user2567 Oct 22 '10 at 20:20
@Pierre - we've tried this with the client - not something they'll accept. Perhaps it works on some clients, but I think you have to go about it politely, using #2. – ScottE Oct 22 '10 at 20:54
If the deal is not win-win anymore, leave the game. – user2567 Oct 22 '10 at 21:06
@Pierre - we're actually pondering that right now. – ScottE Oct 23 '10 at 0:59
up vote 5 down vote accepted

I think that your #2 is the way to go. Such problems can only be solved by talking to the customer. Tell them that changes are costly - both in time and money. Show them your estimations and indicate where their new changes interfere.

share|improve this answer

I was just about to ask this same question. I think we've all worked for clients/bosses that constantly shift gears. Here's a typical work week for me (at times):

Monday: Boss says, "Hey, I came up with this great idea over the weekend! Lets do it!" So I spend the rest of the week coding it up and testing it.

Next Monday: I say, "Okay, here's that great idea you had." They say, "Eh, I don't care about that anymore. But I did come up with another great idea over the weekend! Lets do it!"

Rinse and repeat.

I'm at the point now that I just ignore half the crazy stuff my boss comes up with.

share|improve this answer
Do you have any better ideas than me? – ScottE Oct 22 '10 at 19:27
I actually did ask this question, just with much poorer definition (…). – Steve Evers Oct 22 '10 at 19:31
@ScottE - Nope. Like I said above, my only recourse these days is simply ignoring the boss's crazy requests, and hope he doesn't notice. – mellowsoon Oct 22 '10 at 19:49
@ScottE and @mellowsoon: I can confirm that this method can work. – Steve Evers Oct 22 '10 at 20:26

Unless they add features and you don't adjust the billable amount, I would think this client is aware of this already since it happens so much. They know it would have been cheaper to do it up front. Whether or not the cost is worth it is up to them.

share|improve this answer
This isn't quite what's happening. We'll quote feature A and begin work on it. Concurrently, we'll quote feature B, which they'll all of a sudden decide they want implemented before feature A, which we already started. Feature A now takes more time to complete due to merging / inertia. – ScottE Oct 22 '10 at 20:53
If feature A costs you more to make because of the client's demands for B, you have to insist on increasing the bill for A. – JeffO Oct 23 '10 at 1:48

I agree most closely with #2. However, you better make sure that you are careful with the wording in your contract.

Obviously, you are going to have to have some flexibility (on both sides) to allow some further feature definition on existing features, and allow for some additional (small) features to be added to fill in any missing functionality that is thought of later.

However, if there are big changes, then you need to make the client feel the cost. Explaining the cost to them is one thing, but unless you actually pass it on to them in a way, they are unlikely to change. It may even pay to draw up a second contract for that new work, if it is truly new work.

Make the cost realistic. You don't want to gouge your client, but you also don't want to have constant context switching - in the long run, that could lead to bad software. If you come up with a cost that actually makes the context switching worthwhile, and they agree to it, then everybody wins.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.