A few days ago I posted about a client situation where the CIO had a strong sense of the possibilities and impact that Web 2.0 could have for his organization and the firm as a whole, but the small team he appointed to figure out the specifics quickly fell back on their traditional (and very well-honed) IT competencies. This led to them thinking about:
the business problem to be solved (rather than potential opportunities to surface)
projects to be framed out (rather than experiments to find and stimulate, communities to seed)
- deliverables to be created (rather than behaviors to be fostered)
I’ve been talking with that CIO, and wanted to share some of the suggestions we’ve been discussing.
- Expand the collaboration/innovation team into an experimental “Collaboration/Innovation community” by pulling in people from across the IT organization – try to get some Gen Y’s, people from different levels, and from different groups and geographies. As soon as they feel comfortable, reach beyond IT into the business, customers and partners. Don’t worry about getting the community too big – some people will quickly fall by the wayside – that’s OK – others will engage. Anticipate that 30% will stick with it, so invite 3 times as many as you feel you’d like to have in the experimental community. Make it clear that it’s an experiment. Resist the temptation to call a meeting or set up conference calls. You may need a call or two to get it started, but move as quickly as possible to electronic collaboration.
- Either before step 1, or through step 1, come up with a description of what success with collaboration/innovation would look like. Don’t obsess about metrics – start in terms of behaviors. For example:
- People know how to reach out globally across the company, and do so all the time – to find answers, solve problems, test and share ideas.
- Everyone knows about the latest activities across the company, and contributes to these via the collaboration platform. A variety of special interest communities surface and morph across the company. Some are work related – e.g., community of people with interest in SOA, predictive markets, etc. and these help us more quickly understand, socialize and capitalize on evolving technologies. Others seem to be unconnected to our work – but help people get to know each other, trust each other, and eventually this benefits our work.
- Once you’ve brainstormed a list of behaviors you’d like to see, identify ways these behaviors would benefit the company. Again, this is not about defining “exit criteria” or “project milestones.” This is about helping clarify what we mean by collaboration and innovation – what it would look like and feel like, and how it might benefit the company – to get people excited and involved.
- Find the experiments/examples of collaboration and innovation that are already going on across the company. Apply the appreciative inquiry technique to understand how and why the “experiments” worked/are working – what were the conditions for success? Then look for ways to recreate/expand upon these conditions.
- Identify opportunities for new experiments and ways to seed them. Assume one in ten will succeed, but the ones that don’t are also successes if you can learn from them why they did not work, or perhaps tweak them and try them again.
- Look at web sites such as mystarbucksidead.com and Dell’s ideastorm and see if there are ways this type of approach can work for you.
- Find good opportunities to broaden your use of the collaboration hub with wiki’s, tagging, polling, voting, predictive markets, etc.
- Members of the IT leadership team should be visible modeling the types of behaviors you’d like to see. As a beginning, you should (all or most of the team) become more active bloggers in the company. Try to get to a state where people feel drawn to the collaboration hub on an almost daily basis in order to keep up with what is going on. Perhaps do this against a specific goal of reducing email traffic by 25%.
The specific recommendations here are not really the point – the key point is getting the immediate team to move beyond their typical “IT project” thinking (top down, structured, lots of rigor and formality) to a more emergent, middle out, and unstructured approach to “jiggling the system” (as my hero Jerry Weinberg used to say) and letting stuff happen.