Are You Ready for Social Software?By Baselinemag | Posted 2008-02-21 Email Print
You may be surprised to learn that workers have radically different notions of what should and shouldn’t be made public.
Enterprise 2.0 implementations challenge the policies and practices of any organization, on both the business and technology sides. Hierarchal and bureaucratic companies are at a disadvantage when it comes to deploying flexible, minimally structured software tools, but there are ways to mitigate that disadvantage. With the help of social software analysts, consultants and corporate experts, Baseline has compiled a list of best practices to make the deployment of your next (or first) social software application a success.
ON THE BUSINESS SIDE:
Allow for spontaneity and personal initiative. You never know who might have the next great idea to trounce your competition. Senior executives need to listen and respond to what employees at all levels have to say. If you want Web 2.0 applications to help facilitate decision-making, consider imitating Google, regularly cited as a company that values employees’ ideas and feedback.
Encourage collective responsibility. If your company is focused on individual contributions, be prepared for an uphill battle: The success of applications like social bookmarking and wikis depends on group participation, so if performance reviews don’t factor in team-building skills, workers may not leave the cozy confines of e-mail.
Get ready to relinquish control of some content, standards and people. You may be surprised to learn that workers have radically different notions of what should and shouldn’t be made public. And while perspectives on what constitutes a reliable research source may seem dubious, it’s important to keep a cool head and start creating content management policies to address such concerns.
Don’t force adoption. Unlike more mundane enterprise software projects, adoption of collaborative software tools hinges on creating a positive experience for users. If the application meets a need and is easy to use, you won’t have to get heavy-handed. If there is resistance from a few, give it time for them to adjust.
Count on failure. You’ll hear of Enterprise 2.0 successes in other companies and maybe even in your own, but you can bank on some project flops. It may take time to match the right tool and work process, but as long as you approach each project as an experiment to better understand how people interact using the software, you’ll gain insight for the next project.
Identify explicit and measurable performance indicators. Whether it’s cost savings, storage space saved or improved call-completion times, know the intended benefits of your project prior to deployment. There will always be some that are tough to capture or quantify, such as improved rates of knowledge transfer or more robust training documents. That’s okay, as long as you have enough evidence to make the case for the next round of funding.
ON THE TECHNOLOGY SIDE:
Be willing to go beyond conventional vendors. While enterprise software vendors like IBM and Microsoft are starting to make inroads in social computing, it’s still easier for small, focused software creators like Media Wiki or Ning, an online community application, to change and evolve. Don’t commit too quickly to an expensive suite before you rule out other less obvious options.
Deploy only easy-to-use applications. Andrew McAfee, the Harvard Business School professor who coined the term “Enterprise 2.0,” recommends avoiding all but “deadly easy” software, because even when software adoption is voluntary, he says, complexity is a killer. If you suspect that an application might confuse users, you can bet it will.
Give software structures time to emerge. Impose too much formality up front and you’ll defeat the purpose of your new tools, which are designed to ebb and flow with the quirks and habits of different groups. What works in marketing may not work in R&D, so let each team use the software and then tell you what it needs.
Stick around after rollout. Your company’s technology staff may normally move on to the next project while the one they just finished is rolling out. But with emergent technologies, it’s critical that tech staffers stay in touch with users to see what works, what doesn’t and which features could improve the experience.
Experiment often and assess rapidly. Social software tools tend to be inexpensive and easy to deploy, so be sure to have many pilots in the works and don’t be overly cautious about pulling the plug. If you have a test environment that reflects the larger pool of potential users, a month to six weeks of usage data is typically all you need to make a decision.
Understand the choreography of work. Until recently, software developers have been directed to focus on how people interact with their work. New communication and collaboration tools emphasize how people interact with each other, in relation to the work. Understanding the latter is a new skill for many IT workers and developers—one that requires close observation and keen listening abilities. Be prepared to provide additional training.
Sources: Tom Davenport, Babson College; Nikos Drakos, Gartner; Mike Gotta, Burton Group; Andrew McAfee, Harvard Business School; Joe Schueller, Procter & Gamble; Euan Semple, social software consultant.