How do I avoid scope creep on a software project?

Write the scope down and have the sponsor approve it, including a short list of what this version won't do. Then send every change through a request that someone with authority approves, with its effect on the rest of the work visible before anyone says yes.

Scope creep is rarely one big change. It's many small ones, each reasonable on its own, that nobody adds up.

Where does scope creep come from?

• Gaps in the original specification. When the rules or exceptions weren't written down, the developer has to ask, and each answer can add work.
• Disagreements found late. When two departments wanted different things and nobody noticed, both versions tend to get built.
• Good ideas during the build. Seeing the software prompts new requests, and they arrive one at a time.
• No clear "no." If nobody owns the scope, every request is a maybe.

How do I set the scope up front?

Describe the problem and the goal, list what the software will do, and list what it won't. Settle disagreements between departments before the build, and have the sponsor approve the result. A clear "not in this version" list is one of the simplest protections you have.

How should changes be handled?

As change requests:

• Someone writes the change down.
• Its effect is visible: what else it touches, including tests.
• The person with authority approves or declines it, and the sponsor decides anything that changes the approved scope.
• Approved changes produce a new, dated version of the specification, so the builder can see which one is current.

Is every new request scope creep?

No. Some changes are worth making. The point isn't to refuse change; it's to make each one a decision, with its cost and effect understood, rather than something that drifts in.

What about changes that are really a new application?

Keep them separate. Something that would be deployed as its own system is better specified and built as its own project, rather than folded into this one.

In Mochlion, approving the scope fixes which application a project covers, and changes after handoff are change requests with a report of what they affect. See what happens if your needs change after handoff.