Bus-Factor
From YWAMKnowledgeBase
| Rate this Article |
|---|
|
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.
Contents |
Problem description
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
Possible Solutions/Strategies
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?
- Non-existent
- 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.
- Excellent
- With this document at hand, it is easy to pick up another's work.
