9

This question already has an answer here:

How do I handle the situation where the non-technical project manager never agreed to our estimated time line and as per him it should be half or even less than what we had estimated?

According to him whether there is stored procedure of 100 lines or enablement of some security features for which we need to do RND it should be done on 1-2 hours only and he asks questions like "why does it take so much time, it should be done in 1-2 hours only".
He just goes on asking more and more questions and is never satisfied with the answer.

What should I say or how do I handle this situation?

marked as duplicate by gnat, keshlam, Jan Doggen, Telastyn, Monica Cellio Dec 21 '14 at 2:37

This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question.

  • 10
    Everything is easy to them that don't have to do it. Ask him to show you all how to get RND done in 1-2 hours. – Vietnhi Phuvan Dec 20 '14 at 10:37
  • My question is littlebit different than How can we protest a deadline that is... question because my PM is habitual to this, even if there is no pressure from client or upper management he always create his own pressure and that is his way of managing people i.e. always create pressure to get work done, so how to handle him – kulwal_amit Dec 20 '14 at 13:39
  • 2
    I think the same answers apply, though. If you think it will take longer, spell out why it will take longer. It's legitimate to say "My experience when I've done something similar in the past is that it takes longer" or "Here's what's involved and I just don't think that fits into two hours" or "I can implement it in two hours, but it'll take another three to test it". Or even "I don't think so, but I can try; let's review afterward and discuss what took how much time so we both learn to improve our estimates." – keshlam Dec 20 '14 at 14:08
  • How do your estimates and his estimates compare to the actual time things take? Make sure that you make estimates that match reality. If they match reality, then your manager is either very bad at estimating, or confuses unrealistic targets with estimates. – gnasher729 Dec 20 '14 at 16:16
9

This sounds like a PM that only has experience managing mediocre teams. You need to spell out to him, in business terms, why exactly he should stop this had behavior. It sounds like you're talking about software development, which is where I work, but these should apply generally also. Here is some ammo to take to that conversation (some may not apply to every situation):

  1. Explain what is complicated about the work. You said he's non-technical, but you need to be able to explain this in simple enough terms he can understand (at least so he gets the main idea). Explaining the complexity of work to be done is a basic development skill. I'm not saying you're not doing this, but if not then it's really you that's not doing their job correctly more so than the PM.
  2. Emphasize that you want to give accurate estimates. Suggest using a more scientific approach than either of you is currently using. Get some historical data and estimates and compare them. You may need to use a multiplicative factor to your own estimates (commonly inexperienced engineers actually underestimate by 50% for example), but they probably track the trends of the work to be done better than "everything takes 2 hours".
  3. Explain that you want to focus on producing high quality work. Sometimes that takes longer, but you believe that this allows you to produce better results. You'll need to be armed with examples of things that were done correctly and where the 2-hour solution would have created more work later, or visa versa.
  4. Explain that his "beating down" the estimates like this causes undue stress on the team, which will actually lower productivity. There is the immediate effect of people rushing and making silly mistakes, the mid-term effect of people loosing buy-in and not caring as much so they don't work hard, and the long-term effect of attrition (people quitting) severely impacting the team's performance. Clearly you don't want this to sound like a threat that you personally will leave... well, maybe you do but do so carefully.
  5. Explain that many teams are having higher orders of productivity by using processes that only allow the engineers to do the estimation. Agile software development (scrum) has this as one of it's foundations. Make it clear that if you go down that path, he's still free to question your estimates from a "why does this take so much longer" stance, but not a "this should only take X-long" stance. Really, Agile focuses on relative estimates and then the team establishes a track record and the data speaks for itself. Very similar to the scientific approach I mentioned in item 2.

If none of that work, you should discuss this with a people-manager. I've seen a wide variety in the skill of PM's (from glorified secretaries to people with decades of development and management experience who treat project management as a science). The people-manager should be able to help resolve this if you can't with the PM directly.

If you get no satisfaction from any of these routes, ultimately we're all self-employed and you can vote with the "rule of two feet" by finding another job. That's definitely the nuclear option and I'd exhaust all others first.

Hope this helps.

2

This may be just a comment, or may be something you can tell the manager:

For what it's worth, I have learned that my own initial estimates are always at least 50% overoptimistic, and experience has taught me that doubling them produces a much more accurate number. Also, anything that involves more than a day's work immediately starts to lose hours to other parts of business process, time lost to context switching, simply having to get state reloaded into my own memory overnight, intervening crash-priority items... so I have to increase that scaling factor somewhat as the scale of the task increases.

The number I give is my best guess after I have allowed for all of that. If it isn't the number you expected, one of us misunderstands the scope of the request. If you see a way to get it done faster, I'm all ears; I may have missed something obvious or there may be tools/techniques I'm not familiar with and would be delighted to learn about. Otherwise: I want you to have realistic numbers to work with and this is my best guess at the center of the bell curve; if I thought it was likely to be done sooner I'd have said so.

Not the answer you're looking for? Browse other questions tagged or ask your own question.