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.

  • Why 3 is not realistic? It is the way to go, IMHO
    – user2567
    Commented Oct 22, 2010 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
    Commented Oct 22, 2010 at 20:54
  • 2
    If the deal is not win-win anymore, leave the game.
    – user2567
    Commented Oct 22, 2010 at 21:06
  • @Pierre - we're actually pondering that right now.
    – ScottE
    Commented Oct 23, 2010 at 0:59

4 Answers 4


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.


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.

  • Do you have any better ideas than me?
    – ScottE
    Commented Oct 22, 2010 at 19:27
  • I actually did ask this question, just with much poorer definition (programmers.stackexchange.com/questions/13384/…). Commented Oct 22, 2010 at 19:31
  • 1
    @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
    Commented Oct 22, 2010 at 19:49
  • 1
    @ScottE and @mellowsoon: I can confirm that this method can work. Commented Oct 22, 2010 at 20:26

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.


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.

  • 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
    Commented Oct 22, 2010 at 20:53
  • 1
    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
    Commented Oct 23, 2010 at 1:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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