What happens if your key developer goes under a bus?

OK, a little morbid I know, but it is a question I am asked on far too regular a basis. "What happens if you leave or get in an accident?" Technically it's called key person risk and is the reason you have teams, good documentation and source code control with non-stop backups. 

Technically I have only left a project twice before I wanted to and before a convenient delivery point. 

• Large public sector integrated web site, knowledge-base and licensing site. I left 1 month before go-live as the contract renewal negotiations broke down. The site eventually went live 18 months after I left.
• Geospatial data management system - I left when the scrum master decided they knew more than the architect, about a month before an on target delivery. System still not live 1 year later.

The reality is that you don't survive key person risk easily, it's a huge nightmare and usually puts you back about a year. How to avoid it? Have a happy team that communicates and try not to let too much jealousy creep into negotiations.

Story time:

Once upon a time a large digital consultancy was hired by a multi-billion dollar computer chip manufacturer to create an online game. The brief was that the game should have sufficient difficulty that at the end of 8 weeks a winner could be declared and presented with an expensive gaming laptop. The rules of the game were defined by the sales manager as a flying game where the player had to pass various obstacles, the complexity and difficulty of which were beyond human reaction times until the last few weeks of the game.

The project was delayed through negotiations and when it was eventually agreed it just so happened that the star developer who helped the Sales team was on a vacation, his first in 3 years. The sales team decided to hire an external consultancy that they knew and had used before to undertake the work, they did not engage with the in-house engineering team, preferring to keep all the details in one place.

When the star developer returned he was reserved to undertake due diligence on the progress from the external consultancy (part of the ISO27001 quality assurance the agency had.) He asked for the brief, the backlog, the progress against plan and a login to the code repository. It turned out there were a few missing items, notably:

• There was no brief (it was verbal and conducted in 'brainstorming' sessions)
• There was no backlog (The sales team simply reviewed the prototypes)
• There was no plan (The sales team simply set a deadline)
• There was no code repository (The developers did everything on their laptops)

There was however a working prototype and a copy of the code from 1 week previously. The prototype would work as long as you did not use the controls, it was an early prototype demonstrating the visuals of the game.

The Star Developer called a meeting with the sales team and expressed his concern, raising warning flags that in his opinion they were unlikely to meet the deadline some 6 weeks away, however the sales team had confidence in the external consultancy as the lead salesman only lived down the road from the consultancy, which was run from a converted Victorian house in his street. The Star Developer asked to be included in the next review at the end of the week and asked that the consultancy be informed that a code review was required.

The end of the week came and the external consultancy had to cancel the meeting due to unforeseen circumstances, the following week came and went with no submissions. The sales team where not worried, the prototype was nearly there weeks ago, and there were 4 weeks to the deadline, it wouldn't take long to test surely?

The in-house testers had not written a test plan as there was no brief, after a 1 week of discovery they estimated 2 weeks to write the scenarios and 4 man weeks to test them.

The Head of development called a crisis meeting, attending were:

• 2 of the sales team
• A representative from the external consultancy
• The Star developer
• The Lead tester
• The Head of development

At the crisis meeting the external consultancy relayed a sad story. I turned out that their lead developer had been involved in a road traffic accident, he had been hit by a bus whilst cycling to work.

Not to worry, the Star developer was now available, if the consultancy simply supplied the code completed to date, they would complete the project. The external consultancy explained again that their lead developer had been involved in an accident, he was still in hospital.

The Star developer explained that he would be able to continue the work, all he needed was the code completed to date, the external consultancy explained that their lead developer was travelling to work with his laptop, which was destroyed in the accident. The laptop contained the only complete copy of the code.

The development was brought back in house and an attempt was made to continue from the submitted prototype, it turned out that the game parameters had not been documented or understood; if the user simply shook the mouse long enough then they would win the game. The entirety of the codebase had to be thrown away.

The conclusion of the engagement was that the entire project had to start again, the sales team negotiated that the project was put back 3 months and the competition was completed, the engagement still made a small profit but the client rolled future engagements over due to their standard policy of re-competing suppliers every 2 years.

The lessons learnt are numerous and may well be longer that the story, but it does go to prove that if you say "What happens if the developer goes under a bus?" You may get more than you wished for.