How can we prepare for "getting hit by a bus"?

Question

As a self-employed person working for a client (e.g. creating a website), you have a bus factor of 1:

The bus factor is the total number of key developers who would need to be incapacitated (as by getting hit by a bus/truck) to send the project into such disarray that it would not be able to proceed; the project would retain information (such as source code) with which no remaining team member is familiar.

If something happens to you, the client might have a problem.

• The work might not be finished. What if the client already (part) paid for it? What if the client hasn’t yet received login passwords etc.?
• The work might be finished. What if the project is so complex that the client can’t simply hand it over to someone else? What if the website runs on your server? What if you registered the domain?
• You may have signed a NDA. What if your heirs stumble upon sensitive data of your client?
• (… What else to consider?)

How can we prepare for it?

Answer 1

Without wanting to sound too cut throat about it, I would say that this is firmly the client's problem and not yours. It is in their interest to ensure that they have source code in a location that they can get hold of it and that they have full access to everything that they require to access the system.

If you're concerned about this and want to show due diligence towards your client in regards to it, you could make use of one of the cloud platforms, such as Amazon Web Services or Windows Azure, to host the website, and ensure that someone within the client's organisation has login details. Likewise you can use a cloud source control provider such as Bitbucket to ensure that they can access the source code at any time.

This is unfortunately a risk in any organisation that relies on a single individual to build a website/software system.

Answer 2

The best thing is to have a network of other professionals who the client knows they can hire if they don't like you or something happens to you. In my business, I am the most active developer on LedgerSMB, but we are a multi-vendor solution and if clients want to fire me there are more options on the web site, clients can look through the email archives for ideas on who to approach or the like. I am generally pretty confident that if I get hit by a bus, we are to the point where the client can find others who can ramp up to speed relatively quickly.

Answer 3

By default, share login access, use VCS and comment well...

Think about it from another perspective: If you were a developer who took over halfway through somebody else's project, what would you want available to you?

You're obviously going to need to make sure the client has SSH & FTP access to the server, and preferably access to your bzr repository (or other version control system) to get the work that's done but not pushed live yet.

Commenting is important. As a developer picking up from someone else's 'bus effect', you're going to much better understand the code base if it has full documentation of its classes, methods etc. than if the comments are inconsistent (or worse, absent).

There is more you can do, but it's time consuming...

Past here, you'll want to be talking to the client about specific requirements which differ from project to project. If you're using a fairly common framework with a fairly linear set of requirements, you may not need any more.

If, on the other hand, you're working on a 300KLOC C++ behemoth with custom libraries etc, you're probably going to want to document properly. Obviously, this is time consuming and a lot of clients will turn you down on it, but at that point you've done what you can.

I always offer full UML planning for my projects and try to quote a reasonable fee, these are the easiest way for a client's new hire to recover from the bus effect.

Answer 4

The work might not be finished. What if the client already (part) paid for it? What if the client hasn’t yet received login passwords etc.?

Try looking into version control systems (SVN, Git) and upload your changes as soon as you make them. This way, your client will always have access to these changes. If you are afraid that they will just take the latest changes and run away without paying you the last part (or the full) payment, you may store the login for the version control system and give it to someone you trust.

You may have signed a NDA. What if your heirs stumble upon sensitive data of your client?

Although it's not 100% security, you should always password protect your laptop/server/project folders. If you are that much concerned, you may even encrypt it.

Answer 5

I think there is only one general advice that would apply everywhere. You should have ICE (In Case of Emergency) list, at least one close person should know where it is (someone you trust to actually follow it) and on that list one point would be "Call all my current clients and tell them I wont be able to finish the contract on time / never because of what happened. List of my current clients with appropriate contacts is here: (location)"

It is really your clients responsibility to make sure they dont depend solely on you - that is the price for raising quality of work and cutting down the costs at the same time by using freelancers. Your responsibility is only to make sure that they know they need to carry out their contingency plan.

Answer 6

You improve the bus factor by adding heads with the critical knowledge, or you make it moot by raising it beyond the number of key developers.

I had a number of clients, back when lots of companies were discovering what cool kinds of things they could make or do if they embedded a computer in their products. I was some of my clients' first and only software guy - bus factor 1.0.

BF improvement:
What I did then was to keep my managers in the loop. They were usually engineers who realized they didn't have enough hands to do everything within their responsibility and who hired me to relieve them of the software duties. The contracts were R&D, or Product Development, i.e., ongoing, and I'd convince them that they needed their special knowledge to reside with one or more people in-house, not just with me, and I'd help them select and train their first software hire. As they grew and needed more, but not quite 1.0, people, I got lots of callbacks as the fractional guy. Working myself out of a job was the mainstay of my early career.

BF mitigation:
Documentation. I always figured that if I could re-acquaint myself with what I'd done 6 months ago, then a next person could, too. And as often as not, I was the next guy! I comment my code with that in mind. There were a couple of cases when the next person who wasn't me thanked me for making his job easier. I keep that in mind, too.

Answer 7

The main reason why anyone should be asking this question is if it might affect his/er ability to get hired. While I personally haven't had a big enough project where it might affect the livelihood of my loved ones should I get hit by a bus, it definitely did cause some early clients to pass on to other agencies to give their projects to.

You see, design/development/illustration/etc. is an investment to your clients, and investments have risks as well as rewards. It's in your clients' best interest to mitigate their risk as much as possible. When they're looking for someone to help redesign their website for $15k (or what it is that you offer your clients), they want to make sure the project will be completed as promised.

With $15k on the plate, a sole freelancer who works form home looks a lot more risky than a 5-person agency that has a track record of completing projects just like this one and has even received an award for one of those sites.

So, what you can do to blow away their objections is address their concerns in your marketing:

• Show your workflow on your site. This shows that you're more than just a great designer. Your'e a great project manager who can take care of their project. Make sure your workflow includes small deliverables throughout the scope of the project instead of just one huge deliverable at the end, if possible.
• Show past projects complete with testimonials form clients that state how much they felt they were taken care of, how professional you were, and how you delivered serious results (make sure this is a REAL testimonial).