Participation vs. Adoption

These days in the Enterprise 2.0 world everyone talks about adoption.  Adoption is important if you are going to see business results (more to come in future blog post about adoption for adoption’s sake, but I digress).  What I don’t hear many people talking about is how to drive participation in a trial / POC / pilot of an Enterprise 2.0 solution.  Different customers use different terms for what they are doing but I’m going to use the term POC (Proof of Concept) from here on out to describe a small group of people – usually 100-300 people – trying out E2.0 over a finite period of time to see if the technology helps them meet their business goals.  I specifically don’t use the word adoption in the case of a POC.  Adoption implies long-term use and that can’t be implied for a POC.  So I use the word participation.

 

Getting participation during a POC can be a challenge for a number of reasons:

• Users know that a POC may never make it to an enterprise deployment and so they don’t want to do real work there.  They are afraid they will lose any valuable content that gets created.

• A POC is usually conducted in a “sandbox” environment that isn’t tied into any systems in which users do real work.  That means the POC is outside of the flow.  Adoption 101 tells us to keep everything inside the flow so that people don’t have to go to yet another place to get work done.

• Participating in the POC is above and beyond users day jobs.  Finding an extra 10 minutes a day to participate in a community of expertise (especially if they are afraid all of the content may go away) can be difficult and not that rewarding.

• Some users get POC burnout.  Many leading edge types are asked to participate in POCs quite frequently and they just get tired of it (or have too many going at once).

 

Even given those challenges, most experts recommend you run a POC before you invest in an E2.0 solution for your entire organization.  So what’s a person to do?  There are three techniques I have found to work:

• Identify the right participants.  Aim for at least half of your group to be volunteers who are excited about the new solution set and understand the impact it can have on your business.  Remember, a time-limited POC isn’t meant to prove adoption, it’s meant to prove that the technology works for your organization.  If you are dragging participants in who didn’t ask for it they won’t willingly test it for you in their business scenarios (given the challenges above).

• Incentives.  You’d be surprised at the results a $5 Starbucks card can have.  And if you’re only talking about 100 POC users that’s not a big hit on your budget.  Tie the incentive to a test scenario.  The test scenario could have each user build a profile, participate in a discussion, edit a wiki, etc - whatever behavior you are trying to drive.  At one customer they were trying to drive expertise location.  They had very few people filling out profiles but once they offered an incentive the numbers increased significantly.  If your budget is limited or you aren’t able to give financial incentives due to company policy, ask your vendor if they have any swag you could give away. 

• Recognition.  People like to be recognized for their efforts.  Use the components of the E2.0 solution your are testing to highlight the most active users, the people with the most highly-rated content, the community owners with the most active communities, etc.  This way you are recognizing different types of users – creators and editors – they all have value in E2.0.

 

Some of these techniques work for driving adoption of an enterprise deployment as well.  But the challenges of driving participation in a POC are unique and as such there are some unique solutions.  Can you imagine offering a $5 Starbucks card to everyone in an organization of 50,000 people?  Yikes!  Doing as much as you can to guarantee the highest level of participation in a POC is worth it though because the lessons you learn during this POC can be applied when you roll your new E2.0 solution out to the rest of the organization.  Not only should you use this as an opportunity to test out the technology, but use it to start working on your governance, education, and communication models as well.  You may not figure everything out but you can start to get a feel for what works and what doesn’t.  You’ll be glad you did.