How can we protest a deadline that is too short?

Question

Our Project manager made a project's presentation and assigned it to our team. The amount of work was estimated at 3 weeks.

Our team members discussed the project and we calculated that the amount of work is 5 Weeks.

We explained to our project manager that his estimation was too short, to which he replied that we should work extra hours at the office to make sure the project is submitted within the 3 week deadline.

What should we do? The deadline is too short. How should we go about protesting?

Answer 1

Imposing deadlines without consulting the implementers and then rejecting their feedback is sign of a toxic work environment. Demanding that you compensate for their incompetence via a "death march" (a project under-funded by about half) is even more toxic. You seem like a competent fellow, so my immediate reaction is Get out right now, and build a happier life.

That said, the crux of negotiating about deadlines is to know what actually is required. If the deadline is to meet some external event (trade show, critical customer delivery...), the useful thing to consider is to reduce the scope of what is to be implemented. If the deadline has been set arbitrarily by someone from "high above", it's clearly meaningless. Is it customary for your place of work to impose dates which are routinely missed? Is this used as a threat to withhold compensation, or to justify firings? Depending on how planning and fulfillment is viewed at your place of work, the best reaction can be to negotiate more time, more resources, more compensation, less features, etc. The only thing you should never do is to accept conditions that you know will only be used against you afterwards.

Answer 2

I would say something like "we'll do our best, but as we've shown, we won't be able to deliver. We'll be glad to negotiate over this. You could pay us to work extra hours, buy us dinner for the nights we work late, or we could cut features or cut quality. How would you like us to proceed?".

Of course, every situation is different. If this is the first time the request has been made, and the deadline is tied to an external event that simply can't be changed, and you're a long time employee who enjoys his/her job, you might want to put in the extra hours for the good of the company.

If this is a common request, however, and you feel you're being taken advantage of, be professional and negotiate.

Answer 3

You do need to push back,. This is simply unacceptable. However, don't just say you need 5 weeks, give him and his boss a breakdown of the tasks and the time to do them to prove it takes five weeks. In your breakdown of tasks make sure to include time to support QA, time to respond to the inevitable changes, time for communication (reading and responding to emails, project meetings, etc.), time for writing unit test and for performing testing and debugging. Tell them what features can be removed to meet the deadline. (Do not suggest getting rid of QA - the worst project I ever worked on eliminated QA before the production launch to meet a deadline, it took a year and half to clean up the mess (and at least 4 managers involved in the debacle got fired) and make the client happy)

Do not agree to work the extra hours to get the job done unless you get paid or get some other reward. Working extra hours generally lengthens the amount of time it takes to do the project because exhasuted people work slower and make far more mistakes. If he pushes back on the hours let him read this: http://www.alternet.org/story/154518/why_we_have_to_go_back_to_a_40-hour_work_week_to_keep_our_sanity

Answer 4

Your profile says you are from India. My experience in working with those from India indicates is it is VERY unlikely a project manager from India will tell their manager/boss directly "no, that's not possible." It's far more likely they will not directly confront them and more or less say "ok we'll try" or otherwise attempt the project.

So what probably happened is your project manager got told by his bosses a timeline and didn't object significantly and is now locked into it. Your team is dealing with the effect of this conversation.

Now, he cannot go to his boss and say "oh, by the way, we can't do this" because it will cause him to lose reputation, etc.

Try approaching things like:

• "We see significant difficulty in accomplishing even part of this project in 3 weeks. Why is this deadline in 3 weeks?"
• "Can we speak with [whoever made the 3 week decision] and explain our concerns with this deadline?"

This willingness to say "we can't do this" is a complete cultural difference in India than the United States, btw.

Answer 5

One Useful phase to stop him in his tracks, repeat every time you get pushed

"We/I do not negotiate our/my estimates, We/I will however......" and follow up with a constructive suggestion. There can be

"Work insane hours (for free)" "Drop features X Y and Z" "Reduce / Skip testing"

In this case he has fixed the time line. He needs reminding that the things left to move are Resources, Quantity and Quality. As a project manager, he has the sole responsibility to what, where, by who. As the Engineer, you have the sole responsibility for doing what you said you will do in the time you said you will do it.

It's his deadline, not yours, don't buy his problem by accepting it. Make sure your concerns are well documented, in writing. If a decision is made over the phone, or in a meeting, follow it up with a written record. Every phone conversation should be recorded in you notes, with a summary send to everyone involved. Going over his head at an appropriate time, as last resort that will make enemies and win few friends, is an option to use carefully.

I agree with the with the excellent advise by @Kilian Foth - "get out"

Answer 6

Create costing documents.

These should detail each feature of what you are creating and the time involved each feature. It should not go over 5 days when discussing a section. If something does require more then 5 days, then break it down.

It needs to cover everything. Example:

Feature X 
Specification      - 1 day. 
Unit Test for API  - 1 day. 
Code              
   - X API1        - 2 days. 
   - X API2        - 2 days. 
   - X API3        - 2 days. 
Unit Test          - 1 day. 
Functional Testing - 1 day. 
Documentation      - 2 days.

... and so on. Don't be stingy on those times. People have an habit of underestimating.

Also factor in build times, backup times. Now this doesn't mean you are going to code like crazy for 6 days straight. Average over all. It should also detail what feature is waiting on what other feature, as well as what features can be dropped and still maintain a valid product.

You also need to set the realistic expectation of working hours.

Let's say you work 40 hours a week. That is 120 hours for 3 weeks (168 if you work weekends 8 hour days). You have costed 200 hours (40 * 5). This means you will be doing almost double the number of hours a week to keep to the schedule.

You then leave it on your project manager to drop features or get resources to make it within the available time. If the project manager ignores you, you can voice your concerns to a more senior manager.

You run the risk of burnout in your team, due to lack of control over what you are working on along with the hours expected to work. This can have a detrimental impact on the project.

Answer 7

Any negotiation will decay if you get into a yes/no frame. Too short/not too short is one of those cases. Any time you have a case where only one party can get what they want and the other party will sacrifice something major, you'll find the other party fighting hard. The goal is generally to move the discussion to a frame of reference where you can come to an agreement that lets both sides get something important and give up something that is minor compared to what you get.

Research

First, it always helps to know as much as possible when starting a negotiation. Questions for a schedule negotiation that I'd want to have in hand before returning to the negotiating table are -

Critical Path and/or Must Do Features

What's your critical path and what is the time burden of must do features that aren't on the critical path?

Chances are, you've sat down with the team already and figured this out. Always there is some set of tasks out there that simply cannot be done in parallel - you need the finished product to be able to do the next step and parts of that finished product have some unchangeable qualities. In particular, note things like:

• What are the must-have's are for completing critical steps?
• Any externally mandated wait points with estimates based on previous experience
• Ideas for where you can nestle other must-have items in the plan
• Areas of high risk to cost or schedule

Having this list written out moves you out of a can/can't discussion pretty quickly. It will also point out whether "having everyone work overtime" is even a viable solution. There's always the "9 women cannot birth a baby in 1 month" argument, but you can't say that until you really know what the path looks like.

Why the deadline?

Deadlines can happen for all sorts of reasons and only one of them is "because our project manager is out of his mind". Frequently that's the first impression I have.. but in reality, the overarching business drivers can be anything from a very finite mandate from a high priority customer to a general sense that if you don't get into the market with a certain feature, the value of product will collapse.

Get the scoop, preferably from more than one person. The manager you're arguing with is a key person, but also if there are others on the business end that can give a different persepctive, - get as much insight as possible.

A corallary here is "what REALLY needs to be done?" - it's not unusual for there to be serious disconnect between the "easy" feature the PM sees, and the "way hard" feature the technical team sees. What is really needed here and how simple can you make it?

What are the individual benefits to accomplishing the impossible?

Like the need for the deadline, every company will address this differently... but it could be anything, including:

• Covered by overtime pay
• Incentivized in yearly bonuses
• Something you can be fired for if you don't do
• A case where the business is in enough trouble that it's make or break for the company as a whole.

Is the team up for a push?

If this is a common issue, and you constantly operate in overload, then the answer may be "No", but if not, chances are, you have some team members more willing to take on the impossible than others... it's worth having a conversation on it, at the very least. It is probably best 1-on-1 between the people on the team and their manager.

Negotiation

Once you've got the information, you're in a better position to discuss the problem. Assuming the deadline is there for a reason, talk through the following with the manager responsible for the deadline:

• Limited scope - can you slim the work down to something you CAN achieve in 3 weeks?
• Added assistance for external delays - anything not linked to the team's work - can it be accelerated? A 2 week lag on a 3 week project because of external wait times is unacceptable, what can the management do to accelerate it or give relief if the delay happens
• Other aspects of potential schedule risk
• Ways to pay in cost to make up for pressure in schedule - temporary employees, overtime bonuses, other perks.
• Post-project recovery - pressure for 3 weeks isn't crazy if you know you have slack after that to recoup. This is both personal time (a day off with family), and work space cleanup time - chances are that other work slacked while you were meeting the deadline - what are the options to go back and cleanup when you've met the deadline?

Overtime

Overtime is a tricky one. In most professional, salaried environments I've seen, occasional overtime is an expectation. How occasional and how much overtime can vary wildly, but it is a common thing in many work spaces and the ways the expectation is raised and how strongly the requirement is worded will vary quite a bit from company to company and even boss to boss.

So - there's no easy answer here.

Your best bet is to know:

• the standards for your local industry and profession
• your own level of willingness at this time, and in this company
• whether or not overtime will help in a given situation

In the end, if you are working way more hours than is standard for your location/industry/profession - you may want to consider other employment options. Particularly if this is a big deal for your personal/family life. A single case of overtime is probably not a big reason to quit, but an ongoing pattern may be. It will have to be your call - it's a very personal choice.

Answer 8

Like others have said, make sure there is written record stating that your team disagrees and reasons why you disagree with the deadline. One way is sending email with detailed explanation on why the deadline is impossible and what is a realistic deadline. You can also suggest cutting out features to meet the deadline requested. In the cc-field of the email include Project Manager's supervisor and/or project stakeholder.

This can be seen as breaking the "chain of command", but escalation is important when nothing else works. You are also doing a favor for the PM because he is potentially harming his own career by not doing his job properly. By escalating you are also trying to prevent him from failing.

If higher managers and stakeholders give you bad rap for escalating, then it's and indication of bigger problems in your organization. Then you might consider leaving, like Martin Fowler has said "If you can't change your organization, change your organization!"

I also suggest reading Robert C. Martin's Clean Coder which deals with this problem among other aspects of professionalism.

Answer 9

Your project manager has made an unreasonable demand. Moreover, if you protest, you could end up on the manager's "bad list".

One reason project managers do this is that they have the misguided belief that project goals should be "aspirational" instead of actual; i.e. They will add in stuff to ensure that developers are 100% utilized. For them, if you are less than 100% utilized, you are wasting their money. They also believe that 100% developer utilization, and delivery with work-in-progress is more efficient than 100% delivery on time, less than 100% developer utilization, and no work in progress. In fact, the reverse is true. When you have too many aspirational goals, you end up with a lot of unfinished work-in-progress when you deliver, and that is almost always wasted effort. It is actually more efficient overall to deliver a project with developers utilized less than 100%, but with no work-in-progress at delivery time.

One way to approach your problem is to use Agile sprints. Scope out a sprint which you and your team believe will deliver in 3 weeks, and a second sprint which delivers in 2 weeks. Put the high-priority features in the first sprint as much as possible. Adjust the numbers downward on the "official" plan to reflect 3 weeks for both sprints (i.e. 9/5 weeks for the first sprint, and 6/5 week for the second one). This is a devious move, I'll admit, but it will buy you time to deliver value and look for another job.

Deliver the reduced scope first sprint in 3 weeks. Once you have delivered something, you have the power. Why? Because the project manager has to tacitly admit that your estimate was more competent. And if his superiors complain, he can point out that 3/5 of the functionality was completely delivered, and that is a whole lot better than 100% of the functionality in progress and undelivered.

And while you're delivering your first sprint, polish your resume and send it out. You could get fired over this. Keep in mind that if you commit to 3 weeks and deliver nothing but useless works-in-progress, you could get fired over that too.