How to tell a project manager "NO" to scope creep
While project managers may each have their own personality and management style, it seems that many of them have a pernicious love of sneaking in "scope creep" when they can (whether anyone is watching or not). While they usually mean well (bless their hearts), what's the best way that you've found to say "NO" to project managers?
Let me start by saying that if a PM is "sneaking in scope creep" he is a very bad project manager.
Having said that...it's not your job to say no to a project manager. It's your job to ensure that he knows and understands the costs and risks of the change he is making. If the PM insists on changing the scope and adjusting nothing else in the project, get another job (because the project and/or company is doomed).
A good rule of thumb is to always answer, "Okay. What should we drop to get this in by the deadline?" and/or "Okay. If we move the deadline to X, we can add that in."
Every change affects completion time. There's no such thing as a zero-time task. Forcing a project manager to realize that quality, deadline, or feature list will suffer every time they make a change will go a long way towards getting them to think right about scope creep.
By having good costing and feature design for what is in scope, taking it back to them and asking if they want to move the date out, or cut other features. If the latter, what features are no longer important that haven't been started yet?
The easiest way to do it is be firm and tell them that it will affect the release date if you include the additional feature(s). Ultimately their job is to ship a product on time, so the bottom line for them is "can we fit this in without breaking the schedule". If the answer is no, then any project manager worth their salary should fall firmly on the side of development in agreeing it's unacceptable scope creep.
Explain that there is a tight dependency between ship date, quality and features. Tell them that if they want to meet the ship date the quality will suffer if the new feature is added.
Chances are, while you suppose that your project manager has a 'pernicious love of sneaking in "scope creep" when they can', his perspective is probably different. It is probably more productive to make sure you understand his point of view.
This is of course in addition to communicating your own point of view, namely the consequences of the scope creep. You probably need to explicitly identify the additional work in your development plan, estimate how long the additional work will take, and explain that this means a delay or dropping some other feature.
This only works if your estimates are any good. This does not work if you do the additional work off the books, so that the additional time spent is not visible. Otherwise, you might meet the deadline for other reasons, such as harder work or efficiency gains, and your project manager will just remember that scope creep did not affect the delivery date 'last time'.
By pursuading him to understand how you are trying to help him save his job (i.e. you are telling him the truth.) He's got more at stake than you, I imagine.
If you want to succeed in your organization, you will want to be a team player and should strive to demonstrate your commitment. Sometimes, this means putting in some extra time to get a great new suggestion into the product.
However, you are more likely to command respect by placing firm limits on what can reasonably be expected of you. One way to do this is by helping managers to understand that they are not going to improve a product by engaging in scope-creep but that they are more likely to hurt the product in the long run.
Are the bits that get crept into the project being asked for by the client? Are they valuable items to deliver?
There is certainly an issue with the PM if they are sneaking things into the scope and not making them visible. This is a serious concern and something I would raise with them directly and openly.
However, scope creep (in my book) is perfectly acceptable if it continues to meet the requirements of the business. Sure, you have deadlines, but what's wrong with being flexible on what you deliver on that deadline? This is where visibility is critical.
Something that has worked well for me in the past:
I am taking it that if your project manager wants to sneak in features they do not have an accurate project plan. Keep your own task list with an estimate of how long each task will take, ordered by priority - it doesn't need to be elaborate just a text document or spreadsheet. If your project manager wants you to add a new feature, send a copy of your list and ask where you should insert it in the priority order.
If the project manager tries to negotiate down your time estimates then just say "I will do my best, but I can't guarantee anything."