You are here: Home & Blog » Collaboration and Co-Creation » Don’t Let the Collaborative Event Tail Wag the Project Dog

Don’t Let the Collaborative Event Tail Wag the Project Dog

by Bryan on December 31, 2009

I’ve been facilitating and supporting face to face collaborative events for over 25 years and sometimes have to watch against an event-centric approach in my work. Of course a major collaborative event involving perhaps hundreds of participants and spanning several days must be well designed. The event must have objectives and deliverables. It must have inputs, assignments, preparation lists, pre-event work, capture of information and outputs during the event and a summary after the event. There’s nothing wrong with doing this work–it’s all necessary. But in all of the planning, the context and overall purpose of the event can be lost. A collaborative event should support a project or initiative. The resources and focus of the project should not be rerouted in subordination to the event.

To avoid this common error it helps to (1) think differently about how the event is positioned in the project and (2) change some of the language around the design of the event itself.

Positioning a Collaborative Event in the Project
This starts with an understanding that all projects and initiatives, no matter how large or small, are about change and transformation. Transformation in living systems occurs when the system moves from one state of behavior and activity to another. Ideally this change of states should improve the performance or positively affect other characteristics of the system. So much has been written about change and transformation that I won’t add to it here, but the bottom line is that the replacement of existing behaviors with new behaviors is difficult. The replacement process involves several steps (depending on whose change model you subscribe to) and probably loops back on itself once or twice along the way. The purpose of collaborative events–particularly face to face ones–is to short circuit some of the process and dampen the looping by allowing a group of people to feel and see that they are all in this change together and that they can collectively map their way to a reasonable solution. The solution that they create together represents a probability that a successful future exists for them all. If they feel this mutual support and confidence in the future, then they can exit the event with more alignment and better ideas. This further allows them to accelerate the progress of the project. Alignment, better ideas and acceleration are the three brass rings of most collaborative events.

Since face to face events are expensive and time consuming, positioning them in the project is key. Imagine mapping the stages of a project over time on a horizontal axis against cumulative difficulty on the vertical axis. The result is probably not a straight line but a curve with a few hills in it. The hills represent those places in the project where risk threatens project continuity or where certain change-related obstacles live. For example, everyone may be on board with a change project until action planning shows clearly how it will affect them. Potential resistance creates a hill in the project that can be difficult to climb. Hills like these are potential places to use a collaborative event like a bulldozer to smooth the hill out or to even lower the curve itself (making the overall project less difficult). The event can also be thought of as a catalyst, lowering the amount of energy required to make the transition from one behavior state to another.

using collaboration in major projects to smooth high energy hills

Resist the urge to position major collaborative events in a project for the sake of tradition. For example, a major event may or may not be the best way to conduct a project kick off. We feel that such events should be mounted when there is something of substance for the participants to design or create together. Therefore, we don’t use events to elicit buy-in from employees or other stakeholders.

The Language of Event Design
Once the event is positioned properly within the project, it’s appropriate to talk about what outputs from the project will be available at that time and what inputs to the project are required for the next phase of the project after the event is complete. This is subtly different than considering what inputs the event requires from the project and what outputs the event will produce. Why should this difference matter?

Let’s say that the project is designed to last 12 weeks. Around week 8 the work of a smaller design team will be fed to a larger group of people for testing and integration with other existing practices. This is the hill in the project. A small group of people will have become intimately familiar with the work done to date. They will have coalesced as a team. Therefore they likely have both that feeling of mutual support and a sense of a successful future that allows them to accelerate their own transformation. Now in their enthusiasm they will present their work to a much larger group. But this larger group does not feel mutual support around the transformation and is nervous about the future. That’s the hill. That’s the wall to climb. Sometime around week 8 in the project, a collaborative event can be developed to grow mutual support and a sense of a successful future across a much broader set of stakeholders by including them in the design of the solution. The inputs to the event are the deliverables that have been created to date in the project according to the project work plan. The outputs of the event are the inputs to project week 10.

The collaborative event also should accelerate or otherwise improve the project. This means that the project duration decreases, or the project deliverables created by the end of week 8 have increased (creating some slack in the schedule), or additional deliverables can be created that will improve the likelihood of success or compress the time for execution.

To test for these benefits, design major projects without major collaborative events first. Then add them in and determine what advantages should accrue to the project as a result. If the advantages are minimal, either remove or reposition the collaborative event.

Main Content

Be Sociable, Share!
Frances Gillard January 1, 2010 at 8:35 am

Great article, Bryan! Your hill analogy (bulldozers, curves, etc) also reminds me of the thought, design, engineering, and results from building a good road, where the layout on the terrain (project) has a definite effect on the ease of getting from point to point on the road. Ensuring the best possible slant, water run-off, width, curve to speed limit ratio, and desired functionality are just some of the nuances necessary to qualify as a good road. When done well, these aspects are a sign that the road is meeting all the driver’s needs without the driver even consciously knowing it. To me, that’s what collaborative events do. They help the “driver” get to a better place in the overall project by getting them faster and more smoothly than on a non-collaborative “road.” Maybe I’m way out in left field, but thought I’d offer some thoughts on the first day of 2010. Hope it’s a happy and healthy one for us all.

bcoffman January 1, 2010 at 5:06 pm

Wow! I’ll have you write the core blog post next time. One of my most favorite assignments in college field surveying was laying out a road. All the things that you mention must be taken into account. It’s a nice metaphor to use–especially the curve to speed limit ratio. Even with an accelerator like a collaborative event, you can’t push the envelope too hard or you’ll just have traffic flying off the road.

Yes, I hope we all have a happy and healthy 2010.

Blessings.

Joanne June 10, 2010 at 7:51 am

Hello Mr. Coffman,

This was a wonderful post and will help me thoroughly in rethinking a current project. In my department we just initiated (and just got the go ahead on) a collaborative project between university research and our department. And immediately I hear “kick off” event although we have met 3 times to get the “go” and the 2 teams are on other sides of the country. Knowing the extreme culture differences of academia and business, your post made me think of the project as a collaborative process versus event-centric. I will look for the hills first! (nice analogy)

Thanks
~Joanne

Comments on this entry are closed.

Previous post: Creative Tension: Blessing, Curse, and Essential

Next post: The Unknown, the Future, and the Impossible