Iyfjky

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?

Projects miss deadlines all the time and it rarely results in the death of the project. Can the scope or features be adjusted such that you have something usable in 3 weeks and then the team can follow up with corrections as needed? — Mar 21 '13 at 14:18
If he keeps pushing, you can to mention that, as a good project manager he should know about the project contraints model, and in order to keep the deadline would have to either pay your extra hours, or reduce the scope by dropping features. However people do not really like to be lectured, especially when they are your manager... — Mar 21 '13 at 20:38
For some related reading,this book has some great case studies. amazon.com/Power-Positive-No-Relationship-Still/dp/0553384260/â€¦ — Mar 21 '13 at 21:50
5/3 weeks is approx 166% effort, calculate to approx 13 hour working day. Every day. For next 3 weeks. It is not bearable. — Mar 22 '13 at 11:56
Note that this might also be a cultural thing. The response expected from programmers and supervisors may be highly dependent on where in the world this is. — Mar 31 '13 at 16:32

Kilian Foth 1,643198 · Accepted Answer · 2013-03-21 07:23:27Z

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.

+1 for "Imposing deadlines without consulting the implementers and then rejecting their feedback is sign of a toxic work environment." — Mar 21 '13 at 8:35
+1 for "The only thing you should never do is to accept conditions that you know will only be used against you afterwards" Indeed, in a toxic environment, if you don't refuse this is seen as an agreement, and next 'you did not keep your part of the agreement'. — Mar 21 '13 at 10:35
"The only thing you should never do is to accept conditions that you know will only be used against you afterwards." It is generally good advice not to accept a deadline you know you will miss, but sometimes it goes against the grain. In some environments in which arbitrarily chosen deadlines are routinely missed, pushing back against the deadline can sometimes cause more political damage than accepting and missing the deadline, even when you know the deadline is wrong. But, the right thing to do is to push back with explanation and backing data. — Mar 21 '13 at 21:34
This has way too many assumptions. There are plenty of times when a single project has this sort of pressure. Telling someone to quit when you have one data point out of the entire company is absolutely an overreaction. The whole first paragraph may not even apply to this situation at all and is not at all a constructive element to a meaningful answer to this question. — Mar 21 '13 at 21:54
@enderland Passing responsibility for your or management's mistakes down the line without any modification to the plan or compensation for the extra work required is a prime example of a toxic environment for the people the buck is getting passed to in my book. I've worked in environments like that. We regularly ran out of graphic designers but turnover wasn't nearly as high for management and PMs oddly enough. — Mar 22 '13 at 1:36

score 35 · Answer 2 · 2014-01-01 15:06:27Z

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.

Note that a lot of companies have in the contract that you don't get paid overtime (either at all, or beyond a certain seniority level). Granted, the correct response is to negotiate what you'll get instead (e.g. flexitime), but it's as well to be aware. — Mar 22 '13 at 9:10
In some situations, the alternative to paid overtime is hiring/bringing in staff from other projects, so long as you can avoid Brooks's Law - i.e. depends on the work. — Mar 27 '13 at 12:20
The "work more" does only work for being a little short on time. Any more than just a little short cannot be fixed like this. — Feb 18 '14 at 13:02

HLGEM 133k25226489 · Answer 3 · 2013-03-21 13:47:01Z

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

I've seen that link before, but it really needs to be plastered everywhere. — Apr 6 '15 at 22:13

Elysian Fieldsâ™¦ 96.9k46292449 · Answer 4 · 2013-03-23 14:01:13Z

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.

mattnz 60137 · Answer 5 · 2013-03-21 07:38:53Z

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"

please don't offer to skip testing, you are only going to make a bad situation worse going that route — jk., Mar 21 '13 at 7:45
Skip tests, Meet deadline, Maybe Get on-time performance bonus, quit leaving useless PM in the lurch. Wheres the down side for the OP? What other options has He got? If the OP does not look after #1, no one else will, certainly not his PM..... (Joking... I think) — mattnz, Mar 21 '13 at 7:57
@jk. You must not force it, but this will be the first thing, management will do, when they see the deadline will not hold. Nice side-effect: it reduces bugs ;-) — Andy, Mar 21 '13 at 8:55
if he skips testing, the product gets shipped untested and buggy, and HE will get blamed for it, not the guy that set the deadline that made testing impossible. Same if he leaves out features, HE will take the blame for releasing an incomplete product (or more properly, forcing that release by not meeting the deadline). — Mar 21 '13 at 12:50

Simon O'Doherty 4,85111435 · Answer 6 · 2013-03-21 14:29:14Z

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.

ANd you never cost againast more than an 6 hour day because you have to account for breaks, company meetings, days off (including unplanned ones like bereavement or sick leave), nonproject work (like fixing a production problem on from some live project), etc. — Mar 21 '13 at 18:35

bethlakshmi 70.3k4136277 · Answer 7 · 2013-04-02 15:36:28Z

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.

simoraman 1413 · Answer 8 · 2013-03-21 10:30:19Z

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.

written records rarely help. I've been in such situations and the only thing that helps is having a few good friends in high places (meaning higher than the friends the person who did this "planning" has them) so you can trump them during the inevitable blame game. Which is where things get very very ugly. — Mar 21 '13 at 12:52

Jay Godse 1,290710 · Answer 9 · 2015-04-06 16:53:27Z

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.

Kilian Foth 1,643198 · Accepted Answer · 2013-03-21 07:23:27Z

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.

+1 for "Imposing deadlines without consulting the implementers and then rejecting their feedback is sign of a toxic work environment." — Mar 21 '13 at 8:35
+1 for "The only thing you should never do is to accept conditions that you know will only be used against you afterwards" Indeed, in a toxic environment, if you don't refuse this is seen as an agreement, and next 'you did not keep your part of the agreement'. — Mar 21 '13 at 10:35
"The only thing you should never do is to accept conditions that you know will only be used against you afterwards." It is generally good advice not to accept a deadline you know you will miss, but sometimes it goes against the grain. In some environments in which arbitrarily chosen deadlines are routinely missed, pushing back against the deadline can sometimes cause more political damage than accepting and missing the deadline, even when you know the deadline is wrong. But, the right thing to do is to push back with explanation and backing data. — Mar 21 '13 at 21:34
This has way too many assumptions. There are plenty of times when a single project has this sort of pressure. Telling someone to quit when you have one data point out of the entire company is absolutely an overreaction. The whole first paragraph may not even apply to this situation at all and is not at all a constructive element to a meaningful answer to this question. — Mar 21 '13 at 21:54
@enderland Passing responsibility for your or management's mistakes down the line without any modification to the plan or compensation for the extra work required is a prime example of a toxic environment for the people the buck is getting passed to in my book. I've worked in environments like that. We regularly ran out of graphic designers but turnover wasn't nearly as high for management and PMs oddly enough. — Mar 22 '13 at 1:36

score 35 · Answer 11 · 2014-01-01 15:06:27Z

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.

Note that a lot of companies have in the contract that you don't get paid overtime (either at all, or beyond a certain seniority level). Granted, the correct response is to negotiate what you'll get instead (e.g. flexitime), but it's as well to be aware. — Mar 22 '13 at 9:10
In some situations, the alternative to paid overtime is hiring/bringing in staff from other projects, so long as you can avoid Brooks's Law - i.e. depends on the work. — Mar 27 '13 at 12:20
The "work more" does only work for being a little short on time. Any more than just a little short cannot be fixed like this. — Feb 18 '14 at 13:02

HLGEM 133k25226489 · Answer 12 · 2013-03-21 13:47:01Z

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

I've seen that link before, but it really needs to be plastered everywhere. — Apr 6 '15 at 22:13

Elysian Fieldsâ™¦ 96.9k46292449 · Answer 13 · 2013-03-23 14:01:13Z

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.

mattnz 60137 · Answer 14 · 2013-03-21 07:38:53Z

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"

please don't offer to skip testing, you are only going to make a bad situation worse going that route — jk., Mar 21 '13 at 7:45
Skip tests, Meet deadline, Maybe Get on-time performance bonus, quit leaving useless PM in the lurch. Wheres the down side for the OP? What other options has He got? If the OP does not look after #1, no one else will, certainly not his PM..... (Joking... I think) — mattnz, Mar 21 '13 at 7:57
@jk. You must not force it, but this will be the first thing, management will do, when they see the deadline will not hold. Nice side-effect: it reduces bugs ;-) — Andy, Mar 21 '13 at 8:55
if he skips testing, the product gets shipped untested and buggy, and HE will get blamed for it, not the guy that set the deadline that made testing impossible. Same if he leaves out features, HE will take the blame for releasing an incomplete product (or more properly, forcing that release by not meeting the deadline). — Mar 21 '13 at 12:50

Simon O'Doherty 4,85111435 · Answer 15 · 2013-03-21 14:29:14Z

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.

ANd you never cost againast more than an 6 hour day because you have to account for breaks, company meetings, days off (including unplanned ones like bereavement or sick leave), nonproject work (like fixing a production problem on from some live project), etc. — Mar 21 '13 at 18:35

bethlakshmi 70.3k4136277 · Answer 16 · 2013-04-02 15:36:28Z

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.

simoraman 1413 · Answer 17 · 2013-03-21 10:30:19Z

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.

written records rarely help. I've been in such situations and the only thing that helps is having a few good friends in high places (meaning higher than the friends the person who did this "planning" has them) so you can trump them during the inevitable blame game. Which is where things get very very ugly. — Mar 21 '13 at 12:52

Jay Godse 1,290710 · Answer 18 · 2015-04-06 16:53:27Z

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.

Search This Blog

Iyfjky

How can we protest a deadline that is too short?

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

9 Answers
9

Research

Negotiation

Overtime

protected by jmort253â™¦ Mar 22 '13 at 4:37

9 Answers
9

9 Answers
9

Research

Negotiation

Overtime

Research

Negotiation

Overtime

Research

Negotiation

Overtime

Research

Negotiation

Overtime

protected by jmort253â™¦ Mar 22 '13 at 4:37

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

One-line joke

Category

Random preview

How can we protest a deadline that is too short?

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

migrated from programmers.stackexchange.com Mar 21 '13 at 12:02

9 Answers 9

Research

Negotiation

Overtime

protected by jmort253â™¦ Mar 22 '13 at 4:37

9 Answers 9

9 Answers 9

Research

Negotiation

Overtime

Research

Negotiation

Overtime

Research

Negotiation

Overtime

Research

Negotiation

Overtime

protected by jmort253â™¦ Mar 22 '13 at 4:37

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

One-line joke

9 Answers
9

9 Answers
9

9 Answers
9