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.
