Around a week or so ago I presented online at the social business summit on making Enterprise 2.0 work. It was a relatively short presentation with a lot of information but one of the things I presented was a type of framework or process for how to make Enterprise 2.0 work within an organization. I’m currently in the process of conducting a large scale E2.0 project but I have been doing some in depth case studies and interviews with companies such as Intuit, Vistaprint, Oce, Florida Hospital, and Booz Allen Hamilton (which will be finalized and live within a few weeks). What I created is based off of the information I have been collecting from various companies (and a bit of research). Of course it’s not applicable to every organization and I still think there is room for improvement and modification but here is what I have so far:
Let’s walk through this starting at the top with “business challenges.”
Business challenges
This should be common sense right? Start with the business challenges you are looking to solve and then go from there. However, many companies are starting off with technology solutions and are then trying to “make E2.0 work” by wrapping a problem or a strategy around a technology; which is really not the way to go. Organizations really need to take a look at and understand the challenges they are looking to solve before doing anything else. I’ve also seen organizations go with technology solutions offered by partners and so there is little or no cost associated with the actual platform, again I see this as a mistake. Getting something that you don’t need for free is going to cost you in the long run. Tool selection is only 4th in the overall process, not first.
Requirements and use cases
Requirements need to be looked at from both a business and a technology standpoint which is why it is important to have both IT and business units working together. Technology requirements really need to be thought through especially if looking to proceed with a paid enterprise solution. For example do you want open source or proprietary? Do you have the resources in place to manage the technology or do you need to hire an agency/team to do that for you? What about integration points with other platforms such as Sharepoint (or other)? Business challenges look at everything from manpower resources to getting senior level management support of the initiative. Most organizations will have varying requirements for both IT and business units. Finally we need to look at use cases. Most organizations have various departments so how is each department going to use whatever it is you are deploying? Does everyone get equal access to data and features? This needs to be broken down.
Culture challenges
Chances are that you are already quite familiar with your corporate culture (since you work there) so this is the time to take a real hard look at what that culture really looks like at a more granular level. Is openness frowned upon? Are employees perceived as being weak if they publicly ask questions (as in the case with Oce)? Every organization is obviously going to have it’s own cultural challenges (which can also be due simply to the geographic location, Betrand Duperrin highlighted some French specific challenges and also looked at why prediction markets have no success in France). Understanding the corporate culture from the get-go will allow you to craft strategies around how to deal with overcoming culture challenges (in the case of Oce it was “lead by example”).
Tool selection
Now you can finally start to look at what tools or platforms you should deploy within your organization. Once you have a solid understanding of all of the above you will know whether you should go with a paid platform, a free platform, open source, etc. Your requirements and use cases will be mapped out and you need to make sure that you select the tools that meet the requirements you have specified above. Not doing this can result in more money spent than necessary as you are going to be paying for something you don’t need and will most likely incur extra expenses from shifting platforms or customization.
Pilot program
I know Andrew McAfee preaches that we drop the pilot program altogether but most of the companies I have been speaking with have had some sort of a pilot program in place whether it’s employees experimenting or a more formal “trial.” I see a valid case for both broad deployment and for pilot programs, understanding all of the above will probably give you a very good indication of the type of deployment you should be going after.
Lessons learned
Pilot programs provide quite a good amount of “lessons learned,” these learnings then need to be applied to the enterprise as a whole if you are looking at a broader launch. For example if employees had a difficult time understanding how to use a technology solution then you might want to incorporate training programs for the broader launch. If employees felt uncomfortable sharing too much information then you might want to address this concern during a broader launch and create options and controls for what is shared and how. Again, every organization is going to have it’s own learnings that it can apply to the broader launch.
Broader launch
Now is when you get to introduce your entire organization to the new E2.0 initiatives. Large scale launches obviously need to be very carefully orchestrated to make sure that everyone is aware of the changes that are taking place and why. Simply throwing a tool into the organization isn’t a good way to launch anything. A broader adoption plan should be created that will address how the launch with take place and what sort of milestones need to be reached along the way.
Adoption
This part for me is a lot of fun (yes really) because it requires a very strategic and creative approach. Adoption strategies (from the companies I have been speaking with) include anything from highlighting and promoting positive behavior to creating incentives for employees to including collaboration as an employee performance metric to providing scheduled training sessions for all employees. As with the above the adoption strategies are going to be tailored specifically to each organization and success might not be achieved after a first attempt.
This brings us back full circle to (new) business challenges that we are looking to solve. It’s an iterative process that should never end as your organization continues to grow and evolve. Again, this is what I have been seeing from the organizations I have been speaking with. What do you think, does this make sense? Do you see areas for change or improvement? I’d love to hear your thoughts so please share them in the comments section.
