Time to Retire "Scope Creep"?

I recently saw an email from a project sponsor that simply replied "SCOPE CREEP!" in response to the BA's concerns about whether the report being made as part of the project was going to adequately cover the business needs of the client. The BA had suggested a few additional requirements, like formatting and additional fields to include in the report. This was after the charter was written, but before the user requirements had been captured. I was flummoxed by the response.

How exactly is this scope creep? It seemed to me the scope of the project was "create a report for the client" along with some basic information about what the report would contain. In our organization's process, the charter is usually fairly high level, and is followed by a requirements analysis from a BA who comes up with the specific details for what the product should do. In my mind, the BA was simply fleshing out the requirements. If the BA had suggested a second or third report, sure, I'd (reluctantly) call that "scope creep."

And furthermore, even if the requirements deviated a little from the original scope, what's the point of making a report that's not going to be useful for the client? Should the original scope be strictly stuck to come hell or high water, even if it results in a shoddy product? Is a project one that just stuck to scope? No!

"Scope Creep" has to be one of the most used and abused project management-related terms out there, and sometimes I want to find the person who created the term and shake them. To be sure, many projects fail because the scope got out of control. But I'd argue that the real reason those projects fail was that the original scope was never clearly defined in the first place. It's easy for the scope to change and a project to be delayed if there was no clearly defined scope to begin with.

The PMBOK never intended scope to be something that was set in stone. It just states that it should be defined at the beginning of a project, and any changes should be reviewed, and approved or rejected based on whether they're deemed worth it to the project. The whole point is to look at changes critically and make smart decisions about them. And yet, scope seems to be one of those things that some PMPs and "armchair" PMs  seem to cling to as the most important part of project management.

At a PM class I took last year, the instructor asked the class what they should so, as PMs, if someone asks for a change to the project. I was surprised that many of the answers were along the lines of "explain that the change does not fit within the project's scope and that we cannot proceed with it." I wanted to tear my hair out. Being the "scope police" is not what being a Project Manager is about. To be sure, we have to be careful about the scope of a project, but change is not always a bad thing, and sometimes, if dealt with effectively, it can be one of the most important elements of a successful project.

So, I'm hereby proposing we retire the term "scope creep". It's too easy to cling to as a buzzword, and distorts the role that scope should play in a project. Any suggestions for a replacement?