Manager causing scope creep [closed]

Question

I've been working as a team lead on a series of tight-deadline projects for a very high-profile client. I make sure going into each one that the scope of work is very clearly defined, with the client's help, to ensure my team doesn't get swamped by unexpected work while they're under pressure already.

Unfortunately my boss, the actual delivery manager for all projects under this client, has a habit of forcefully (and often) changing our priorities and inserting new deliverables that are outside our scope of work, his reason usually being as vague as "We have to have this" or "The client needs this now." After going through this several times I have noticed he is wrong every single time, and is sometimes even completely contradicting something the client stated directly about our timeline or expectations.

What's worse is when this work causes an actual deliverable to be late, he does not hesitate to throw my team under the bus in front of the client, and I can only imagine what sort of image that gives them of our company. Such confrontations have lead some team members to get burnt out and quit the project.

I've tried to diplomatically push back on these requests but the more I push, the more forceful he gets. Is there something I should be doing differently? Or is this manager just a lost cause?

Edit: To clarify, my whole team is client-facing to some extent (I personally deal with the client more often than the manager does, with regards to my projects) and are usually all present when the bus hits. Post-bus, the rest of the day (well into the evening) is usually filled with angry emails/calls/messages from the manager to seemingly random members of the team (rarely me directly, because I'm the only one who pushes back) regarding the status of whatever deliverable was delayed that I would easily classify as "badgering" to get it done.

Answer 1

When your manager wants to reassign your priorities or wants to add scope to your project, clearly communicate to him the cost of this. You can do this like this:

"We might be able to add this feature, but we are already 1 month behind our project plan. Adding this feature would take an additional 3 months, so when you insist on that it is to be expected that the whole project will be 4 months late."

Your boss might try to haggle. Never fold to that. What some managers fail to understand is that time estimates are not a negotiable offer. They are a factual assessment of the situation and facts can not be discussed away. The only way to modify a time estimate is to modify the scope of the request.

There are three possible responses your boss can make to this:

1. Decide that the feature is not worth the delay.
2. Decide that the feature is important despite the delay and that the deadline needs to be extended to accommodate for it.
3. Insist that the feature is necessary but that the project must also be completed within the original timespan.

When the latter happens, you need to make it clear to him that this is not possible to do. You can try your best to fulfill the request, but it is very likely that you will fail. Send these concerns in writing, so you have documentation that you warned him this would happen. Then try your best even though you know you will fail. After you failed, you have documentation that your failure was not because of you but because of a project planning failure from your boss.

Answer 2

I've dealt with very similar characters to your manager. My opinion and approach would be rather to push back on this (as you do not know what external influences are pressuring them to request the scope creep items) but document each one and the effect it has had on your ability to deliver. This will help you should you be 'thrown under the bus' at a later date.

Rather than push back, all you can do is make the manager aware of the effects of adding the additional functionality. If they are the project sponsor/client liaison, you have no control over them and their ability to amend the requirements. All you can do is be flexible and make people aware that time spent re-prioritising or re-engineering stuff to fit in the new items is time that could have been spent delivering other items.

This is far far FAR more frequent than you probably think.

If the requests are contradicting the client requests, you could set up a working group to review and sign off each request before it is considered accepted and ready to work on. If the client is party to this group, that is the stage at which these requests get flagged as not required. This does still require your time though

Answer 3

When I've encountered this sort of scenario with someone who directly faces the client and provides conflicting information or tasks that will put an actual deadline in jeopardy, I always ask to see it in writing. Just as your organization has an individual responsible for interfacing with the client, they have someone responsible for interfacing with your company.

When a task such as this comes up, ask to see written approval from the client before deviating from an endangered task. Make sure the written approval states the risk, the knowledge of the risk and the importance of the deviation. Projects with deliverables often have rigid, pre-planned timelines that are agreed upon by all entities from the client down to the team doing the delivering. It should be trivial for this person to get the written approval if it is indeed necessary.

The wrinkle here is that this person is your boss. It could be that this person will give you an ultimatum eventually. There are a large number of options available, but each has a consequence that you have to be able to live with when everything has run its course. As with any situation, I recommend you handle it at the very lowest possible level.

1. Have a private, very direct conversation with your boss indicating that this behavior is contrary to a good product and while it looks like it's "satisfying the client" in the short term it is hurting the client in the long term. Make it clear to him that this kind of scope creep doesn't just put pressure on your team, but it puts pressure on the entire company to live up to an unrealistic standard. Consequence: This is mildly confrontational, and even in the face of justified facts and reason it may be perceived as you telling him how to do his job. Try to avoid that at all costs, but with some folks it's inevitable.
2. If you can't handle it locally, I'd recommend speaking to his boss regarding it. Keep it private. Keep it informational. Keep the tone entirely about asking for guidance on what YOU can do to handle the situation. While your boss will consider this tattling, you can still avoid that stigma by making sure you are putting the onus of effort on yourself. Consequence: It's possible that if this communication gets back to your supervisor (and it will), that he'll consider it going behind his back. This is my least favorite method personally.
3. Tattle. Arrange a meeting with you, your supervisor, and his supervisor/manager to go over the situation. Have all of your topics prepared and your facts assembled. Make sure the meeting has a thesis and stay on point. Everything you say must be in support of your specific goal or it will come off the rails. Consequence: You're officially a tattle-tale. It doesn't matter what results come of it, your supervisor will harbor some resentment. Ultimately, however, the clients' real needs should be met and addressed and that's the goal isn't it?
4. Defiance. I don't really recommend this for folks who aren't familiar/comfortable with it. There are a lot of variables involved with this kind of attitude and the consequences when it all goes wrong can be disastrous for you. You are the team lead. It is your job to make sure that obstacles are overcome and deadlines met. This person may be your supervisor, but he has become an obstacle and is threatening your deadlines. Complete your deadlines as promised. If this new scope creep doesn't get done, explain why. Be factual. Be dispassionate about it. Don't let it be a surprise. Make it known from the moment the scope creep enters until the minute the scope creeped deadline goes by. Consequences: Vastly innumerable. Best case, your supervisor gains a respect for you as a leader who sticks to his guns, works hard for his team and gets done what needs to get done. Worst case: Supervisor deems you a "non-team player" and sacks you. Most results end up in the middle. Your mileage may vary.

My best recommendation is to go with option 1 and keep it as quiet and as low on the "food chain" as possible. You can even ask to be present in some of the meetings to help prevent your team from residing under the bus. In any of the suggestions above, however, note that I recommend keeping everything compartmentalized. Discussions should stay between you and your supervisor and his boss (at the most). Complaints always go up, never down. Your team should never be privy to any dissension or malcontent on your part. They have their tasks to do, and your issues should not weigh on them. If they bring it up or are already asking questions about it, let them know with confidence that you're working on it and you have a plan in place.

Personally, most situations I've ever experienced are always handled on option #1. I've never used #2 or #3 personally, and only had to resort to #4 on a couple of occasions (in 20 years). In all cases, when you make your choice, be prepared for the fall out. There will be some no matter what you do.

Answer 4

I like the current answers, but one little thing I wanted to mention was from your edit:

"Post-bus, the rest of the day (well into the evening) is usually filled with angry emails/calls/messages to seemingly random members of the team regarding the status of whatever deliverable was delayed that I would easily classify as "badgering" to get it done."

Who is doing the badgering? Your superiors? Your clients? While getting thrown under the bus is never a good feeling, this easily becomes completely unacceptable to me. This is your team, and disrupting them from working with "are you done, yet?" would not make me a happy person.

• coming from clients: Ask your team to forward such complaints to you and not to worry about them. Push back.. if you've recorded the instances where priorities shifted, leaving you from completing core objectives, you have those to fall back on. Hopefully, you also recorded the "updates" to your project scope and how it will affect deadlines - and have those approved by your manager. You now just show the documented expected work, with the expected outcomes of changing priority - which was approved by your manager. Address any further concerns with him and stop bothering the team.

• coming from superiors: Explain how the situation is yours. If they need anything further from your team, come to you. Badgering hurts their productivity. You don't appreciate being micro-managed. With the same documentation example as the above, show how you estimated the changes, which were approved. (hopefully estimates are accurate, but if not, then explain why that was. In reality, every estimate being accurate is impossible.)

In both cases, a re-estimate should be provided. So they don't have to wonder. Sometimes the only answer is: "when it's figured out". That can be tough, but bugging about it is just slowing people down. You'll let them know as soon as you know.

Answer 5

I have a totally different answer for you:

1. Realize that you are a beaten dog beneath this manager, and as a result, you've become unaware of your worth, and unaware that there are better places to be. Sit in a quiet room with a simple Notepad app running, and type out all the good qualities you bring to the table, for any company delivering IT projects of the type you manage.

2. Now that you've regained your confidence, update your resume.

You know the rest.


In my 20 years, I've been in your shoes three different times, and I've tried much of what the good people on this post have recommended. Through it all, I learned that, if a manager like yours can attain a position of authority, it indicates the corrupted values of the company that put him there, and the best of your intentions will not change it. Politics always wins, and boy does it wear you out while you're losing the battle.

I have always moved on, and always been happier - except the one time I left one such place for another, got out quickly, and THEN I was happier.

Techies by and large have good hearts, and believe we can deal with anything - but that doesn't mean we should.

Answer 6

In situations like this, the best solution may be utilization of a formal "Change Order Request" or COR. When new items or functionalities are requested -- by whomever -- it gets put onto a COR, including associated time and cost, and before it gets added to the scope of work, it must be signed off by the client. A COR allows everyone involved to assess the value of the additional work, its cost in both dollars and time, and the mutual agreement that the change is worth it or not.

The beauty of a COR is that everyone gets tired of seeing them crop up frequently. It propels the client to define the project more clearly, while giving your manager a tool to legitimately add scope.

Answer 7

You've met with the client rep at the beginning of each sprint, or project. The two of you (or your teams) have come up with an agreed upon scope of work for that duration. That is your official list. Put it down on "paper" (document/spreadsheet, what have you) and send a copy of it to your manager titled something like "Project X - client agreed scope of work".

Now let your manager manage. If/when he adds new scope/deliverables, add it to your official scope list and then email that back to him.

Let this go for a cycle (or two). If he doesn't adhere to the list and you feel strongly enough (and are willing to accept the consequences, whatever they may be, including termination I suppose), you could up it a notch or ten and send the agreed upon initial scope list to the client rep, and then each time your manager adds to it, send that as an addendum to the client. That will ensure you are covered from the point of view of the client. Just know that your career at your current company may be shortened.

Answer 8

In my experience what happens is that this particular project becomes more and more of a gamble, instead of a planned profit making endeavor. As it becomes clear that to make money on the project, things are going to have to go faster, an especially seductive way to supposedly make this happen is for managers to use brute force authority to 'make' the project go faster. What really happens is that they just end up adding risk to the project timeline and schedule. It might work out that certain tricks or new techniques will save you 10% 15% even 25% and the project will come in right on time and everybody wins. But more often than not, statistically, things don't go quite as planned, estimates are off, not by being too long, but by being too short, delays in communications, misunderstanding, mis-coordination, etc cause lots and lots of re-do work which lengthens the project.

In my experience what happens, when management continues to brute-force, add risk to a project, there is nothing really that can be done to correct it. It is their prerogative to run it and you are the subordinate. What WILL happen, however, as the goals are totally unobtainable, is that something will slip. 9 times out of 10, what slips is the quality of the solution. The appropriateness of the features shipped, the quality of the code. Basically a lot of things that are relatively easy to hide, and smoke and mirrors over - will take the hit. That's it. the quality suffers, often tremendously. This is sometimes not too terrible, as long as some upper management see this and understand it somewhat.....but, again typically, once management see that they made money that time, in that way, they do it again. And this time, the backbone of the project, the existing code base is hopelessly defective, and is used as the foundation for the next project or a similar project for a new client. That's really when everything breaks loose, you have lots of people getting fired, heads are down, etc.

It's just like a stock market bubble kind of thing. You can ride a low quality code base for a while but eventually, just like stocks, somebody finds out and it all comes crashing down. Where you are when that happens, well, who knows. Give your stock broker a call and see.

Answer 9

What we have done during requests like this is (having estimated the original scope) sit down with the project owner (I would assume this would be your boss and the client) to review the request and say yes it could go in... but what should be removed from the original scope to accommodate this feature and still deliver the project on time?

They will often then sit and weigh up what actually is a big priority and small "feature creep" items will usually not then be added into the scope.

Answer 10

Most answers here show you how to deal with a normal reasonable person and you can try them, "hope dies last" ;-)

What you are dealing with is the typical workplace psychopath, who is not interested in the client, the project, the team, the company or anything other than his own profit and career advancement.

There is usually two ways this goes, either management is smart and they figure out he has to go before he destroys the company or they think he is doing a great job and he gets promoted to the next level.

Whatever you do, make sure you have a plan B ready, best outside of this company. Me personally would go into documenting everything like suggested, but also involving the next higher hierarchy level. I would ask them to keep it confidential and that you will try to handle it, but just so they know what is going on, you will send them copies of all the strange requests the manager does. (not sure that's legal, last psycho I dealt with was fired before it got so far)

If he is anything like the guys I know, he will not understand subtle or tactful, even with strong words he will twist everything around. Write short and easy to understand, sentences, also send him mails of anything you discussed verbally, they like to give undocumented orders and then pretend you made them up.

Include statements as "like already discussed, this will add 4 weeks to the time estimate" or "the client specifically said not to ...".

Prepare for a battle on a whole different level than your usual work discussions, when put in a corner the typical pscho will do anything to get back on track. Lying and spreading rumors is their native language.

About the time management and estimates, they should only come from you and your team, if the manager were smart enough to do them properly, he would not be a manager. This problem is a very old one and there are good books about it, for example the pretty old "Peopleware", recommend reading it.