-->

What is Scope Creep? [closed]

2020-08-17 06:30发布

问题:

This is going to be the noobist of all noob questions, but what exactly is scope creep, what does it entail?

回答1:

Scope creep "refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided."

Source.



回答2:

You start with a mouse and end up with an elephant.

In other words requirements change on a daily basis and what you are supposed to deliver doesn't look anything like what was supposed to be delivered at the start of the project



回答3:

Wikipedia expresses it more completely than I could.

Scope creep (also called requirement creep, or kitchen sink syndrome) in project management refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. It is related to but distinct from feature creep.

Scope creep can be a result of:

  • poor change control
  • lack of proper initial identification of what is required to bring about the project objectives
  • weak project manager or executive sponsor
  • poor communication between parties
  • lack of initial product versatility


回答4:

There are two definitions for scope creep.

  • Negative. Scope changed in uncontrolled ways adding cost and risk.

  • Positive. Scope changed in uncontrolled ways because our fantasy project plan was wrong, and we starting learning things we didn't expect to learn.

Most folks seem to like the first one.

The second one, however is more accurate. The few managers who recognize that scope creep -== learning are able to manage it wisely and get stuff done.

The rest of the managers see uncontrolled learning as a threat. The project won't create the hoped-for deliverables in the fantasy schedule or budget. This means that either scope needs to be reduced or budget needs to be expanded.

Note that most Agile methods don't seem to care much about scope or scope creep. With a narrow focus on the next release, the big picture becomes less threatening and scary.

Learning -- in an Agile context -- also leads to scope creep, but it's a good thing. Stuff that won't ever be useful is deferred. Stuff that didn't seem important when we started gets accelerated.



回答5:

It's when a project incessantly gets larger and more complex than what was originally planned for, and therefore is perpetually behind schedule and over budget.



回答6:

When you start your project, you set certain parameters. These parameters are your scope. You should think about what your project is supposed to do, how much will it cost, and how much time is it going to take to complete. When more functionality, time, money.... creeps into the project this can be referred to as "scope creep",



回答7:

Scope creep is when requirements keep being modified or added to current product release. For example, you show a demo to the customer/user and they request new reports/buttons/fields. It can also occur when a developer wants to add new "cool" features, etc without needing them. It is best prevented by managing the project release cycles. People suggesting features is a good thing, but everybody involved needs to understand the impact on the project and budget. Consider adding new feature requests to a list and meeting regularly to decide which new features get added to the "next release".



回答8:

In the case of feature creep in my view there needs to be an element of contributing to the downfall of a product. For example growth of a city is good - urban sprawl is bad.

Or in the case of UI design.. all related features get stuck on one control screen - new features are continually added to the point where their mear existance confuses more people than would ever find the features useful.

To qualify as feature creep they should pass the test of contributing to unecessary complexity or throwing unecessary wrenches in the lifecycle of the system. Origionally unplanned features that do not meet this critera should not be concidered feature creep.

Scope Creep is concidered in the same light as feature creep only at the level of a products scope... For example:

Your team is building an "Air Sucker"(tm) which sucks air from one location and transports it to a factory two blocks away. The scope of the air sucker is that it moves air.

Then management realizes the sucking device also needs to suck and transport water and sand. The Air Sucker was never designed to transport liquid or granular materials and thus increasing the scope of the air sucker to the point where it must be significantly reengineered to meet the new transport requirements.



回答9:

If you have appropriate change controls, possibly a cash cow.

There's a famous picture of a big power boat with a little runabout in tow. The runabout is called "The Original Contract", and the power boat is called "The Change Requests"



回答10:

features, budget, schedule: pick any 2 but not all 3



回答11:

Scope creep is any change to the originally agreed on specification/project scope/definition. The change could be due to discovery of prior unknowns, internal/external market changes, technology changes or plan ole' sponsors wanting something more. It negatively impacts the project when there is no change control process in place to review and accept or reject the change.



回答12:

And how does scope creep affect product schedule? Is there a way to keep scope creep out of your development process? How does your PM handle scope creep? What was the best feature to ever come out of a scope creep? etc. etc.



回答13:

Scope creep is like pornography: you know it when you see it.