Project Management

3 Tips for Avoiding the Single Point of Failure

From the Voices on Project Management Blog
by , , , , , , , , , , , , , , , , , ,
Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with--or even disagree with--leave a comment.

About this Blog

RSS

View Posts By:

Cameron McGaughy
Lynda Bourne
Kevin Korterud
Conrado Morlan
Peter Tarhanidis
Mario Trentim
Jen Skrabak
David Wakeman
Wanda Curlee
Christian Bisson
Ramiro Rodrigues
Soma Bhattacharya
Emily Luijbregts
Sree Rao
Yasmina Khelifi
Marat Oyvetsky
Lenka Pincot
Jorge Martin Valdes Garciatorres
cyndee miller

Past Contributors:

Rex Holmlin
Vivek Prakash
Dan Goldfischer
Linda Agyapong
Jim De Piante
Siti Hajar Abdul Hamid
Bernadine Douglas
Michael Hatfield
Deanna Landers
Kelley Hunsberger
Taralyn Frasqueri-Molina
Alfonso Bucero Torres
Marian Haus
Shobhna Raghupathy
Peter Taylor
Joanna Newman
Saira Karim
Jess Tayel
Lung-Hung Chou
Rebecca Braglio
Roberto Toledo
Geoff Mattie

Recent Posts

The Planning Paradox

Project Management: Talent or Skill?

Project Management Is The Great Equalizer

3 PM Lessons I Needed to Relearn

4 Signs You’re a Micromanager in Your Projects


Categories: Agile, Best Practices, Teams


By Christian Bisson

In this article, I refer to “a single point of failure” as the situation when a company utilizes someone with unique expertise/knowledge that no one else has, or is the only one who does a particular task. By having these single points of failure within a team, you risk facing problems if that person becomes unavailable—or even worse, just isn’t part of the team anymore.

Fortunately, there are various ways to mitigate this!

1. Rotate roles within the team

There are several tasks that often fall by default on the scrum master or the “nice guy’s” shoulder. A good example is sharing a screen so everyone can see the backlog for a planning or a refinement session, or sharing the board in a daily scrum (if it’s not physical).

If that person is not there, then the meeting becomes less effective because the logistics (using Jira, screen sharing, etc.) is not necessarily well known by everyone.

By having a rotation system (by random name picking, for example), these tasks are eventually done by everyone and all can be efficient doing it eventually; therefore, the team doesn’t become dependent on a single person to know simple things like updating the story points of a ticket using Jira. 

I once came across a team that couldn’t do its own planning without the scrum master sharing the screen and going step by step with them, and it had been doing it for several months!

2. Conduct knowledge transfer sessions

This can be done in many ways, but I’ve seen a lot of teams planning a weekly knowledge transfer session, where each time someone presents something to the others (a new tool, something they just coded, etc.). Another good way for developers to share knowledge is for them to code pair. That way, the code itself is known by two people instead of just one; throw in peer reviews on top of that and you will be in better shape if someone leaves or is on vacation.

The idea is to avoid having only one person knowing something; always aim for a minimum of two people. If you want to identify gaps, there is always the classic “lottery winner” scenario you can use, which is to keep in mind that it’s possible for someone to win the lottery and therefore become unavailable without notice. Although it might seem unlikely, the idea is to ask yourself: For every member of the team, what would be the impact if that happened?

3. Rotate members among teams

This practice is debated, but I feel it’s a good way to make sure the knowledge is properly spread. The idea here is to have a rotation system of team members among the teams. This practice is questioned by some, who will argue that to be effective, teams need to be stable—and changing it will make it regress to the “forming” stage.

That is indeed important to keep in mind when thinking about how/when the rotation will occur, but in the long run, people will be accustomed to working in all the various teams—and also be knowledgeable in all the different pieces each team takes care of. This gives a much higher flexibility depending on deliverables/vacations/etc., and lowers the risk of losing knowledge on something within the organization.

What tips do you recommend?

Posted by Christian Bisson on: July 02, 2021 11:32 AM | Permalink

Comments (10)

Please login or join to subscribe to this item
So powerful to note again that avoiding failure means ensuring continuity by #2. Conduct knowledge transfer sessions

Thanks!, I recommend standardization as a driver to flexibility and avoid single point of failure; if processes, templates, ways of doings are standard, the knowledge is shared and can be applicable by anybody anywhere. Moreover, standardization enables training to newcomers and smooth rotation among employees.

Dear Christian
Very interesting theme that brought to our reflection and debate
Thanks for sharing and for your tips.

I am convinced that the important thing is that:
1. That there is sharing of tacit and explicit knowledge among all team members.

2. Implement a philosophy of continuous improvement by sharing lessons learned

Thanks Christian.
I would approach it differently. Centralization normally build expertise in certain function that is more scarce than others. After achieving reasonable redundancy we would overcome the single point of failure. Then, we can de-centralize. In addition, embracing the learning organization concept and embedding the knowledge Management system would help in avoiding the recurrence of single point of failure.

Interesting and important topic when resources are limited. Conduct knowledge transfer sessions or brown bag sessions with team members in similar functional area. For team meetings rotation is useful when there is a template which provides a format.

Regretfully some people, to protect their jobs and enhance their personal power in the workplace, do not document or allow access to their work-in-process, notes and historical data/user files to others.

An effective project management information system (PMIS) and enterprise file management system must be in place to capture and archive essential knowledge and work artefacts gathered/produced by project team members.

All files (paper/electronic) should be saved and backed-up to a safe and secure network belonging to the organization—never stored on an individual’s stand-alone computer or storage device.

Yes indeed a project management practitioner may encounter problems if a team member with ‘unique expertise and knowledge’ becomes unavailable—or leaves the team altogether. How do you prevent this?”

Project management practitioners—yes it’s a risk—but please don’t suggest that ‘Mitigate’ is the sole risk response strategy.

Noteworthy is that “Mitigate” is just one of many risk response strategies.

The following are strategies to manage a negative risk:
- Avoid
- Mitigate
- Transfer
- Escalate
- Accept

These deal with positive risks:
- Escalate
- Enhance
- Exploit
- Accept
- Share

Cautionary Note

In some workplaces project managers own the work while the functional managers own the resources. Therefore, the risk response strategy must be developed in tandem with the functional manager.

Food for Thought

“In a matrix organization the project manager has no one reporting to him/her administratively. Instead, needed skills are “borrowed” from the functional managers. The project managers own the work while the functional managers own the resources”—Michael D. Taylor, PMHut

Single person in the team having particular knowledge is both ways risky, the member can often overloaded to the extent he cannot go on a leave, if in-between critical tasks ..... For team it is the risk of unavailability of the person ! Knowledge transfer and second line training must happen .. thanks for the article

It would appear that Christian's Blog and the resulting comments supports the premise that applying 'KM' (Knowledge Management) good and best practices can go a long way to minimize the disruption--especially when the only person with unique, specialized knowledge or person who does a particular task becomes unavailable—or leaves the team altogether.

What is KM?

The classic one-line definition of Knowledge Management was offered up by Tom Davenport early on (Davenport, 1994): “Knowledge Management is the process of capturing, distributing, and effectively using knowledge.” Probably no better or more succinct single-line definition has appeared since.— Michael E. D. Koenig

Please Login/Register to leave a comment.

ADVERTISEMENTS

"O, it is excellent To have a giant's strength! But it is tyrannous To use it like a giant."

- William Shakespeare