How to Get Consensus in a Meeting with the “Fist of Five”

Have you ever been in a meeting and asked “Is everyone okay with this plan?” only to be answered with silence. You prompt again “any concerns or questions”?” again nothing. Finally you announce that you are going to assume silence means consent and move on to the next topic. But here is the big question: Is silence consent?

In order to answer that question, think about what happens after the meeting where you assumed silence was consent. After the meeting, did one of the team members turn to another and start pointing out the flaws in the plan? In the coming days and weeks did anyone keep bringing up that same topic again because of additional concerns? In the worst case scenarios when you go ahead with the plan and it does not work. Is there someone who stands up at the Follow Up meeting and says “I knew this plan would never work”? Those are all signs that the team did not reach a consensus.

The Merriam Webster defines consensus as “general agreement” and “group solidarity in sentiment and belief”. It’s that second definition group solidarity you want to reach with your team.  Group solidarity means we all agree to support this decision or plan going forward. That means we won’t walk out of the room and start telling everyone this is a bad idea, and we don’t think it will work. It means that even if it fails you will stand up and say you agreed it was worth trying.

Consensus is not a group vote where majority rules. It is the entire group agreeing to support a decision or idea. There is a very simple technique you can use check for consensus: The Fist of Five.

When you are ready to ask “Is everyone okay with this plan”, each team member responds by raising their fist with one to five fingers.

• Five fingers – You think this is a very good plan and you fully support it
• Four Fingers – You support this plan, it’s not perfect, but you strongly support it
• Three fingers – This plan may not be your first choice, you have some concerns about it, but you understand the arguments presented in the meeting and you agree that given the current circumstances it is a reasonable plan moving forward and you support it
• Two fingers – There is an issue you feel must be resolved before you can support the plan, further discussion or follow up is required before you can support it
• One finger – You do not support this proposal, you do not think it will work, it is going to take some serious convincing to get you to change your mind

If everyone is showing 3 or more fingers then you have consensus. If anyone is showing less than 3 fingers ask them to explain their concern and develop a plan to address and follow up on that concern.

It’s simple, and it works. In fact we had a team meeting this week where we were putting this technique to good use as we discussed how to work with user communities, developers and IT Professionals across Canada. Besides what could be better than a meeting technique that sounds like the title of a Kung Fu movie!

All those in favour?

This blog post also appears on the Canadian Solution Developer

Another Meeting! Who Really Needs to Attend?

Have you ever been to a meeting where part way through you thought to yourself “I do not need to be here”? It’s happened to all of us. I once asked my husband exactly what he does at work. He thought about it for a minute and answered “I go to meetings.” Meetings are everywhere! Now don’t get me wrong, meetings can be very effective. We want to keep everyone informed, and we do need to consult with different team members when we are making decisions. But how much thought do we put into who to invite to meetings? Most of us err on the side of caution and invite everyone who may have an opinion or wants to be kept informed. After all haven’t we been told over and over again the importance of communication? But sometimes we forget meetings are not the only way to communicate.

I have done a lot of work with the Information Technology Infrastructure Library, better known as ITIL. Don’t worry I am not going to go into a diatribe on the benefits of MOF (Microsoft Operational Framework) and ITIL here and now (that’s a blog for another day). The reason I bring it up is that in ITIL I came across a wonderful model I have applied very successfully. Its called the RACI model (pronounced racey). RACI is an acronym for Responsible, Accountable, Consulted, Informed. This model can be used to help you run more successful meetings. As they say in Kinect Dance Central…let’s break it down.

Responsible –  Who are the people responsible for doing the work? The people responsible should definitely be in the meeting. For example, if you are holding a meeting to discuss a bug fix, you definitely want the programmer who is making the bug fix present to explain the effort required to fix the bug, or to explain the cause of the bug.

Accountable – Who is the person who is ‘on the hook’ for the work? This is often the supervisor of the people responsible. Sometime it helps to think of the A as standing for Authority, as in decision making authority. Who has the authority to make decisions? There should only be *one* person identified as accountable. Otherwise you run into problems. There is a Danish proverb that roughly translated says “When you have one clock in the house you know what time it is, as soon as you have two clocks you are are never sure.” You want the person accountable in the meeting, because if they aren’t there you may find the meeting going in circles because there is no-one in the room with the authority to make a final decision on how to move forward. If the person accountable cannot attend, see if they can appoint someone to attend to act on their behalf with their authority. Otherwise, you may want to reschedule the meeting to a time when the person accountable can attend. For the bug fix meeting example, the operations manager or project manager might be accountable. We want them in the meeting because they will have the final decision on if or when we fix the bug based on the effort required, the impact on the users, and the other team priorities.

Consulted – Who are the people who will want a say in the decision or discussion but are not doing the work itself? Often you can provide these individuals with a summary of the topic to be discussed by email and follow up with them before and after the meeting. They may give you questions that they want answered, but that doesn’t mean they need to attend the meeting itself. Often you can ask the questions on their behalf. If the question is too complicated, then you may invite them to the meeting so they can explain and elaborate as necessary. For example, when you are making a bug fix you may need to consult with the security team to ensure that the fix does not violate security policy. Most of the time, if you let security know what you are going to discuss in the meeting, they will tell you the concerns they need addressed. After the meeting you can let them know the outcomes and give them an opportunity to identify any outstanding issues.

Informed – Who are the people who need to know what is going on? These are the people who need to be kept in the loop, but do not need to attend the meeting. For example, your user community, your client, or the testing team may need to know about the progress on a bug fix but that doesn’t mean they need to attend all the meetings. Often e-mail or a collaboration, project tool like SharePoint or Visual Studio Team System is sufficient to keep them up to date.

So the next time you are invited to a meeting, ask yourself where you fit in the model, if you are not responsible or accountable, do you really need to attend? If you are holding a meeting, complete the RACI model for the topic being discussed. On some projects, I have documented the RACI model for each programming module, or bug. That way when a change or issue was identified we immediately knew who was responsible, who was accountable, who needed to be consulted, and who needed to be kept informed.

So in keeping with the meeting theme, here are

My 5 Tips to successful meetings (there are many more, but I’ll stick to 5 for now)

1. Complete the RACI model for the meeting.
2. Email your agenda, or questions to be discussed one to three days before the meeting. That way everyone has a chance to arrive in the meeting prepared. Don’t send it out to far in advance or they will forget about it before the meeting.
3. Book a suitable meeting room with the required amenities. Make sure you have enough chairs, water, a projector if necessary. It is very frustrating for meeting attendees to spend 20 minutes sitting unproductive while you run around the building trying to find a projector or whiteboard markers.
4. Use a parking lot! Meetings frequently go off track, do not be afraid to have a flipchart or corner of the whiteboard where you can park issues for follow up later. It is important if you use a parking lot that you do leave a few minutes at the end of the meeting to discuss how you will follow up on each item in the parking lot. A parking lot is not meant to be a black hole.
5. Do not deliver surprises in a meeting and expect useful feedback. When someone tells us about a new initiative or change, our first reaction is emotional: I love the idea or I hate the idea. It will take me a little while to absorb what you have told me and give you useful feedback. All too often we walk into a meeting and are informed of a major change, then while we are still reacting to the news we are expected to provide constructive criticism. If you tell me today by email or in person, and give me some time to absorb the idea and mull it over I would be in a much better position to discuss it rationally tomorrow in a meeting.

This post also appears in the Canadian Solution Developer Blog