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

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 ProjectThis 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.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 DesignOnce 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.