Dealing with unrealistic deadlines [duplicate]

Question

I'm seeking advice on how to deal with unrealistic deadlines at work. The issue is that the company I'm working for is making a huge pivot, however there is an expectation that the pivot will occur quite rapidly and that the previous technology solutions will be sufficient to make this a smooth transition.

To the contrary, I have discovered recently that the real amount of time to implement the new product is going to take a few more months than planned, mostly because new technology will have to be used, and a large amount of refactors are required. So far, the management team hasn't been quite receptive to this news, and are hoping I actually drop the much needed refactors.

I'm looking for advice on how to handle these kind of unrealistic expectations and how to move forward. I really like the company, but I think that there is a lot of stress here since the company is losing a lot of users daily.

Answer 1

If there is an unrealistic deadline, one of the following has to happen:

1. a. Extend the deadline / b. deliver past the deadline.
2. Drop features.
3. Drop quality (expect the odd crash or data loss here and there).
4. Bring in someone highly qualified who can contribute significantly to the work, that is expensive.
5. Work ridiculous hours and make yourself ill as the result, with dubious results.

What doesn't work, but what your management seems to do, is

6. Close your eyes and ears to anyone who tells you the deadline is at risk.

Number 5 has the disadvantage of making you ill, without any advantages for you (company isn't going to pay overtime, or going to thank you, but realise that you can be taken advantage of), and it doesn't help much anyway, so that is the option that you must avoid and refuse at any cost.

I'd suggest to create a list of features that could be dropped while still having a useful product, and a list of points where quality can be dropped, including the obvious consequences. Your management then needs to decide what to do. If necessary make them aware that option 6 doesn't work (tread carefully there), and that option 1b. will happen automatically.

What you need to emphasize is that without action, the deadline will not be met.

Answer 2

Firstly - accept that if this really is the case, it's not okay. Too many programmers take home work with them and stay silent on these issues leaving management in the dark (even if they appear to not be).

You also never want to present a problem without some sort of reasoning or a solution. To do this - communication is key. Not just telling your manager that you're not going to be able to reach a deadline but refining how you communicate it.

If I were in your position I would break down the work into items and put timing, and deadlines around each of them. You can then use this to communicate exactly why the deadline isn't achievable, with hard data that the business can feel comfortable making a decision upon. If you're comfortable doing so (depending on your level and the team) you could even suggest some compromises that could be made (with changes or your own schedule) to help get the project back on track.

Should this not work I often continue to update a worksheet as the project commences sending a weekly (or if necessary daily) summary of the work items that have been completed, any blockers to getting work done and the forecasted schedule.

Answer 3

First of all, it sounds like your company is abusing concept of deadlines and estimations - estimations are estimations and that is all they are. Nobody, ever should expect for a estimation to fit in a deadline exactly and deadline should have a very reasonable safety buffer over estimation for exactly these situations. Delivering sooner is okay, delivering past the deadline is not.

Amending to the previous answers, and based on my previous experience this might as well be a communication issue for one simple reason - people in management often lack technical skills and understanding, and simply put, they are underestimating the importance of software quality which is a real need in this case apparently, as you stated that a lot of refactoring will be needed. Based on that, you should probably present management with the fact that doing it later will cost more, as technical debt only increases and the problem that already exists will not simply go away if postponed - it will increase in severity as you add more and more complexity to the project, and that increase will be exponential to the point where maintaining the project will suck up huge amount of resources. I don't think a wise management will pass on this if it is absolutely certain they will loose money if this continues in a way that it does.

If this is a inside product, argument that we should actually produce something that works well instead of a half baked cake should pass with flying colors.

If this is a product for some external customer, even more - people usually are reasonable enough to accept extending deadlines if that means the end result will improve by order of magnitude.

Last, but not least, you should figure out why this gross underestimation happened in the first place and place a mechanism from preventing it from happening in the future - were the tech people not involved in estimations? Was something important excluded from the estimations, and if so, why? And if so, why was not the deadline extended after it was proven to be unrealistic?

Answer 4

Sorry, but I think you're approaching the problem from too much of an engineering standpoint. It's easy to just accuse management of not being reasonable especially if they're not technically savvy, but you are losing clients. That is a reality.

Like all emergency situations (severe loss and damage with little time and resources), you have to triage. In your case, it has to happen on both the Refactoring and the Feature/Requirements areas. Get those two in synch if possible. If feature A will help retain the most clients, refactor that part of the code base if necessary. At least limit the refactoring in areas with the least interest to your clients. I realize you may be refactoring generalized areas, utilities or frameworks.

I'm skeptical about this large makeover at a time when clients are not satisfied with your application. Fix what you have to solve their problems. If you can get me across the river, I don't need a new bridge.