7

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.

ScottE
  • 463
  • 3
  • 7

4 Answers4

5

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.

underdark
  • 386
  • 2
  • 8
2

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.

mellowsoon
  • 451
  • 2
  • 5
  • 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 (http://programmers.stackexchange.com/questions/13384/considering-consistent-change-how-short-of-a-planning-period-is-too-short). – Steven Evers Oct 22 '10 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 Oct 22 '10 at 19:49
  • 1
    @ScottE and @mellowsoon: I can confirm that this method can work. – Steven Evers Oct 22 '10 at 20:26
1

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.

Wonko the Sane
  • 3,172
  • 1
  • 24
  • 24
0

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.

JeffO
  • 36,816
  • 2
  • 57
  • 124
  • 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
  • 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 Oct 23 '10 at 01:48