I have gone to a few interviews at project-based companies for software developer positions. One common question they tend to ask, which is also the hardest to answer, is:
Given a scenario where you have a project on hand, and the deadline given is in X days, and you know that no matter how hardworking you are trying to pull up all nighters everyday, you will never meet the deadline. And the client mentioned that it is a hard deadline.
What answer should I give? What do they expect to hear?
What answer should I give?
This answer is for a software developer role (no direct reports):
The simple answer here is the truth. And in this specific instance if you know the deadline isn't going to be met, delivering the truth sooner rather than later is best.
Basically they want to know you are not going to hide the fact that you aren't going to make your deadline and aren't afraid to ask for help.
You will never get a job like that by repeating an answer you were given on a site like this. You need to learn how to answer that question in your words using your experience and examples that you have actually been part of. That said, you can find a better answer to give them next time. They key is to understand why they are asking. They believe they know what to do and not to do in that situation, and they want to see if you do too.
A good answer will contain two things. First, you should easily be able to list your options: telling the client the deadline will not be met, dropping some part of the work, those sorts of things. And this list should not include things that won't work, like adding people to the project. Second, you should be able to explain how you would choose among those options and how you would communicate in the situation. If you just say "I would X" without any explanations of why X instead of Y, it's not a good answer.
If you're applying for a project management position, they will expect somewhat different options and thought processes than if you're applying as a developer working without the support of PM, but the basic "I would have a choice of X or Y, I wouldn't consider A or B, and I would choose X or Y based on Z" will still be there.
If you don't have a good answer for this and have been asked it more than once, get yourself a good answer. Surely you have faced this? Even if you saw someone else handle it rather than handling it yourself? What worked, what didn't, what have you done in that situation before? Get better at telling that story.
This is also an opportunity, after answering the question, to talk about how important it is not to get into that situation, and what you do to prevent it. This might be regular status meetings, frequent releases, resisting scope creep, monitoring progress, or any number of other techniques you have learned in your job. The interviewer wants to know what you know how to do.
As a software developer, it's not my job to discuss that sort of problem with the client, and as a software developer there's nothing that I can do personally to fix the problem.
So the only sensible course of action is to contact the program manager as soon as possible to make them aware that there is a problem, and discuss with them what can be done to bring the project back on track.
The answer may be to assign more people to the job, to negotiate a later deadline with the customer, or several other options. But the decision isn't mine to take.
Or what do they expect to hear?
They are looking to see how you think through and process this sort of question.
They don't want to see you try to tell them what you think they want to hear. They don't want to hear a canned answer.
It's hard, but try not to guess what they want to hear. Instead, listen to the question, think it through, and answer honestly. Try to put yourself into the posed situation, and tell them how you would react.
And if you have actually encountered the situation, make sure you indicate that you have, what you did, and if you would do the same thing again.
Funny that this was one of the questions, my answer to which (I think) gave me one of my previous jobs. It was not a good job, because such situations were common there. But it was relevant for that job (and should give me a hint not to take it).
I mentioned what we did on one of the projects I participated:
We were in an impossible situation: in a small company, we needed the contract to keep us alive for next few months. It was extension of our (accounting) system which we wanted to implement, but deadline to complete it was impossible. So we started implementing it anyway, with our best guesses how to do it, and published a big document with many questions asking how exactly they want the new functionality to be implemented. And we told them that it would take X months after we will receive the final answers.
Guess what: it took them months to agree between themselves what exactly they want, while we were implementing out best guess. We got the contract, got some milestone payments from the customer. In most cases we guessed right, few cases we had to redesign, few features were postponed to phase two, but company survived to fight another day.
I am not sure if you can just fake such answer (because this is a true war story, any follow-up question might disclose you as a fake if you did not lived through it).
In live-or-die situation, you are forced to take chances with hopes that you will have luck, because if not, company will die anyway. Nobody writes about the hundreds startups which failed, only the successful are mentioned. See survivorship bias - you assume you will survive.
According to Team Software Process (by Carnegie Mellon University), you need to communicate with the Stakeholders as soon as the team knows that the deadline cannot be met. This allows all interested parties to either replan, remove features or do something to resolve the issue (of not meeting the deadline).
According to the Mythical Man Month, by Fredrick Brooks Jr., adding more people to a project will not shorten the schedule.
In terms of project management, there is the triangle with sides of scope, time and budget. If one of the sides changes (in length), the other two must also change.
So, to answer the interviewer's question:
The information from #1, #2 and #3 should come from the team members (doing the work). They are closest to the project and can give information with the highest degree of certainty.
IMHO, only plan overtime sessions if the completion time is small. There is no guarantee that overtime will improve the quality of the product; sometimes overtime can introduce more issues and extend the schedule.
At one shop I worked at, requirements were removed from the project in order to reduce the schedule.
This would be my answer, if my role was a Project Manager:
If I don't think we can meet a deadline, the first thing I need to establish is what it would take in terms of manpower and other resources in order to meet the target.
Then I should go to my management, and together we can perform an assessment if spending the additional resources is worthwhile in order to get the project completed.
If management pushes against additional resources, I would go to the client and explain the situation, and recommend a reduction in scope of the work, until such a point as the work becomes feasible in the timeframe. I would work with the client to prioritise the work in order to ensure client impact is minimised.
If the client refuses to reduce the scope or discuss work priority, I would analyse the requirements carefully to see what is the set of deliverables that limits the damage to the reputation of the my company, and in addition, any financial penalties that would apply. I would make it very clear to the client what will be delivered in that timeframe, in order to mitigate the client impact.
I would imagine in some situations, clients may be more receptive to renegotiation when they realise that they will not get everything they want, and they want to have better control over what they do get. They may also be willing to push back the "hard" deadline.
Obviously, it's regrettable that any project would get to a point where there is a major surprise towards the end. Ideally we would be tracking progress, and that would allow us to modify the scope of the work in a gradual manner to ensure the most important requirements are met.
I've got a question along these lines before, so it's not that uncommon. In my opinion the only correct answer is along these lines:
Somebody screwed up somewhere to get here at all, now we'll make the best of it by organizing an emergency meeting and see what is possible instead of what isn't.
Knowing you're going to fail and doing it anyway would be the wrong answer. If it can't be done, it can't be done. Yet you will often encounter situations that look like they're asking you to do the impossible.
The absolute key here is to find what is possible and work from there. This is not a question about hard software engineering. This is a question about managing expectations, dealing with the unexpected and keeping a project together.
It also means they're looking for more than someone who just writes code. They're looking for someone with a whiff of managerial capabilities or are at least finding out if you got those. Because no matter what answer you give them, how you give them the answer will tell them a lot about how you think about projects.
A possible follow-up might be (either as a question from them or as an answer from you if they expect long answers) how to handle the fallout and reducing the chance of it happening again.
So there's a deadline, and it is impossible to meet. Whatever you answer, whatever you do, one thing that won't happen is you meeting the deadline. Here's what you and your manager can do:
Tell your manager as soon as possible to give them a chance minimising the damage. Missing a deadline with $10,000 financial damage is an awful lot better than missing a deadline with $100,000 financial damage.
Don't panic, calm down, and calm everyone else down. Seriously. I have seen grown ups flapping around like headless chickens in those situations. I've done the same once when I was a lot younger and learned from that. Now I know that instead of flapping around and not getting anything done, you change the problem in your mind from the unsolvable "How do I meet a deadline that is impossible to meet" to "How do I minimise the damage".
The method that doesn't work is trying to rush, or trying to add more people. What does help is getting people to do secondary things. For example if you are supposed to write code and try it out, you write the code and someone else tries it out. Another method that your manager can use is improve your ability to work more hours. There's a nice hotel 100m from my workplace. I can do more hours if my boss pays for me to stay at that hotel, and orders healthy food to arrive at lunchtime, and more healthy food to arrive at 5pm. On one occasion, someone had to be at my home to get a furniture delivery. My bosses wife did that. She wasn't happy, but my boss needed me to work. That kind of thing is also quite motivating.
There are two obvious methods to get finished earlier: Reduce quality, and reduce features. That needs to be discussed.
There is an obvious method to meet a deadline that people often forget (because see point 2): Move the deadline. Very few deadlines are unmovable. See Peter M.'s ingenious method. Congratulations if you can pull that off. Easier is often to just negotiate. That's likely done one or two levels above you. But if you make it clear to the customer that there's no chance he's getting the promised thing at the promised time, they have the choice of extending the deadline or not getting anything.
I hope it doesn't come to this, but the first rat to jump off a sinking ship has the best chances to survive.
Between a rock and a hard place? Get on the other side of the rock. Offer the client a demo of partial functionality in 1/2 the time to their deadline. You will catch them off guard, and pull them into the conversation. Bringing them in weekly to discuss what functionality has been increased that week, you will quickly learn that their requirements were not 100% of what they needed, and by the time that deadline rolls around you may well have "something" that they can use, even if its 80% functional, you are way ahead of your waterfall competition.
I feel some of the others are constructing too weak a version of "hard deadline".
I have never been a PM but on more than one occasion I've had to tell the truth to the CEO when everybody else, including the PM who should have known, was silent. We have certain legal requirements, and when the requirements of the law change, we must change our code to match, and the deadlines are set by the government. The truth was "That day is already gone."
I had been there a long time. I knew how long it would take from internal engineering release to production. I had just looked at the test logs and knew how long the testing would take. I had a really good estimate for number of items sent back to failed testing, used a low figure for turnaround time, and a really good figure for retesting time. I added up the numbers and it said we had -1 days to continue development. I don't remember how the explanation of all this went (which did happen immediately), but I just remember my opening statement.
Due to source control limitations that management didn't care about before, we could not decide to drop completed features to relieve testing time so these things could not be improved upon.
Unfortunately I couldn't tell them how many days they could realistically expect, so they didn't accept my answer. But at the internal demo of the regulatory required features the next week management asked for sweeping changes to them. Go figure.
We ended up delivering a month and a half late.
Taking everything said at face value, the best option is to consider any more work on this project as a waste of time and instead skip to the next project. Which is not the decision of a software developer to make.
This does not happen in real life. I've been in situations such as this and the solution basically was to give the customer what they wanted to see. Which changed from unreadable data (not quite the right format but not intentionally so) to fake data (generated or test data passing the writing routines) to stuff prepared with manual intervention to hand-selected working examples to the real thing.
This may involve working with the actually contracting company in order to convinve downstream recipients to also play the waiting game: stuff needs to look as if there is so little missing that it would make little sense to abort.
I've taken subcontracts from incompetent contractors with good business relations and paying well where the main priority was to always keep your ass covered, calculate deadlines safely and produce working and well-documented material that you got them to sign off on every time since the governing project was most definitely headed for a crash landing and you did not want to be the scapegoat under the collapsing landing gear.
This garbage fire was cancelled about two years after the "hard" deadline, long after I've delivered and collected. This is the reason that the right response to sure-fire failure of a hard deadline rarely is to give up: some deadlines may trigger penalties one wants to avoid. But the deadlines killing a running project for good are rare and the final decision may very well fall at a time you are not aware of.
