How (Not) To Fail

Euan Semple breaks with tradition with a Top 8 list rather than a Top 10, and by explaining Most Companies Who Try to do Enterprise 2.0 will Fail (worst practices) vs. why they will succeed (best practices). From both sides of the IT fence (as a consultant and sales person at a VAR, an operations manager and product manager at a global content delivery service, and in marketing and consulting roles here at Traction Software) I've seen my share of internal failures and customer or prospect failures too. I've commented here on 3 of Euan's Top 8.

Euan's Reason #1 - They think it is about technology

There are two sides to this point.

On one hand, I've seen IT groups buzz like moths to light - thinking that what they see on the net is what they need in the enterprise. Circa 2005, I heard from Enterprise IT groups who came out with "We are deploying blogs" as a mission and requirement. Most of these efforts failed. Circa now, "Social Networking" is the mission.

These approaches will meet the same failures of file sharing focused collaborative workspaces. The problem is two-fold:

1. Meeting the lowest common denominator requirement meets nobody's full requirement and
2. Without a business context and process for using technology (however informal), as well as the human aspects behind gaining adoption and consistent use, the technology will sit idle.
   

On the other hand, every time I've seen the focus on the technology comingle with a focus on a business problem, Enterprise 2.0 projects have succeeded. From Suw Charman's Dark Blogs Case Study 1 - European Pharma Group and Michael Angeles' Lucent Technologies Case Study in 2005 to my case studies about ShoreBank in 2006 and NHS in 2007, technology as a key ingredient is a common thread. In all of these cases, the technology was brought in to solve a particular problem, rather than as an Enterprise offered "feature" or "service" for the intranet.

• In the Dark Blogs story - the e-mail digest was one of many facilities that made the system serve a Competitive Intelligence distribution need.
• At Lucent - the ability to add a custom interface and build nice Question forms were key to supporting a world-wide community learning a new ERP system.
• At ShoreBank, the ability to query across requirements, open To Dos, issues and questions helped organize blog and wiki style information flows around milestones.
• At NHS, the ability to include Twitter updates in a user profile was helpful to a hard-to-find IT admin.

These use cases show how technology, planning and people come together to make E 2.0 succeed.

Euan's Reason #3 - They will assimilate it into business as usual

I think that the issue brought here by Euan is that the E2.0 technology and its program will be managed like any other system deployed in the enterprise. The issue being that its not so simple as selecting a technology, deploying it, organizing a training session and then just letting it run.

Enterprise 2.0 projects may involve less technology and cost than ERP projects, but (in some but not all cases) require more human care and feeding than other IT infrastructure that puts itself in the middle of a process (and, therefore, demands use).

There is a "business as usual" case to be made for Enterprise 2.0, however. Whether planned or emergent (or both), the business need and process for using the technology has to be understood at some level.

Phil Grove of Computer Sciences Corporation (CSC) framed the issue nicely at our Traction User Group in 2007 by describing the challenge most users encounter when they face a "Blank White Page" in a wiki system. He was referring to the need for templates for common page types (meeting notes) as well as frameworks for teamwork (this comment, in part, led us to add Template support in Traction Sections - so you can click ADD on a meeting note section in order to load a new article publisher with a meeting note template already loaded.).

In my Yin-Yang of E2.0 post I discuss in more detail how E2.0 technology becomes valuable and earns fast adoption with a some structure and context in business process, along with creative collaborative chaos required to flex with a team's or individual's needs.

Euan's Reason #7 - Lack of patience

Bravo! Ask me "how long is your sales cycle?" and I will tell you "2 years, 2 months or 2 weeks." The issue is not whether the Enterprise 2.0 project is needed or how urgently, its when a person or team has an available work-cycle to do something about it.

Once E2.0 services are deployed, "Follow the Leader" adoption models tend to outperform "Build it and they Will Come" adoption models. The Leader (a team on a project or program, a community, a business function) first has to try, learn, shift course and then succeed. This could take weeks, months or a year. Then the Followers have to free up work-cycles before reviewing the Leader's best practices (structure), adapt to their own needs (emergence), and cut over their own communication and collaboration processes to the Enterprise 2.0 platform.

This industry has had an idea about Enterprise Blogs and wikis since at least 6 years ago when Jon Udell wrote Traction's enterprise weblog gets a grip on corporate KM for InfoWorld, yet blog and wiki tools are only now becoming commonly accepted and deployed in enterprises across the world. Another few months or a year to see adoption in a given enterprise is hardly a long wait.

If there is one resource that IT, KM Managers and other E2.0 stakeholders need a lot of, its patience.