Dear community, have you ever heard of the “bus factor“? No? Neither had I until recently. That’s not a big deal, because you know the story behind this number very well from many projects yourself.
So, what does this number mean? Well, it shows us how many people in a project have to be hit by a bus at least, and thus be out of action, for a project to come to a standstill.
If you don’t want the story surrounding this number to be quite so negative, you can also ask yourself how many people have to leave a project for the project to come to a standstill. These people could, for example, quit because they won the lottery and from that moment on are so financially well-positioned that they no longer have to go to work.
Apart from the approaches to understanding this number, its significance is much more crucial. Since it’s about people, it ultimately revolves around bottlenecks in know-how (knowing how something is done corresponds to theory) and skills (being able to actually do it corresponds to practice).
When I look back on my working life in the SAP ecosystem, this number was usually around 1. Shocking but true. Regardless of whether the projects were small or large. Due to the complexity of many issues and the deep expertise of many project members, who complemented each other but didn’t replace each other, one can speak of a “single point of failure.” At least for a certain period of time, until you reacted to the loss of a single person.
You can consider the bus factor for your current team. Do you simply complement each other’s skills, or are there genuine duplications, i.e., personnel backups?
You usually really notice this when the question isn’t just considered theoretically but is applied in practice. This is the case, for example, when a project member is on vacation. Can someone then replace the person, or does the project at least come to a standstill with regard to the topics for which the respective team member is responsible?
I’ve already seen how to successfully counteract project standstill. Good content for future blogs. Until then, everyone is welcome to consider what the bus factor is in their own teams.
See you soon
Michael