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:

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)

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

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.

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.

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.
–
ScottEOct 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.
–
JeffOOct 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.