When will you blow the creep whistle?

Question

Most people were here at some point or another - in your project you get very small requests along the path that you are happy to take care of, but at some point the little things add up. Sometimes it takes less time to implement something than to reconcile a project plan.

Providing a specification / requirements plan is decent, and from the very beginning it is not a doomed project, and at what point do you actually blow the whistle and start talking? In any request? When does this request additional pages / forms? Or just feel it? I would like to hear you call.

Answer 1

Budget N hours of special requests in your project. (You know that this will happen, so why is it not?) Then keep track of your special requests and talk to each other when changing budgets.

Answer 2

In any request?

The real goal is to make the customer happy until they tear it apart, right? Flexible methods to a large extent solve these problems. New requirements always arise, and if you do not access them as they become available, you will end up building things that are outdated or dysfunctional out of the box. Thus, you need the client to enter the process, the working prototype as soon as possible, and many iterations. There is a ton more, of course, but this should be enough to continue.

Edited to add: Purchasing a client means that they know about you while working on a new feature, not what you will do and that they agree. When you finish your schedule and budget, but still haven't done it, they were there with you and found out why. There is no great surprise: "What? You are not DONE?"

Answer 3

I would say when this will affect the schedule / release date. If this happens, it is time to blow the whistle. If either the creep of the area is sufficient, or if there are sufficient cumulative changes that affect your ability to send on time, then you must step back.

Answer 4

The moment your budget is reset. You cannot continue to make all these "free" additions - unless you do it for charity.

Once you have lowered your foot once, you will find that the requests dry out!

Answer 5

I was in this situation only with internal tools, where our stated goal was to best satisfy any whim of our "customers" in a situation where it was not possible to predict needs in advance. So take my answer with salt.

My opinion is that the decision is often political, and if you are not the head of the company, it may not even be up to you. The cost of unsatisfied customers passing over their heads to your boss can be more damaging.

I really believe in a flexible and continuous assembly of requirements, which is related to how users work with the product and try to meet their needs. Nevertheless, each user has his own individual "pleasant things", and there is no way to satisfy everyone. If you have multiple target users, democracy is a good system - just implement what most users can extract.

If your customers are a cohesive group (for example, you do it for users in a certain department in a particular organization), start the Wiki site or something like SO or other engines where they can list and then possible functions. Make it clear that you give priority (but not guarantee) to higher ratings, and that you probably won’t give priority to things that don’t receive votes from others.

In doing so, you can get customers to apply some kind of collaborative filtering (or peer pressure) on ideas. You will also get some visibility so that people can understand why their desires were not respected. An important side benefit is that the one who requested the function is now interested in formulating the request and justifying it so that they can make others vote for them. This will eliminate some ideas made from half-baked asen.

Of course, the basic assumption about all this is that you planned for some time on “different functions” with the one who pays for the project.

Answer 6

The estimated completion date is a probability curve rather than a single date.

Any additional function reduces the likelihood of meeting a specific date.

You must blow the whistle if and when the decrease in probability becomes “significant” or worth mentioning.