Project Management – What is your “Bus Factor”

Andy McComments off.

[icegram campaigns=”412″]
The bus factor is a common term in software development projects, but each and every project manager should be aware of it.  “Being a good project manager means I could get hit by a bus tomorrow and a colleague could pick up any project and run with it .”

The statement is a play on something we frequently talk about as project managers regarding risk mitigation.  The bus factor refers to the number of people on your team who need to be ‘run over by a bus’ before the project is in trouble. Of course, for the employee to ‘disappear’ you don’t need a morbid bus accident: she could suddenly change jobs, switch projects, move away, have a health emergency or simply retire before the project will be in jeopardy. One thing is sure: you don’t want your bus number to be one.  However, a key member of the team that PMs rarely ask this about is themselves. Being a project manager is about risk mitigation and communication, and a huge part of that should be reducing the dependency on yourself.

For some project managers, this can make them uncomfortable. By making sure you are not a dependency, they will sometimes think that this makes you expendable. While it does mean that you minimise the switching costs of your role (they could replace you with relative ease) the role of a PM is still essential to any project. The work that you undergo to make sure that your role can be taken over at the drop of a hat means that it is easier for your team to react if you are out of the office, or on holiday.

Yet when it comes to the ideal team size, we know that less is more. If you want a highly efficient and motivated team, you should really keep it between 5-9 people, which is also the number of people in an agile development team. In most cases, unless you are severely understaffed, you really shouldn’t be going around hiring people just to increase your bus number. So how can you increase the bus factor without adding extra people to the team?

It’s important to look at the current processes in place, as well as at the work itself.  For example, if one key employee leaves their job tomorrow, how would you get access to the work he’s currently doing? Are all the vital files stored on his personal computer? Where did he file those documents that are essential to the project?  Where is the up-to-date Project Plan –  And then there’s the extra work itself: who on your team can tie the loose ends of the lost member’s contribution to the project?

Simplify your processes

Aim to make it almost impossible for one employee to hold all the information by simplifying your processes. This includes using modern technologies (if you are using out-of-date technologies then you are planning to fail!) as well as technologies that anyone can easily learn. In the day and age of SaaS, where everything from customer relationship management to  Project Plan Management to File Storage is cloud-based, there’s no reason not to. You can start by filing and sharing your internal documents through the cloud, reviewing your office communication tools – including email, and practices will also play a big role in simplifying your processes.

Regular team updates

Meetings can often be a waste of time, but it’s not so with team updates. At least, you should be having a weekly update meeting, or even better, a daily morning huddle where each team shares what has been accomplished and what are their top priorities for the next leg, or sprint,  of the project. You should also encourage sharing possible roadblocks and pinch points that team members can help solve after the meeting. This will definitely boost collaboration and the sharing of information.

Multi-training

It’s not only necessary that team members know what everyone is working on, but also that they know how everyone is working. You can have a low bus factor if there is no skill redundancy on your team. You want your employees to be generalists to some degree. Multi-training in basic tasks will ensure that the tasks can be covered for when one employee goes under the bus. As much as possible, you want every member of the team to have at least one secondary skill that will allow them to cover for a team member.

Pair programming

Again, there’s something to learn about collaboration from this agile development technique. Pair programming is a technique where two programmers sit together at one workstation. The driver writes the code while the navigator reviews each line as it is typed in. The programmers switch roles frequently. There’s also another style of pair programming, called promiscuous pairing, where each programmer works with all the other programmers on the team instead of pairing with only one programmer.

Of course, this technique is not applicable to every position you might have in your team. Sometimes it’s not viable to have two people work together on a sub-team. But it teaches us something about a culture of learning and collaboration. Programmers get to see and examine their partner’s work and provide feedback. This is essential not only for sharing information but also for the team members to develop their own learning mechanisms.

Flexibility

You can increase the bus factor by allowing workers to work out of the office. If your colleague  is at home with the flu, that you don’t want to spread around the office, chances are they are still able to do part of the job. If their child is sick, they can still perform some of their responsibilities while away. This doesn’t solve the problem of what would happen if a team member permanently left the team, or if they are not capable of fulfilling their duties remotely. But it is a good way to trick the bus number when your other options are limited.

However, doing all the above will prove to be inadequate if you do not address any issues that would arise if you , as Project Lead, were unavailable. So let’s look at some questions you can ask yourself:

• What regular meetings do I have, and are the clients names/location/call credentials easily available?
• Do I have profiles of all of my clients/project stakeholders and what my interaction points with them are?
• Can my project plans or long term planning resources be found and understood without explanation? Are they easily accessible and understandable?
• Do I have a todo list that can be easily transferred?
• Are my regular updates for project sponsors clearly identified?

As you start to ask yourself these questions you will see a pattern of the information that you regularly leverage in your day to day basis that would be helpful for someone stepping into your shoes. Once you have this information, you can determine the best way to make it accessible. One idea is to have a regularly updated one-page dossier (or Project Charter)  on each project. Another idea is to have checklists for all of your projects with tasks that are required in the process (legal approval over the vendor contracts, deployment scripts ready, sign off from change management, etc.) Regardless of the manner in which you make your information accessible, the point is that it is imperative that you do so. This way, you provide a method for someone to step into your shoes easily, with little to no knowledge transfer required.

 If you are concerned with your business resilience contact IMENTOR today for a FREE scoping meeting.

bus, factor, innovation, leadership, management, productivity, project, project management, projects, scrum Posted in: Project Management