Bus-Factor - Avoid to depend on a single person
The idea: Imagine, one person of your team got hit by a bus - would your project be in serious trouble (i.e. die)? Then your bus-factor is 1 (worst case). Everyone is depending on this one person (everyone depending on everyone would be even worse, but this is also counted as 1.) If one person can be removed from the team and the project can continue but removing a second person would critically weaken the project, the bus-factor would be 2. So the higher the bus-factor is, the better.
This is very relevant to YWAM, as staff turnover is high (see Churn rate) and often unpredictable.
The Wikipedia article, Bus-Factor, explains the problem further.
The same idea in a more mathematical manner (Truck-Number): http://c2.com/cgi/wiki/wikibase?TruckNumberFixed
Train Your Staff
Cross-training can increase the bus-factor because then more people know enough about a project to make it survive.
Document Your Project
Documentation also improves the bus-factor because anyone who can read can follow what has been done (if documented well enough!).
Is your documentation good enough? Let's take a little test. Which case is applying most to your documentation?
- People turn into living knowledge bases. This may be flexible in the pioneering phase, but it will get annoying for that person to be asked over and over again.
- Poor / insufficient
- A written document exists, but does not describe the whole picture and/or needs heavy updating.
- Good Enough
- With this document at hand, it is possible to pick up another's work.
- Your documentation should have at least this quality.
- With this document at hand, it is easy to pick up another's work.
Technology use needs experience
Using technology to facilitate or even automate tasks is often tempting (e.g. using a spreadsheet for keeping track of lent books). But don't forget that not everybody has the same experience in this particular technology, so you'd need to train others & document what you did and how you use it.
Use standard Technology
Also, whenever possible, use technology that is usually used for this task: the more popular it is, the more people can potentially take it over because they already have some experience (If you use some specialized librarian software for this task would reduce the chances of finding someone that can use it; compare this to using Excel.).
If I got Hopelessly Sick / Died Suddenly ...
(a blog entry from ywamit.com)
As the password database (both in my head & in an encrypted file) grows, I increasingly worry about the responsibility which is behind. Not only that someone else could get access to these passwords, maybe suddenly the Internet stops working (at least at home), my computer stops working, the hard drive refuses to read the database file; maybe I'm in holidays, sick or otherwise occupied, and in this very month a significant security update should have been made for [replace this with concerning server or website]; or worst, my heart stops beating and someone else is trying to take over my heritage because he desperately needs access to [server/website].
Let's take worst case: I suddenly die. He will have really tough times. Set aside that from the amout of data I have on my disk he will be interested in maximum 10 % of the files, he probably just doesn't have the IT knowledge that I ... had. If he doesn't know Linux, he will have no chance of doing whatsoever on my computer. So we could seperate his task into 3 different aspects:
- Find out which technology I used
- Learn this technology
- Find out the password.
Repeat this process for each specific problem you ask, such as: "how to read the files?", "how to crack the user account?", and finally (!), "where to find the password of my website?". So even though I appreciate tofirius' thoughts about Digital Legacy, this only covers part 3) of the process. He's talking about sending relevant passwords to his leaders, 1) do they know, were to enter these passwords?, and 2) Are they familiar with this, at least to the point where they can teach themselves the rest? If not, they will desperately take the next computer crack that arrives - maybe a DTS student - and delegate this work to them. [ This cannot be our goal, even if it works (too often I was in this situation at the beginning of my YWAM "career"). Firstly, because we cannot assume that the leader or the student can realistically assure that technically savvy enough for the specific task, and secondly, we are giving the student almost total control over the concerned system - do we know we can entrust him with this responsibility? ]
So what can we do about it? Essentially, more cooperation between IT staff in YWAM. (That's why I'm so excited about this communication platform!) To show an example: I am part of the Joomla!-Community, and seeing that many other YWAM sites are made with Joomla! also, I could imagine forming a Joomla! working group. This could imply
- maintaining documentation about how the corresponding website is working
- forum for learning from each other
- peer exchange of relevant passwords, e.g. in a way that some peers have to work together in order to get access to the website.
So when a security release appears (a really bad one like 1.5.6), all admins of 1.5.x-Sites will be notified by email; they then will post back that their website is updated. After a reasonable time-frame, let's say a month, the remaining sites will be upgraded by the community and the admin will be notified. This ensures that critical bugs will be patched ... at the moment, there is not even a notification process, so I'm sure there are sites out there who hasn't be updated since Aug 08 - because the non-technical guy is saying: what's the matter, it's working, isn't it? Until the day that the site is completely defaced [ which, by the way, is not the worst case ... it would be worse that the hacker silently installs some additional things remaining undetected - and some day start sending spam or similar. ], they won't even recognize.