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?
+10
A:
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?
Joe
2009-01-20 23:20:20
+5
A:
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.
Jay
2009-01-20 23:22:03
not necessarily true - a PMs job may be to ship on time, it may alternatively be to deliver a certain quality standard or a certain feature set, or a combination of the three.
flesh
2009-01-20 23:34:56
@flesh - That's true; In that case, tell them adding the new feature *will* affect the date, feature set, quality standard, or a combination of the three ;)
Jay
2009-01-21 00:29:36
@flesh: you know the saying: "good, cheap, early, pick any two".
philippe
2009-01-21 07:36:54
+29
A:
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).
Jim Blizard
2009-01-20 23:22:05
+1 for the bad PM comment; +1 (if I had two...) for informing the decision maker what scope creep means for the project and letting them decide how it should be handled.
Austin Salonen
2009-01-20 23:46:51
it absolutely is bad project management. but in the real world you can't just quit every job because someone above you isn't perfect, when a simple reminder of the correct way to handle a variation would do.
nailitdown
2009-01-21 00:49:16
I think the point about getting another job comes down to; scope-creep (without change orders) = over budget -> company losses -> (and if carried on long enough) a bankrupt company. OR an employment opportunity when he/she gets fired.
CodeSlave
2009-01-21 01:45:09
If you define a good PM as resisting scope creep, then I have never met a good PM.
J3r3myK
2009-01-21 05:49:03
I agree that a PM that introduces scope creep is not doing their job HOWEVER if it's uncovering work that needs to be completed and previously not discussed (oh...we have to install MS SQL Server in order for the system to work?) or the like then it's the PM doing their job
meade
2009-01-21 10:57:51
A prime job of the project _manager_ is to manage scope. If there is a need to change the scope the PM should manage it. "Sneaking in..." is not managing.
Jim Blizard
2009-01-22 02:52:14
Couldn't agree more. A better question is.. how do you handle/minimise the impact of a bad PM?
RobS
2009-01-26 13:25:50
+4
A:
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'.
Peter Hilton
2009-01-20 23:29:24
+5
A:
Be honest
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.
Sam Saffron
2009-01-20 23:31:54
+2
A:
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.
le dorfier
2009-01-20 23:32:17
+18
A:
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 effects 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.
Jekke
2009-01-20 23:35:04
+1 - don't say no, say yes. scope creep is absolutely fine as long as it's handled properly. "sure we can add that in. you put through the variation and add it to the plan"
nailitdown
2009-01-21 00:47:37
grammar nazi in me has been evoked - you want "Every change *a*ffects completion time". Effect = "to bring into existence or create". Affect = "to alter".But yeah, you're absolutely right.
Tom
2009-01-21 05:07:48
+2
A:
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.
Mark Brittingham
2009-01-20 23:36:08
+1 for the second paragraph, but it seems to contradict the first. If the "great new feature" isn't appropriately paid for (blood, sweat, and tears should not be payment alone -- startups excluded), it would hurt the organization.
Austin Salonen
2009-01-20 23:53:58
The two were meant to stand in contrast to each other. There *are* times when some extra effort can pay off both in your reputation and in terms of the product. The risk is that you are always expected to put in "extra effort" for no additional pay. Thus, the balancing act.
Mark Brittingham
2009-01-21 01:09:54
A:
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."
trilobite
2009-01-21 10:35:08
+1
A:
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.
Carl
2009-01-28 01:20:57