When do you blow the scope creep whistle?

Question

Most people have been here at some point or another - in your project, you get really small requests along the way that you're happy to take care of, but at some point the little things add up. Sometimes it takes less time to implement something than it does to re-negotiate the project plan.

Providing the spec/requirements plan is decent and it isn't a doomed project to start with, at what point do you actually blow the whistle and start re-negotiating? At any request? When that request requires additional pages / forms? Or just feel it out? Would love to hear how you make the call.

Answer 1

Budget N hours of ad-hoc requests in your project plan. (You know it's going to happen, so why isn't it in there?) Then track your ad-hoc requests and renegotiate when the budget's blown.

Answer 2

I'd say when it's going to impact the schedule/release date. If that happens, it's definitely time to blow the whistle. If either the scope creep is of sufficient magnitude, or if there are enough cumulative changes that it's impacting your ability to ship on time, then you should push back.

Answer 3

The moment your budget gets blown. You can't keep doing all these "freebie" add-ons - unless you are doing it for charity.

Once you've put your foot down once, you'll find the requests drying up!

Answer 4

The estimated completion date is more of a probability curve than a single date.

Any extra feature reduces the likelihood of meeting some particular date.

You should 'blow the whistle' if and when the decrease in likelihood becomes 'significant' or worth mentioning.

Answer 5

At any request?

The real goal is to make the customer happy while not getting ripped off, right? Agile methods address these issues to a large extent. New requirements always come up, and if you don't address them as they come you end up building things that are obsolete or dysfunctional out of the box. So what you need is customer buy-in to the process, a working prototype as soon as possible, and lots of iterating. There's a ton more, of course, but that should be enough to be getting on with.

Edited to add: Customer buy-in means they are aware of you working on a new feature instead of whatever you would be doing, and that they are in agreement. When you've gone through your schedule and budget and still aren't done they they've been there with you the whole way and know why. No big surprise "What? You're not DONE?!"

Answer 6

I have only been in this situation with internal tools where our stated goal was to best serve any whim of our "customers" in a situation where there was no way to predict needs in advance. So take my answer with a grain of salt.

My view is that the decision is often political, and unless you're the head of the company it might not even be up to you. The cost of unsatisfied customers going over your head to your boss can be more damaging.

I'm a big believer in agile and continuous requirement gathering that does involve seeing how users work with the product, and trying to match their needs. However, every user has his individual "nice to haves" and there's no way to satisfy everyone. If you have multiple target users, democracy is a good system - only implement things that the majority of the users can benefit from.

If your clients are a cohesive group (e.g., you're making it for users in a specific department in a specific organization), run a Wiki site or something like SO or other engines where they can list and then collaboratively vote on possible features. Make it clear that you will give priority (but no guarantees) about higher rated features, and that you're probably not going to give priority to things that don't get votes from others.

In doing so, you may be able to get the clients to apply some collaborative filtering (or peer pressure) on ideas. You will also get some visibility, so people can see why their wishes were not respected. An important side benefit is that whoever requested a feature now has an interest in formulating the request and its rationale well, so that they can get others to vote for them. This will eliminate some asinine half-baked ideas.

Of course, an underlying assumption of all this is that you budgeted some time to "misc features" with whoever is paying for the projec.