8

Recently in my company we had a project where the deadline was very tight, and everything was going according to plan until I was unavailable due to extreme personal issues.

Eventually we missed the deadline by 4~5 days.

What are the usual recovery plans for these conditions? should my company attempt to outsource a developer to finish my work? even that could take a few days to find one?

Christophe
  • 74,672
  • 10
  • 115
  • 187
Sherif
  • 201
  • 1
  • 4
  • 3
    If your part of the work can be outsourced with no training or transfer of information from you, you may not be adding much value. But typically, in a well-managed project, one must allow some contingency time (based on the project duration but never less than a week) to manage risks like this. – James McLeod Dec 30 '17 at 19:05
  • Why wasn't there anyone to finish the job? – Euphoric Dec 30 '17 at 19:17
  • @Euphoric: maybe there was someone available (just noone who could hold the deadline), the OP did not tell us. – Doc Brown Dec 30 '17 at 19:45
  • the company is not very large ... I was the only backend engineer available – Sherif Dec 30 '17 at 19:47
  • 7
    "Recently in my company we had a project where the deadline was very tight" - so in other words, (a) the project manager created a deadline that didn't allow for anything to go wrong, and (b) the project manager was unable to foresee any risks (such as a developer being unavailable for a period of time, not exactly an exotic circumstance) and therefore was unable to plan for them. Sounds like you need a new project manager, unless this one can learn from his/her mistakes. – Kyralessa Dec 31 '17 at 07:32
  • 4
    @Kyralessa: Or (c) the project manager was forced to squeeze out all buffers from the planning because someone else made unrealistic promises to the customer. "Building this can't be that hard, so lets promise a delivery date before we ask the developers for their estimates." – Bart van Ingen Schenau Dec 31 '17 at 09:38
  • 3
    @BartvanIngenSchenau, in a situation like that, his/her job as a project manager is to push back. – Kyralessa Dec 31 '17 at 15:54
  • Its a catch-22. Ideally there should not be human single points of failure. But then the business reduces costs by eliminating redundancies. – Thomas Carlisle Jan 02 '18 at 20:29
  • ["adding programmers to an already late project just makes it later" - Frederick Brooks](https://en.wikipedia.org/wiki/The_Mythical_Man-Month) – radarbob Jan 04 '18 at 18:13

6 Answers6

10

It depends on the foreseeable duration of the unavailability, the remaining duration of the project, the way the tasks are distributed and the consequences of missing the deadlines.

Software developers are not an interchangeable at will. Developers build knowledge on the system as the system grows, and adding a new resource requires to cope with the missing contextual knowledge of the new resources.

Several good practices reduce the risks associated with sudden unavailability:

  • peer reviews ensure that knowledge on the development are shared between several developers. In case of unavailability, the rest of the team could reorganise to take over, or in the worst case bring in a new coder and organise a knowledge transfer.
  • integrated colocated teams that closely work together for making design decisions can mitigate unavailability in the same fashion. The shared knowledge on the overall design facilitates redistribution of work and briefing of newcomers.
  • formal documentation could eventually help. However in practice this works well only if the documentation produced by one developper is used by another developper (or models used in code generation tools). Documentation that is only read by oneself frequently appears to be much more ambiguous. If a new developper has to take over such work, the self documentation might raise as much questions that it answers.

Bringing in new developers when there are tight deadlines is very challenging, because briefing the newcomers take time of the team, in a period where there's no spare time. If you're ill for 1 week it makes no sense. It's to be envisaged if the cost of briefing newcomers is compensated by the benefits of the new resource, typically if there are high costs of being late, or if it's not possible to postpone, or if the unavailability is over a longer period of time.

Christophe
  • 74,672
  • 10
  • 115
  • 187
  • 1
    This is fairly close. The most important thing is to actively ensure someone can cover you at a moments notice. – candied_orange Dec 30 '17 at 22:49
  • In project managment there's a concept for these cases. The planification should take in account this sort of situations. Now is too late for the company for minimizing the impact. Be honest with the stakeholders and make them know that the deadline should be moved. Meeting deadlines is almost nothing compared with meeting expectatives. Trying to save this lack of planification at expense of "quality", the solution could be more expensive than you think... After the release there's only one "first impression". – Laiv Jan 02 '18 at 21:56
  • @Laiv Thank you for your feedback. I cannot judge if in this case the deadline can be postponed or not. In the past I managed several critical Y2K and EURO introduction projects for which a postponing was not an option. But I agree with you on the principle: it is better to discuss deadline matters with the customer when the risk is to high, instead of trying to covertly find an impossible alternative and fail. Planification of contingency is of course a must; but unfortunately it is not sufficient to deal with such extreme situations (reserves tend to get exhausted at end of project). – Christophe Jan 02 '18 at 22:47
  • Yes, that's true. I have not seen too many projects in under-run despite the budget for contingencies. – Laiv Jan 02 '18 at 22:52
5

The usual plans for this is to build contingency into the deadline. Things happen, you often never hit deadlines. You being unavailable was just another hiccup in the carefully laid plans that never go according to plan!

gbjbaanb
  • 48,354
  • 6
  • 102
  • 172
  • You're completely correct: every plan needs some contingency reserves to deal with risks. The problem with too much contingency however is the self-fulfilling prophecy effect: in the end the contingency gets consumed anyway. And in the last weeks of the plan, people might still fall ill although there's no margin left. So contingency alone is not sufficient. – Christophe Dec 31 '17 at 15:06
  • 1
    Actually, contingency is a risk mitigation strategy but their are other ways to deal with risk, including removing it (make sure others can take over without affecting the schedule), accepting it (the default if you don't manage your risks), or transfer it (in this case, inform the client/customer that they are not paying enough to guarantee in-time delivery and they need to be ready to handle any delays). – James McLeod Dec 31 '17 at 16:49
5

This is called the "bus-factor". Basically, the risk posed to the project if a developer is hit by a bus. Having a developer unavailable for a week is a small hiccup compared to losing a developer permanently. It could be an accident or sudden illness, but less dramatically it could just be a core developer switching job on short notice or getting fired. Or a core developer getting transferred to another high-priority task in different department.

In short, you have to either plan for lowering the bus-factor, or you have to be prepared to mitigate it, e.g. by having buffers in deadlines or just be flexible enough to be able to push the deadline. What you usually cannot do is just outsource a complex task on short notice, or hire a new developer - it would almost always take more time to introduce a new developer to an existing system than to wait a week for a core developer to return. If a small team loses a member they will of course be slower, but if the also have to introduce a new member, they will be even slower.

You can lower the bus-factor by having a team continuous knowledge sharing and peer-reviews (or even pair-programming). But of course this is something which have to happen before the bus hits.

JacquesB
  • 57,310
  • 21
  • 127
  • 176
2

Any employee may become unavailable for a week, or a month, or forever, without any notice, at any time. Accident, illness, having had enough of this job, many other reasons. It is up to management to make sure that such an occasion is annoying, maybe expensive, but not a disaster.

If you have a team of ten, you might lose 10% of your team. The company should be able to handle that if the rest of the team is motivated (paying for overtime is highly motivating). If you are a team of one, then the work isn't going to be done. If you have other employees who can step in, the delay may be minimised. Hiring someone from the outside would be difficult, although you probably find some contractor who can start at a days notice for a few weeks at a very high hourly rate.

The best thing to do is to have contracts etc. in place so that a delay finishing a product is not a financial disaster. And to have a planned and achievable finishing date way ahead of the deadline. Having employees that can step in for each other helps (but can be problematic to achieve).

And if you have a deadline that must be achieved, then maybe the scope of the work is more flexible. In other words, drop features to meet your deadline.

gnasher729
  • 42,090
  • 4
  • 59
  • 119
1

One key way to reduce the "Bus Factor" that @JacquesB mentions above is pair programming as a core technique. (My own practice is to use the term "Lottery Factor" since it's less morbid but the effect is the same.)

Many developers hate pair programming; many managers hate it too, for entirely different reasons (some developers hate being forced to communicate with other humans for extended periods; some managers often feel incorrectly as though they are paying twice as much money for a single output).

But pair programming all-but-eliminates the risk of a single human point of failure, by ensuring that any given development task is performed and understood by at least two developers.

Jim Kiley
  • 191
  • 1
  • 5
0

There are a number of ways I've seen this sort of thing handled:

Share the work out

The most obvious thing to do is share the work out among existing resource (assuming this is possible). How to ensure the developers hit the ground running is almost an answer in itself but ultimately, it boils down to properly recording requirements, designs and progress. Things like pair programming can also assist greatly here.

Push the deadline back or attempt to claw back time

Check with the customer to see if the deadline can be extended. Alternatively, it might be possible to gain addition development time by working evenings, weekends and holidays.

Drop other tasks

Are there any other non-critical tasks that can be temporarily dropped to make room?

Get ahead

Is there work planned after the development that can be brought forward such as documentation, test scripts and configuration?

Admit it could be late

Speak to the customer early. It might be possible to deliver in part - or at the very least, you could get a decent steer on the relative priorities of other things.

Additional resource

A possibility - but this itself carries risk. It will take time to get them up to speed and as they're temporary, they could just leave leaving you even worse off.

Check the critical path

If other parties are involved - check that they are still on target. There is little point in moving heaven and earth to get something finished if say, the test team are a month behind on testing things.

Accepting the realities of risk

There is a common phrase in the legal profession that states that hard problems create poor solutions. It can be tempting to try and get everybody to understand everything to cover all eventualities. This however, is a fools errand.

Developers should be spending quality time on their own developments. Consuming an ever increasing amount of time becoming au fait with other developments is a highly questionable activity. A reasonable middle ground might be to have a subject matter expert and a deputy.

Robbie Dee
  • 9,717
  • 2
  • 23
  • 53