How do you convince upper management that something can’t be done?

Question

When you are employed as a developer, you usually don’t get a chance to choose on what you will work. It might be a new application that must be written, it might be an old one that needs maintaining, or it might be a legacy system in which you have to plug holes just to keep it at float.

Whatever the case, there is one thing that is always the same: “deliver the thing before the X date in perfect working condition”.

Ideally you can choose when the X date will be (more or less). You make an estimate of the work that needs to be done, you present this to upper management, they take it to the client, the client says “No... that’s too late” management trims the deadline etc, so you get more or less a delivery date around date X.

But sometimes the client comes and says “I need this working like a charm before X date. Period!”.

Now, it might be a development that takes too much, it might be fixing an application that needs to be put out of its misery and the fix takes too long.. etc.. etc.. but something that can’t be humanly feasible until the X date, much less working like a charm.

Upper management won’t tell the client to take his stuff and go somewhere else, so you are stuck with it. No matter how you choose to do the stuff, no matter how many people they bring on the team, some day the s**t hits the fan.

How do you convince upper management that it can’t be done? (and may I add “Period!”)

Answer 1

I am happy to have the understanding team and management. So when something cannot be done or can only be done badly with consequences, I just bluntly tell it.

Important is to tell as soon as possible, not a day before the deadline.

It also helps if other team members support your position and can express their opinions to confirm your point of view.

When you're putting it forward, bring arguments, provide explanation, talk about consequences.

Something like "If we do it the code will look ugly" will not cut it.

Saying it like "Doing this will require reorganization of the module Y which will need M weeks time to accomplish and N weeks time to retest it otherwise there will be numerous errors and the potential for customer data corruption" will be more convincing.

Answer 2

As a "lowly" developer, you don't have to convince upper management. If the project generates problems, it's the upper management who will be held responsible. It is very important anyhow that you report your opinion and make sure it is written somewhere so that you don't take blame for the error of someone else. After that you do what you can.

Answer 3

"I need this working like a charm before X date. Period!" could be dealt with the following framework. I understand having X ready by Y is important to you, but unfortunately we won't be able to meet this request. What I can offer you is a subset of X by Z.

Answer 4

That's not your task. Upper management decided that you can deliver on day X, so that's what it'll be. Of course, it won't work, but they already knew that, didn't they? Still, they decided that the product will be shipped on day X, which means in my book that they already have a strategy to deal with the predictable miss of the deadline.

You're role in this game of wits is to make sure you can't be blamed for the delay. So make sure the management sees your progress. At the same time, if you can, let them know several ways to meet the deadline. They might turn you away but at the deadline, you'll have written proof "told you so". That is to make sure they can't use you as a cheap scapegoat.

Answer 5

They key is that they don't care about the technology (this you already know) so you have to explain why it's impossible in terms that they do care about:

• Risk
• Dependencies
• Cost
• Time scales

When people ask for a change they normally think of the benefits but not the downsides. What might break if it goes wrong? Will it be slower or harder to use if you hack together a solution? They usually hate the word "regression."

It's all well and good you committing to finishing some work on a particular schedule but are other teams working to the same timescales? Do you need anything from them before you can start? Are you going to waste a day if a DBA won't change a database view for you?

The last two are kind of the same unless you use some specialised equipment or need more gear to get the job done. Obviously you can't explain very low level changes, you can show why something is harder than it first appears. "This button affects this... and that... then this screen will need updating... plus the database and the reports..." People don't always consider the full magnitude until it's spelt out.

Finally, are the requirements well defined? If not you can document what you will deliver on time and consider anything else as a "change request" that will take extra time.

The danger with some of this is that you'll get a reputation as being unhelpful or negative, which means that it's very important to deliver on your promises. If you offer workable alternatives, make sure they really do work and are delivered on time. If you say you need an extra week, make sure it really does take a week or less. You're only unhelpful and negative if you're consistently wrong.

Answer 6

Upper management does not want to hear what cannot be done; they want to hear what can be done. So tell them what can be done and under which conditions. This shows that

1. you're willing to do the task
2. you have given it a though
3. you are giving your commitment that with your conditions it is doable

Answer 7

Personally as a manager myself I would never say "something cannot be done". As a developer I've been there myself, knowing deadlines are too tight and timescales are intense, then having a good old moan about it.

As the developer put your point forward and ensure that it's stated you believe the deadline cannot be met with your current resources, resources being the key point in your assessment. Then, the managers can assess the situation and pull together internal or external resources to meet the requirements of the client. This way the responsility is clearly placed back in the hands of the manager and you can do your best to complete your part of the project.

In the end this is what developing in the real world is all about. Writing code to tight deadlines with the pressures of business and profit based decisions.

Answer 8

First it helps to know why the date is unmoveable. Sometimes there are outside things that affect that ( a new law that takes affect 1 July that they must compy with is an example). If you know why, you may be better positoned to give them what they need by the deadline and deliver related but not as critical items a bit later.

Next recognize that management is trying to make the customer happy. This is especially true when there has been a problem with the customer and the customer is currently unhappy. You can remind the manager that often the customer will be happier with a solid application delivered a week later than a buggy product delivered on time.

The key is to let people know as soon as possible, why the deadline won't work (not the day before!), what can be done about it (will more people help? Are certain shared resources (dbas, testers) not available but could have their priorities changed if management wants to. Can the release be split up into two?) If you agreed to a deadline and then unexpected problems came up, inform the managers and have the inform the client as soon as you know the impact of those events, things like testing uncovered a module that your change broke that nobody planned originally to touch or the developer had a family emergency and someone else had to take over but you had to wait until some higher priority work was done, etc.

If in general the deadline would never have worked, it's a bit trickier. Create a project plan showing the steps that need to happen to produce the end result and the time each task will take. Show the available hours of people currently assigned to the project and what else they may also be assigned to work on (and the priority od other tasks). Then when it is clear that hours to do task > hours avaiable to do task, ask them what needs to be done. Most of the time they will move the deadline or cut out some part of the requirements or reduce the testing hours. If testing is reduced, then make sure you doucment back to them the risks of doing so. Now this normally should be done by the team lead, as a developer you can only provide him with an input concering your own part of the project and ask him what to do. It is important to do all of this in writing as it documents that there were problems identified with meeting the deadline. It is also easier to go back to the client with a project plan in hand and show them the problems with meeting the deadline. Managers will ignore grumbling about a deadline but it is harder to ignore a document that clearly shows why the deadline won't work and specifically asks what to do to fix the issues.