I began pulling my ideas for this post together by seeking a simple definition of the word adoption. There wasn't a single definition that conveyed the scope I was looking for. It's a common issue with English. A single word with many meanings reflecting a variety of professional or personal scenarios. To some adoption means accepting a new software, processes or ideas. To others it's simply general acceptance with 'approval'. To others still it's gobbling up a whole religion or accepting an unrelated child into a family. In the E2.0 trenches? I'm guessing any of those definitions might sound familiar (metaphorically of course). So with a word that can evoke such varied responses, what measuring stick reflects the truest of realities? What does it mean to say you have xx% adoption?
I believe there is no single metric which reveals absolute adoption, moreover that only your organization can define adoption in a way that's meaningful and further, that the acceptance of those adoption measures will vary across an organizations internal cultural spectrum. Stakeholders want numbers. They want those numbers to climb or fall over time to reflect a wise choice; that the horse they opted to back is yielding the purse they expect. It makes perfect sense. Despite the continued din of conversation for or against traditional ROI applied to E2.0, those of us on the ground will have to offer indicators and analysis. The simplest answer is to focus on the goals stated when you sold the business plan in the first place. Measure the problems you were trying to solve. Your job is to make sure the selected measures reflect reality, are viable in the long term, and not so narrow that they hobble your ability to be agile as you evolve. Much of the work that's being done in E2.0 is the stewarding of new ideas and evolving norms to the organizational world. It's important as a practitioner to know what's working, and what's not. That last bit is key. Knowing which aspects of your project need promotion, clarification, modification, or education will keep you from blindly throwing darts at a target. In a nutshell, analyze often and resist the urge to believe your own press releases. Adoption can be a fuzzy thing. It's important that you build a common definition of adoption within your organization. Does it mean logins, contribution (posts, updates, edits, comments), does it mean 'wins' that can be attributed to your project, and your project alone, or is it some other established success indicator? You have to define these factors explicitly. Like any number of rethinks that you'll encounter, you need to think new when it comes to the metrics you need. Page hits and logins might not reflect the true story. Think back to the problem you're solving and ask "Why are we doing this? How can we make it better, and how can we measure 'better'?". There are a number of creative ideas around RO_ (return on collaboration, adoption, networking... etc.) These ideas are a important to consider as you gain a sense of scope. They are perfect examples of the kind of flexibility you'll need maintain agility. Though it seems the text books are still being written, there are a handful of folks who've got very solid ideas about ROI as it relates to E2.0, though much of the conversation is happening well above the tactical level, or speaks to specific case studies that may not resonate with your project. Dion Hinchcliffe (as always) does a great job of creating clarity around the discussion. I count his posts/presentations as the right place to start. You can, and really must, create an RO_ which is supported with adoption metrics that reflect the realities of your space. With research and a solid understanding of your goals and culture, you'll be off to a great start. Have you tackled it adoption measures for your organization already? Are you tackling it right now? I'd love to hear how others have approached it. Thanks for reading.