I’ve been reading and thinking a bit about “collective impact” lately. (Here’s the seminal article introducing the buzzword.) It’s a solid, mostly-common-sense framework for thinking about collaborative/coalition efforts. There are five elements that define a “collective impact” approach:
- Common agenda. If you don’t have a shared vision for change, you can’t really expect to collaborate effectively.
- Mutually reinforcing activities. Successful collaborators need to coordinate their activities, play to their strengths, and know their role in the larger effort.
- Continuous communication. If you don’t communicate regularly you can’t hope to build enough trust and shared language to collaborate effectively.
At this point, you’re probably thinking, “Jon, why are you wasting my time with such obvious folderol?” Most coalition efforts I’ve seen fulfill these first three conditions pretty well. Hang in there, it’s the next two that are the most interesting:
- Shared measurement systems. Hmm, now we’re getting somewhere. Collective impact suggests that collaborative efforts need agree on a shared set of indicators of success and the systems for monitoring and reporting on those indicators. Without shared indicators, collaborators have no way to really know if they are succeeding or failing, and no feedback systems that allow them to “course correct” as needed.
- A backbone support organization. Proponents of collective impact assert that successful collaboration efforts need to have a strong, staffed organization at their center, in order to run the collaborative process with sufficient intensity and focus to drive it forward in the face of distractions. It’s not clear to me whether they think a strong “lead coalition partner” fulfills this condition or not. (I suspect not.)
It’s these last two points where most collaborations falter, and probably not concidental that they require sustained, long-term resource commitments. How do collaborations you’re involved with stack up?
Just a quick thought: if Microsoft includes their new hosted Office 365 service as part of their nonprofit donation program, then I think it will be a very, very formidable competitor to Google Apps. InfoWorld has a really nice in-depth review.
Joel Burton, Chris Calloway, Chris Ewing and Chris Rossi (with some remote assistance from Alex Clark and Matthew Wilkes) just wrapped up an insanely productive sprint focused on improving ZopeSkel, the code generator for Plone integrators and developers. At the end of their in-depth write-up, they share some golden “lessons learned” about effective small-group sprinting.
The No-Fun ZopeSkel BBQ Sprint accomplished 23 major tasks in four days primarily by four sprinters.
We are very excited by the productivity and usefulness of the sprint and feel there are some lessons to impart:
There’s a lot of clean-up work left over from this sprint. We could have used an extra day. It would have been wrong to cut short the work being completed on the final day in order to make a second ZopeSkel release in four days. Plus, some clean-up work depends on the outcome of discussions regarding the previously mentioned splitting proposal. Suffice to say, there will be at least a couple of people merging branches into trunk at the Plone Conference 2009 Sprint.
- Smaller sprints are by far more productive.
- Ruthlessly focused sprints are more productive. Having super-clear goals and not wavering from them is key.
- Excluding topics which don’t exactly fit goals is not a bad idea.
- Design discussion and documentation ahead of the sprint make for a more productive sprint.
- Inviting capable sprinters with strong motivations and undivided attention is abolutely necessary.
- Bounties are not all they are cracked up to be. They take a lot of work. There may be easier ways to raise travel expenses.
- A work environment geared towards serious concentration with no interruptions or distractions is extremenly helpful.
- Starting as early as feasible each day and working for about ten hours is most productive.
- A lunch break which involves walking to a location away from the work environment refreshes the afternoon’s work.
- IRC, Twitter, UStream and other open communication channels are distractions while sprinting. Help yourselves before helping others outside the sprint while it is sprint-time. There will be time to help others after the sprint and a sprint which doesn’t produce helps nobody.
- Sprint now, report out later. Blogging is another distraction while sprinting. Help the sprint first.
- Photographing whiteboards is a nice security blanket which doesn’t take much time.
- Have the network set up the day before. Don’t go wireless. Have a high speed switch on a fat pipe.
- Have a couple of nice dinners in the middle of the sprint. Make lunch fun. Eat BBQ every day. Have BBQ on your pizza. People who have fun together work together better.
- Get plenty of sleep. Don’t stay out all night.
- Get the nicest possible accommodations. Private accommodations entirely taken over by the sprinters are best.
- Do not fit three people in the front seat of a pick-up truck.
Previous posts about sprinting:
More Sprint Wisdom
Supporters of long-term social change should not just be providing resources to organizing campaigns. They should also be focusing on helping decisionmakers become more able to hear the messages that social change campaigns are sending.
What good is funding campaigns to send faxes, emails, tweets, phone calls and letters to legislators who are already overwhelmed by unstructured incoming messages? Why not also work on tools to help the legislators track and manage inbound communications more effectively, so that they can actually hear the voice of organized people over the din of organized money?
Why not invest in providing government with the tools to run proper community engagement processes that bridge traditional in-person public meetings with online technologies? This probably requires some interesting innovation in online discussion tools.
Most social change advocates believe fundamentally that government works. Why don’t we systematically invest in helping it transform itself so that it can be more open and responsive to our advocacy?
David Brin, answering Edge’s big question: What have you changed your mind about?, says, somewhat off-topic:
Let me close with a final surprise, that’s more of a disappointment.
I certainly expected that, by now, online tools for conversation, work, collaboration and discourse would have become far more useful, sophisticated and effective than they currently are. I know I’m pretty well alone here, but all the glossy avatars and video and social network sites conceal a trivialization of interaction, dragging it down to the level of single-sentence grunts, flirtation and ROTFL [rolling on the floor laughing], at a time when we need discussion and argument to be more effective than ever.
Indeed, most adults won’t have anything to do with all the wondrous gloss that fills the synchronous online world, preferring by far the older, asynchronous modes, like web sites, email, downloads etc.
This isn’t grouchy old-fart testiness toward the new. In fact, there are dozens of discourse-elevating tools just waiting out there to be born. Everybody is still banging rocks together, while bragging about the colors. Meanwhile, half of the tricks that human beings normally use, in real world conversation, have never even been tried online.
My colleagues and I at ONE/Northwest have been spending a lot of time engaging with an Open Source software development community (the folks who make Plone) over the past two years. It’s been an amazing learning experience.
The following essay summarizes our experiences and attempts to tease out someulearnings both for nonprofits and for Open Source communities
This is a really rough first draft. I invite your thoughts, feedback, questions and criticisms. Tell me what parts (if any) ring true with you. Tell me what to cut. Tell me what I missed, or what I just plain got wrong.