Many Possibilities

The Context

Every year in our team at work, we get together to discuss our research funding budget. Each team at IDRC is responsible for producing a yearly “pipeline” of projected research projects to fund. Our team is pretty spread out, in four offices across the African continent and in Ottawa. We rely on a face-to-face meeting every year around March to talk through everyone’s proposed projects and come up with a coherent set of projects that are in line with our 5-year strategic plan. The trouble is that these discussions, even with the best of intentions, often end up being a bit of a bun-fight with people defending their own projects and being critical, often due to lack of time to discuss the projects in sufficient detail. While we have improved incrementally in the way that we approach this, this year I hoped we could make a leap forward in how we approached this. My goals were the following:

1. Have each team member thinking about the big picture, about the body of knowledge that our collective funding is going to contribute to and not just their own projects.
2. Find a way to deepen the understanding of team members of each others’ projects in an efficient way.
3. Not waste time arguing minutia of projects where there is already broad agreement i.e. focus our face-to-face time on the most contentious proposals.

I should mention that we did have some virtual team (text) chats via Skype to review the proposed projects but we limited those sessions to asking questions for clarification as the synchronous online text environment is not a great environment for debating complex issues. This gave everyone at least a nodding acquaintance with the overall project pipeline and gave team members clues as to areas that would need further elaboration prior to the face-to-face team meeting. I nabbed the idea of printing each project on a single sheet of paper by accidentally walking in on the telecentre.org team meeting a month ago.

As a setup for the meeting process, we had the title and description of each proposed project printed in as large a font as possible on a single sheet of paper. These were stuck up on a wall of our meeting room, in no particular order, spread out as much as possible. Each project description could then be read from a few feet away.

So, on to the day itself. After an Open Circle (OpenSpace style) we moved on to the first session of the day.

1. Articulating the Research Questions

This session was pretty straightforward. Team members broke out into pairs and interviewed each other to articulate the key research question of each of their proposed projects.

In the past we have found that focusing a discussion around the project research question has the effect of sharpening the focus and understanding of the project in general. In this case, it also helped team members to better understand each others’ projects, albeit a subsection.

We spent about an hour doing this during which each team member wrote out the research question for each project on a sheet of paper and stuck it up on the wall under the relevant project. To the left you can see the wall full of project descriptions with the research questions written and posted underneath.

2. Social Tagging

Now we come to my favourite part of the day. I am an avid del.icio.us user and a strong believer in the power of social bookmarking as well as the power of emergent taxonomies or folksonomies. I wondered whether it was possible to recreate some of the power of online tagging into a face-to-face environment. Thanks here to Nancy White, Alison Hewlitt, and Beth Kanter for pointing previous experiments that Beth had done on “live tagging”.

We adopted a slightly more prosaic approach than Beth. Each team member got a pad of Post-It notes on which to write their “tags” and they were instructed to post them around the projects. This was a process that had multiple benefits:

• On a very basic level it forced team members to read project descriptions and research questions (again or in some cases for the first time). It deepened (in a fun way) the understanding of each project without engaging in debate.
• It encouraged team members to think abut projects on a meta level thinking about themes and key issues
• It allowed common threads to emerge from the tagging process.

This part of the process was a real success. It achieved all of the above and more. The biggest challenge in this session was to communicate clearly at the beginning what sorts of things one might write on a tag. For those who hadn’t used del.icio.us before, it was not immediately obvious what a tag represents. The best way I could think to describe tags was as a kind of aide memoire. I asked team members to think about descriptive terms they would use about the project that would help them find it again if they were looking for it. I highlighted the fact that these terms might well be different for each person. I think I still need to work on a succinct explanation of tagging as an introduction.

The tagging exercise took us through to lunch time. At this point I felt like we had achieved at least a couple of our goals, namely to deepen understanding of the projects and to get the team to begin connecting the dots and thinking big picture.

3. The Stoplight Exercise
The purpose of this exercise was to begin to highlight projects where there was broad agreement and more importantly where there was very little agreement. Everyone was given a page of colour coding labels and was asked to mark projects with a green, yellow, or red dot. Green for “I am happy to support this project”, Yellow for “I have some questions I’d like answered first”, and Red for “I have issues with this project proposal”.

This exercise was intended primarily to identify projects where there was a lack of consensus among the team. The intention that this would allow us to focus the majority of our efforts on fundamental areas of disagreement and not let time get away from us by spending too much time discussing smaller issues simply because they came up first. In a way the stoplight exercise was a kind of coarse filter for the final “Gradients of Agreement”.

4. Gradients of Agreement

This exercise was a vast improvement on any previous methods we have used to seek consensus. At a suggestion from Alison, we drew on Sam Kaner’s “Gradients of Agreement” from his excellent book “The Facilitator’s Guide to Participatory Decision Making”. Kaner suggests that disagreement is seldom black and white; that there are gradients of agreement. He offers 7 levels of agreement ranging from full-on endorsement to outright blocking. The interesting parts were the middle gradients which expressed sentiments such as “disagree but unwilling to hold the majority back” or “I can live with it”.

Each gradient was printed on a single sheet of paper. Originally I had thought to tape the sheets to the floor in a line in front of the projects on the wall but it turned out to be better to stick them to chairs and line the chairs up. See photo at left.

We then initiated a discussion on proposed projects, starting with those projects that had attracted the most red dots and working backwards from that. We began each project by asking team members to stand by the gradient that most closely reflected their feelings about the proposed project. While team members were asked to move dynamically from gradient to gradient, we found it was necessary to stop from time to time specifically to ask people to reflect on their “gradient”. Kaner goes into detail about the process and I can’t recommend the book enough. We carrying on discussing each project until it was evident their was sufficient agreement or it seemed likely that no consensus was likely. In general we assumed that each participant had veto powers but no one ever felt compelled to use them.

Improvements for next time
There is still lots of learning to be done in implementing the above exercises. I think each of them were worthwhile and each built well on the previous exercises. They added up to a very productive day and a stronger sense of vision and of common threads across our programming.

One area that we didn’t account for was how to deal with projects that are very similar. I think a separate clustering process linked to the tagging exercise might be a useful addition. We would have to change the way that we physically represent things on the wall though as it would have been too much work to move all the pages and tags around. Also, I would want to think about what to look for in clusters. Maybe just looking for areas of substantial overlap.

It is tempting to think of moving this whole process online. It think it would work very well and might facilitate virtual decision/consensus making processes. Perhaps when I have some spare time…

All comments and suggestions welcome.