“Consensus is the negation of leadership.”
-- Margaret Thatcher[i]
“Genius abhors consensus because when consensus is reached, thinking stops. Stop nodding your head.”
-- Albert Einstein[ii]
I had published several pieces in my Variance Threshold column in PMNetwork on a particular element of PM prior to PMI® contacting me to participate in the creation of the Practice Standard on that topic, so I felt pretty good about writing a couple thousand words for the draft Chapter One, and sending them off to the effort’s PM. He had arranged for a confab of the early contributors out in California, at a hotel/conference center, and I was looking forward to hobnobbing with my fellow subject matter experts. And man-o-man, was I in for an education.
We were in a conference room with a “U” shaped table, with a laptop and projector at the base of the U, and a screen at the top, where the PM would project the text I had sent. If memory serves, there were around a dozen people in the room. As an aside, I was the only attendee who had actually generated verbiage. Everyone else there was in the position of reviewer. When my first paragraph was thrown onto the screen, about half the room objected to it, for various reasons. Interestingly, the other half of the room was okay with it, or even praised it. Paragraph One marked for further review, on to Paragraph Two. This time, those who objected to Paragraph One approved, but those who found Paragraph One acceptable were suddenly critical of Paragraph Two. Paragraph Two marked for further review, on to Paragraph Three.
And so it went, the entire frustrating weekend.
At a subsequent get-together sponsored by PMI®, this one to cover the ground rules for creating practice standard-level content, a representative from the American National Standards Institute (ANSI) gave a presentation on the, well, standards to be observed while generating our document. During the Q&A, I asked about a suitable test for making an include/don’t include determination on content, and his answer amazed me. He said that, essentially, an assertion should not be included if a substantial number of people who are identified as experts in the field objected to it. This is consistent with ANSI’s definition of “consensus,” which reads:
Consensus means that substantial agreement has been reached by stakeholders. It signifies more than a simple majority, but not necessarily unanimity. Consensus requires that all views and objections be considered, and that an effort be made toward their resolution (emphasis in the original).[iii]
My (and, probably, PMI®’s) takeaway: never allow Hatfield to be the author of a document where consensus is called for.
I’m in good company. Consider this quote from Michael Crichton:
Let’s be clear: the work of science has nothing whatever to do with consensus. Consensus is the business of politics. Science, on the contrary, requires only one investigator who happens to be right, which means that he or she has results that are verifiable by reference to the real world. In science consensus is irrelevant. What is relevant is reproducible results. The greatest scientists in history are great precisely because they broke with the consensus.[iv]
Of course, Crichton is referring to the hard sciences when he talks about reproducible results. However, I’m made bold to assert that the Management Sciences aren’t that far removed from their harder cousins. Both are subject to the task of comprehensively identifying all pertinent parameters, and to then quantify them precisely. In those instances, like the free marketplace, where comprehensively identifying all pertinent parameters, and then precisely quantifying them is next to impossible, it’s pretty easy to see why consensus becomes the automatic stand-in for the whole hypothesis-experiment-evaluate results cycle upon which authentic science depends.
Even so, I’m forced to agree with Thatcher and Einstein. In the Project Management arena specifically, the PM must be the one who has final say with respect to setting the technical agenda. It’s been my observation that the technical agenda set by consensus is more likely to fail to come in on-time, on-budget for any but the most routine of Projects. To be clear, I’m not saying that guidance documents or practice standards should be assembled in any other way, nor that the PM should not be informed by the subject matter experts to whom she has access. I am saying that, ultimately, the way the Project Team approaches the problem to be solved must be the responsibility of one person. If they succeed, that person and the Project Team deserve accolades. If they fail, not so much. If they fail catastrophically, the PM should own the selected technical approach, and face consequences. Otherwise, they will end up adding to some wrong-headed consensus, which turns into policy, increasing the odds that someone else in the organization will use the wrong-headed strategy, with entirely predictable results.
Based on such a sequence, I’m going to remain skeptical that consensus is the friend of management science, or true leadership.
[i] Retrieved from https://www.azquotes.com/quotes/topics/consensus.html on October 26, 2024, 19:26 MDT.
[ii] Ibid.
[iii] Retrieved from https://www.ansi.org/standards-faqs on October 26, 2024, 20:44 MDT.
[iv] Crichton, Michael, “Aliens Cause Global Warming,” Caltech Michelin lecture, January 17, 2003.
Posted on: October 29, 2024 10:17 PM |
Permalink
Cameron Fraser
Consultant and Process Facilitator (retired)| Stonewall Consulting
Ottawa, Canada
I was a consultant and group facilitator for 35 years. I am also and International Association of Facilitators Certified" Professional Facilitator | Master and have worked with and for many Project Managers over the course of my career. Consensus was, and is, a useful tool, but it is just a means to an end, not an end in itself. It appears to me that neither the PM of the project youve described nor the individual from ANSI understand that particularly well.
I should warn you this is a relatively long reply. I feel pretty strongly about this, in no small part because I think many people get consensus wrong, and their response can create an equally difficult situation where there is little buy-in to decisions. I will start this by including the old George Box quote& All models are wrong. Some are useful. I think its useful to keep in mind that nothing is perfect when considering these sorts of questions.
Firstly, a look at the quotes that open the article. Thatchers undoubtedly had an agenda behind it&One driven by a particular leadership approach. They did not call her the Iron Lady for nothing. Equally, Einstein has a point, as far as it goes. Genius is responsible for so many things that have made the world a better, more knowledgeable place. On the other hand, genius would have been of remarkably little use when my wife and I wanted to design and build a major addition to our home. We needed some pretty clear consensus on what we were trying to achieve and how.
Different situations require different approaches. I would argue that in the situation described in your post, the PM holding the meeting chose the wrong approach, and then executed the chosen approach badly. Not every decision should be made by consensus. Figuring out what consensus is needed on (if at all, who is making the decisions, who else should be involved, and to what extent, is a foundational piece that needs to be decided in advance.
An old, but to my mind still useful model in describing a range of options is Situational Leadership originally created by Dr. Paul Hersey and Dr. Ken Blanchard while working on the textbook, Management of Organizational Behavior. It was first introduced in 1969, so is often discounted because of its age. Another is the Vroom and Yetton decision model, which is newer, but not by much.
What both these models have in common is that they recognize that different situations require different approaches. At their extremes, they have decisions that are made solely by a leader and, at the other end of the scale, the decision is made by the group and accepted by the leader without alteration, with a range of options in between. One of the things I like about Hersey and Blanchards model is it explicitly talks about the level of expertise of those being led, the decision making approach of the leader changing depending on the level of knowledge and skill present, and the role of the leader in developing those knowledge and skills. That leads us to an aside.
You undoubtedly know of and may have participated in a team building exercise called Lost in the Desert. (There are variations that occur at sea or on the moon.) It puts a group in the hypothetical situation of having survived a plane crash in the desert. Their task is to rank fifteen items salvaged from the plane in the order of their importance to the teams survival. There are three steps to the exercise. In the first, individuals make their own list of priorities. Secondly, the group works together to produce a consensus based list. Finally, the correct answers are provided and the individual and consensus lists marked for accuracy.
Many years ago, I went through the exercise with a group of people I worked with, and the result was pretty clear. Our consensus for priorities as a group was better than any of our individual lists. Being young and keen I decided to use the same exercise with a group of Officers I was working with in the military reserve. Strangely, I got exactly the opposite result. All the individual answers were better than the consensus result. So much for teambuilding! And I was at a loss for an explanation.
Some time later I came across an article published by NASA about the variability of results in the exercise. What it came down to was that when the individuals had limited knowledge of survival techniques, the consensus result was better. When there was an expert in the group, the result was better when the group deferred to the expert. And there was my explanation. All of my young officers had a degree of expertise in bushcraft beyond what the average person might, but because they were told to make decisions by consensus, they ended up compromising on things that they knew better about, in the interests of achieving consensus.
And so back to your post, and why the meeting you were in produced a poor result.
1. Firstly, given my comments above about the desert survival exercise, it may well have been better off to defer to an expert&perhaps you as original author or another person acting as a reviewer&rather than have a group discussion. If there has to be a group discussion it might have been best to defer to whoever had the most expertise around particular points.
2. Secondly, and perhaps painfully obviously for people in my line of work, there was no explicit process. Without a stated purpose, outcome, and process, I would argue that the goal of the meeting unintentionally defaulted to achieving consensus, rather than producing the best product, in this case a refined document. (I would also argue that sticking to the goal of a better product needs a good facilitator, but I may be biased.)
3. Having decided this was going to be done by a group, there was no explicit discussion of how the group would make decisions, beyond looking for consensus.
4. There was no shared definition of consensus or discussion about what the expected threshold for consensus was. (How will we know we have reached consensus?) Arguably, even if you are going to go with consensus for decision making, there needs to be a discussion about what level of consent is required. I would argue that, in some critical cases it needs to be, or very near to being, unanimous. In other less consequential decisions 50% +1 may be good enough.
5. Even when you define a threshold for consensus there are nuances. Do you need people enthusiastically on board or is it enough for them to simply let things happen and not actively oppose a decision? Or is it somewhere in between?
If the PM needed consensus from the gathered group on the use of the document, then a point by point review of the content of the chapter was not the best approach. They needed a better understanding of what they needed consensus on. A far better approach would have been to ask questions like:
" Is this chapter consistent with our intent for the overall standard?
" What key messages are there that we must keep/emphasize?
" Are there any key messages missing?
" Are there any concerns you would like to see addressed in the next draft?
The answers to those questions would then go back to you as the author for use in creating a second draft, rather than having the group edit piecemeal.
Long and short, a lack of a defined outcome, no clarity on who and how to make decisions, and a lack of defined process doomed this session. Consensus is a fine tool for improving work and getting buy in, and is very useful for leaders of projects, but if getting consensus is the only goal, or it accidentally becomes the only goal as seems to have happened here, then things get pretty easy. All you have to do is descend towards the lowest common denominator.
Community Champion
