Inteview: What to do when you can't finish a project on time
Discussion
I have been asked quite a few times during an interview that "What would i do when i can't finish a project on time?"
I normally say that i will try to analyze that why is this happening and will let my manager know about the situation.
I don't know if this is a right answer.
Could you please share your experience.
I normally say that i will try to analyze that why is this happening and will let my manager know about the situation.
I don't know if this is a right answer.
Could you please share your experience.
Ooh, that's an interesting one - not something I've been asked as an interviewee - or thought to ask as an interviewer!
I think that probably one of the favourite answers has to be to 'get in touch with the client immediately to advise and dicuss.'
Looking back at my previous industry, where a lot of jobs were time-critical (financial printing) one thing that customers cannot stand is to be told that the job will be late, right at the 11th hour - especially without an alternative plan. They generally go bonkers.
Trouble is, human nature being what it is - no-one wants to deliver bad news, so often things just get left until the last minute, when it is then 100% bleeding obvious that the project will be late.
I've found that, as horrible as it is - it is ALWAYS best to realise as early as possible that the job might be late, then think about what the alternatives are, and call the client asap. Often, you don't get the rant / b
king that you expected anyway - and most of the time, they thank you for your honesty and for letting them know with some time in hand - and we've then been able to work out a solution. On some occasions, I've called to advise of a delay very early on when something has gone wrong at our factory - but then managed to work around it and deliver more or less on time in the end. The clients are always still extremely happy to have been involved in an early dialogue about possible delays, even when they've not come to fruition.
Communication is always the key to good client relationships!
I think that probably one of the favourite answers has to be to 'get in touch with the client immediately to advise and dicuss.'
Looking back at my previous industry, where a lot of jobs were time-critical (financial printing) one thing that customers cannot stand is to be told that the job will be late, right at the 11th hour - especially without an alternative plan. They generally go bonkers.
Trouble is, human nature being what it is - no-one wants to deliver bad news, so often things just get left until the last minute, when it is then 100% bleeding obvious that the project will be late.
I've found that, as horrible as it is - it is ALWAYS best to realise as early as possible that the job might be late, then think about what the alternatives are, and call the client asap. Often, you don't get the rant / b
king that you expected anyway - and most of the time, they thank you for your honesty and for letting them know with some time in hand - and we've then been able to work out a solution. On some occasions, I've called to advise of a delay very early on when something has gone wrong at our factory - but then managed to work around it and deliver more or less on time in the end. The clients are always still extremely happy to have been involved in an early dialogue about possible delays, even when they've not come to fruition.Communication is always the key to good client relationships!
I'd:
Inform all atakeholders immediaely.
Arrange metng to discuss options and priorities.
Reschedule the project with realistic timescales and detail _true_ hard points (many projects have false lots of deadlines, some are critical, and others are nice to haves).
Assign tasks / backup plans for the most critical bits.
Hire a villa in spain coinciding with deadlne week.
Turn phone off.
Deny it all when confronted.
Go work in smaccies.
Prefect plan
Inform all atakeholders immediaely.
Arrange metng to discuss options and priorities.
Reschedule the project with realistic timescales and detail _true_ hard points (many projects have false lots of deadlines, some are critical, and others are nice to haves).
Assign tasks / backup plans for the most critical bits.
Hire a villa in spain coinciding with deadlne week.
Turn phone off.
Deny it all when confronted.
Go work in smaccies.
Prefect plan
I was asked the same question in an interview recently. Scottri and Ray have already nailed the answers - time is fixed so you can only adjust quality or cost.
If you can't find a solution then communicate as early as possible.
I can add a little validation to the response as I was offered the role and although I declined the feedback from the interview was excellent
If you can't find a solution then communicate as early as possible.
I can add a little validation to the response as I was offered the role and although I declined the feedback from the interview was excellent
I´d hold off on telling the stakeholders. I would
- Try to re-work the plan and confirm that the plan cannot be met
- Provide options e.g. de-scope parts of the project to hit timeline, 3 week delay, weekend working which means $x impact
- Ensure that you understand why the project is running late (planning, new requirements, impact of external issue)
- Pre-align stakeholders individually on the options and understand what they would prefer (do this 1:1)
- Then give the stakeholder the options in a meeting to make their choice.
Thats my take on it from a large company point of view
- Try to re-work the plan and confirm that the plan cannot be met
- Provide options e.g. de-scope parts of the project to hit timeline, 3 week delay, weekend working which means $x impact
- Ensure that you understand why the project is running late (planning, new requirements, impact of external issue)
- Pre-align stakeholders individually on the options and understand what they would prefer (do this 1:1)
- Then give the stakeholder the options in a meeting to make their choice.
Thats my take on it from a large company point of view
recognize as early as possible that project is off schedule (through milestones / reporting etc)
Identify why schedule has slipped (scope creep, resources not performing at expected speed, suppliers deliver late, etc)
identify scenarios to mitigate impact -
more money / resources?
what elements are critical to deadline, what can be slipped?
what will be the key impacts and other alternatives.
present situation and options to stakeholders ASAP giving them all the information available for them to give business steer.
re-align project based on stakeholders steer from information and options presented.
Identify why schedule has slipped (scope creep, resources not performing at expected speed, suppliers deliver late, etc)
identify scenarios to mitigate impact -
more money / resources?
what elements are critical to deadline, what can be slipped?
what will be the key impacts and other alternatives.
present situation and options to stakeholders ASAP giving them all the information available for them to give business steer.
re-align project based on stakeholders steer from information and options presented.
XJSJohn said:
my pet hate is the "tell me your biggest weakness" question.
"I've shagged your wife.......only joking, telling really inappropriate jokes at completely the wrong time is my biggest weakness"Joking aside, I think the correct answer has been answered. The only spin on it that I'd have added is that if this was a known risk then it would be recorded in a risk register and hopefully already have some kind of mitigating action detailed if things do go belly up.
My first port of call would be to talk to my manager, he's the one I need to protect me, so would explain there first, definitely don't want him getting a call from a Sponsor / Stakeholder without them first knowing! After this I'd talk to the sponsor next and then contact the stakeholders via exception report etc. You don't want the sponsor finding out second hand!
In the real world and as already answered look at cost Vs quality options and understand the result of each one. A reduction of scope may mean the project produces no business beenfit which makes the whole thing pointless.
From the OPs other forum posts it would appear they are a software developer. I work as a sysadmin however I work closely with developers delivering projects on a daily basis.
Here is the route I would go with the question.
First off notify people as soon as possible and try and come up with possible solutions:
Next up you need to review why and how you got into this situation in the first place ?
The main thing is to isolate the points at which delays happened and try and reduce them.
There are loads of things I've missed here but you probably get the idea. What you do in the long term in terms of improving process and tooling is just as important, if not more so, than what you do in the short term.
With all interview questions like this then it's the discussion, not the answer, which is more important.
Here is the route I would go with the question.
First off notify people as soon as possible and try and come up with possible solutions:
- Can you cut/delay features ?
- Work out which parts left to finished are going to take the longest ?
- Can we sacrifice some short term technical debt in order get things moving faster ? (this is often a very dangerous game to play though)
Next up you need to review why and how you got into this situation in the first place ?
- Did things take longer than expected ?
- Has there been feature creep ?
- Did the requirements keep changing ?
- Bugs that didn't get picked up early enough ?
The main thing is to isolate the points at which delays happened and try and reduce them.
- Is QA taking too long because they are finding bugs that should have been picked up by functional tests ?
- Is getting feedback from the client taking too long because it's taking 2 days to deploy newer versions of the software ?
- Are you spending too much trying to optimise things you shouldn't be ?
There are loads of things I've missed here but you probably get the idea. What you do in the long term in terms of improving process and tooling is just as important, if not more so, than what you do in the short term.
With all interview questions like this then it's the discussion, not the answer, which is more important.
XJSJohn said:
my pet hate is the "tell me your biggest weakness" question.
"Trying to please as many people as possible at the same time to my personal detriment, I also find it hard to remember, when asked that question, that there are no stupid questions when that particular question shows that there is always an exception that proves a rule."John is right, recognise that you have a delay is the first thing, then you can look at the cause and mitigation. Like any problem the first step in solving it is to recognise it. Most project teams do not recognise the delay in tome, they know its there but bury their heads in the sand.
The key is not to talk to the stakeholders in the first instance but the Sponsor..... only when you have done this should you start talking to stakeholders.
And make sure you have your facts and options ready first, really understand the critical path and then have a conversation; that is the sign of a good Project Manager.
Poor Project Managers either;
1) bury their head in the sand and "hope" it will be ok
2) try to make it somebody else's problem
3) panic
either one of the above will see you leaving my organisation.
If the PM is doing a good job the fact that the project is going to be late should be apparent early enough to make some balanced choices.
S
And make sure you have your facts and options ready first, really understand the critical path and then have a conversation; that is the sign of a good Project Manager.
Poor Project Managers either;
1) bury their head in the sand and "hope" it will be ok
2) try to make it somebody else's problem
3) panic
either one of the above will see you leaving my organisation.
If the PM is doing a good job the fact that the project is going to be late should be apparent early enough to make some balanced choices.
S
Fundamentally, you need to give a specific example of what you did when it happened to you. It s a competency based question and you need to discuss an example to demonstrate the competency.
Personally I would select an example that had a decent end result and discuss the things you learnt and also the things you do differently now to prevent it happening again.
Personally I would select an example that had a decent end result and discuss the things you learnt and also the things you do differently now to prevent it happening again.
Gather your software testers together for a meeting and ask their opinion and advice.
If I had ben asked why something wouldnt work, or how long I felt something would take to be implimented, tested and released for UAT the project I work on would have been delivered properly months ago, rather than overhearing about issues, and making it 10 times worse by pointing out other things that would be affected by 'a quick workaround *shudder*
Testers normally have the second best feel for the system after the devs, and the devs are only interested in the code, not wether the code works as it should (bigger picture sort of thing)
Plus, if you let your testers know the issue, they can re-prioritise their work and concentrate on the blocker, fit in a bit of regression testing around the implimentation and get it tested and ready for business UAT ASAP!
No good when we know nothing, and the bug sits in our Jira list for a few days as no one thought to tell us the importance of it...
/xmas rant
If I had ben asked why something wouldnt work, or how long I felt something would take to be implimented, tested and released for UAT the project I work on would have been delivered properly months ago, rather than overhearing about issues, and making it 10 times worse by pointing out other things that would be affected by 'a quick workaround *shudder*
Testers normally have the second best feel for the system after the devs, and the devs are only interested in the code, not wether the code works as it should (bigger picture sort of thing)
Plus, if you let your testers know the issue, they can re-prioritise their work and concentrate on the blocker, fit in a bit of regression testing around the implimentation and get it tested and ready for business UAT ASAP!
No good when we know nothing, and the bug sits in our Jira list for a few days as no one thought to tell us the importance of it...
/xmas rant
Gassing Station | Jobs & Employment Matters | Top of Page | What's New | My Stuff