There are five ways to handle this:
- expand capacity
- go down valiantly
- drop quality
As you are already behind the ball, you have no time to invest into increasing your overall capacity. But if you did:
- Expanding the team requires sacrificing one or more active developers to teaching and training. There is also an upper-bound on team size before this will start slowing overall development even once the new developers are up and running.
- Reducing red tape/removing limitations requires assigning one or more team members who understand what the red-tape is meant to do, and how it is not working, to remove or rework the red tape that is offering no benefits.
- Automating repetitive work loads. XKCD nails this, there is a trade off in how much time investing in this will pay off. As you are already close the payoff period is small, and as such probably not worth while automating.
Doing this can be beneficial, but they have their biggest pay off if done early, and consistently overtime.
Go back to the customer and be honest. We are not going to deliver this on time. Lets negotiate.
Yes there are penalties, they are going to be invoked. The earlier you acknowledge that this will be happening the smaller the fallout will be.
- The project might be written off and cancelled. A bad day but now you have two months to do something useful with that would have gone down the gurgler.
- You might negotiate a reduce scope to be delivered, with follow up deliveries. At least now you know what your customer finds important, schedule it and get it done. Then cleanup the mess and deliver the next feature set.
- You might negotiate a reduction in scope. Similar to before but you won't have to clean up.
- You might be given more time. Use it wisely.
Whatever the outcome, your reputation will include that fact that you pro-actively manage project failure early. Many business will see that as a sign of maturity.
If you choose to resign, the project will be further jeopardised, and quite likely you will:
- not get a good recommendation,
- do serious harm to your professional relationships, and
- possibly be responsible for some of the contract damages.
- you probably were not going to get a good recommendation anyway as you were not performing as a superhuman,
- if you think your professional relationships aren't going to take a battering by delivering hot, burning, rubbish software - think again.
- not to mention that if this is do or break, you will likely go unpaid for time worked anyway.
So it comes down to whether or not you think somewhere else is better. It probably is at this point. But sometimes we do not even get this choice.
Go down with the ship.
- On the pro side, you get to keep your morals and dignity.
- On the cons side you are not going to make that deadline.
What you need to do:
- Be loud, be direct, be professional.
- Keep explicitly spelling out that you will not deliver on the deadline and project the current best guess with uncertainty. eg: 6 to 10 months if everything goes to plan. 8-20 months if more than x issues occur.
- Make sure you keep a printed and witnessed copy of every communication you circle around about the project.
- Do not agree, or ratify any schedule given to you, that is not commensurate with your sanely projected schedule. eg: can you demo monday? No, we are at least two months away from something that can be demo'ed. But your schedule says 3 weeks.. at the earliest, more likely to be two months.
- Read up on your company policies, particularly around your rights, and how to escalate issues that affect the business reputation. Follow those processes.
You will be put under enormous pressure. You may lose your job, bonuses, special parking spot. You will likely be paraded before and used as a scape goat.
You may become subject to law suite. This is why you have kept your communications to prove that you followed due diligence.
It will pay to get training in how to consider, and then express your argument to a hostile audience. Things like public speaking, debate, assertiveness training will be helpful.
This is the vilest answer, but if you are stuck between two unrelenting businesses that will not negotiate on time, or features... and you cannot quit for whatever reason, and for some reason you cannot take the moral high ground of going down with your ship.
I personally do not condone sacrificing quality. I point this out to outline why this solution, is NOT A SOLUTION.
The problem is that the two parties are at war, and you are stuck in between them, which will inevitably lead to destruction around you. There are those whom intentionally or not will choose this action out of spite, pragmatism, or some other justification. It is certainly something to be aware and wary of in both yourself and in others.
Should this option be the one that is taken:
Please, place your dignity and morals in the bin - you cannot afford them. Welcome to a hell that you are personally tailoring for yourself.
You have a deadline, and a set of sentences that describe the end state of the system. Your role is to play the Genie of the lamp, you have been given an unreasonable request, your goal is to solve it with the least amount of effort, consideration, or thought while meeting the letter of the request. Don't mind the spirit of the request - it has already proven it cannot change the terms of the contract and can be sent to the same bin as your morals and dignity.
- Find every corner and take it. If your choice is between spending half a day or a full day on a "feature" spend half a day. Even if that will exact punishment on the next set of developers.
- If there is a fluffy requirement find a blanket solution. eg: must be secure. Define this as uses SSL. Presume that the server box is secure. Thus you can store password credentials unencrypted. etc...
- If there is a requirement that can be read two ways. Interpret it in the way that reduces implementation time. And rephrase the requirement in a stakeholder document that gets signed.
- If at all possible satisfy a requirement by doing nothing. A paragraph explaining how this is provided by someone/something else is 100x faster than actually implementing it.
- Don't bother with good engineering. Think novice programmer: code directly in the UI, spaghetti is king, always write more, never reuse.
- If you have satisfied all requirements, every remaining moment is your bonus.
As an experienced engineer you will be capable of guessing which parts of the code will bite you early. These are the only pieces of code you should care about enough to do well.
But seriously don't let yourself ever be placed into this position. Push for one of the other solutions, even quitting is better. At least it sends the message clearly to both sides that this is not on.
Make your choice.