Reliable information, reliable decisions, reliable systems, reliable teams

I don’t attend many meetings these days, but when I do, I’m reminded of the failure modes of meetings, when group think can take over, leading to poor decisions by the group. But like all human reliable systems, the group can do some simple things to correct the problem before a failure.

Systems commonly trade off performance for reliability. In telecommunications networks, we can trade off latency for assured packet delivery through Forward Error Correction (FEC). Rather than make a hurried left turn into traffic, we can slow down and wait for a lower risk opportunity to make the turn. Group meetings are similar. We can slow down the meeting a bit by checking our assertions with facts and data.

In a group, we can take time to check our assumptions. Often, in the dynamics of a group meeting, people make assertions that may not be true, though widely held. The other day, I met with a large group of reliability experts, some of the best there are on the planet. I made a statement about the importance of a particular field of research, and one of the best experts on reliability, and this specific field as well, questioned that assumption, asking for evidence. That challenge lead to some serious thought. And while another participant offered some support for my statement before I was able to, the question was still provoking. What if my statement had not been well supported? How often do we check our ideas for support? How often does a group make a decisions off of an ssertion that lacks evidence? Fortunately, in our story, someone questioned the evidence, and the evidence was presented. But how often do groups not behave that way? I could assert that it happens most of the time, but I leave it to you to check your own experience. Fortunately, we can commit to taking the role in any group to question the assertions that members make, and take the time to make sure decisions are evidence based.

When we are in charge of inviting attendees to a meeting, how often do we consider the group dynamics, and try to design the right group for a decision? Sometimes we have to invite process owners, peers, interested parties, and others due to organizational requirements. But what if we considered the group to be a system or a network, and tried to design that team for reliability? What if we added redundant components to the group so that the right experts were in the room, the right points of view, and the right support for the decisions that the group needs to make? When the dynamics of a group are not ideal, try to build some redundancy in that group to help it succeed at its mission. If one person must participate, but they tend to disrupt the discussion with their own agenda, offer them a limited amount of time to address their concerns, and invite someone who can  address that need so that the meeting can focus on its main goal. Build redundancy into the group system. If one person you must invite always makes claims that you believe are not correct, gather the evidence before the meeting that supports your point, and meet with that person before the meeting to address the disagreement before the meeting, in a form of proactive maintenance.

Not only can we try to structure our teams to be designed for reliability, but we can also use the dynamics of effective teams to create reliable systems. Think about the different roles that group members take, and consider analogies. The team leader usually acts to break ties. A redundant voting system needs an odd number of voting members to break ties in decision processes. It is always good to have one person take notes, but a second is better in case they miss a key point; redundancy is often important in any system. Think about the dynamics of effective teams you have been a member of, and how you can leverage that design in other applications.

Back to the group, checking our assertions is almost always the right thing to do. I encourage everyone to ask for evidence behind any assertion presented in the group that might be important to the decision process for the group. Reliable information enables reliable decisions by the group. Reliable decisions can yield reliable designs, reliable systems, and reliable results.


About Rupe

Dr. Jason Rupe wants to make the world more reliable, even though he likes to break things. He received his BS (1989), and MS (1991) degrees in Industrial Engineering from Iowa State University; and his Ph.D. (1995) from Texas A&M University. He worked on research contracts at Iowa State University for CECOM on the Command & Control Communication and Information Network Analysis Tool, and conducted research on large scale systems and network modeling for Reliability, Availability, Maintainability, and Survivability (RAMS) at Texas A&M University. He has taught quality and reliability at these universities, published several papers in respected technical journals, reviewed books, and refereed publications and conference proceedings. He is a Senior Member of IEEE and of IIE. He has served as Associate Editor for IEEE Transactions on Reliability, and currently works as its Managing Editor. He has served as Vice-Chair'n for RAMS, on the program committee for DRCN, and on the committees of several other reliability conferences because free labor is always welcome. He has also served on the advisory board for IIE Solutions magazine, as an officer for IIE Quality and Reliability division, and various local chapter positions for IEEE and IIE. Jason has worked at USWEST Advanced Technologies, and has held various titles at Qwest Communications Intl., Inc, most recently as Director of the Technology Modeling Team, Qwest's Network Modeling and Operations Research group for the CTO. He has always been those companies' reliability lead. Occasionally, he can be found teaching as an Adjunct Professor at Metro State College of Denver. Jason is the Director of Operational Modeling (DOM) at Polar Star Consulting where he helps government and private industry to plan and build highly performing and reliable networks and services. He holds two patents. If you read this far, congratulations for making it to the end!
This entry was posted in Engineering Consulting, IT and Telecommunications, ORMS, Quality, RAMS - all the -ilities and tagged , , , , , , . Bookmark the permalink.

Comments are closed.