14 Reasons Why Enterprise 2.0 Projects Fail

In other words, people are just grabbing tools off the Web and putting them to work, drawing their co-workers in as they begin to use them. As we saw this year, most organizations now have the tools of Enterprise 2.0: blogs, wikis, and social networks and the workers have access to them. The amount of rogue IT that actually takes place varies widely by organization, but seems to be on the rise particularly with social tools. Access to them is very easy via the Internet and I hear frequently now from organizations that this is happening.

Most of these smaller, on-the-ground, often under-funded Enterprise 2.0 efforts will fail to thrive for whatever reasons. These are useful experiments but they were missing one or more ingredients to succeed. But occasionally some of them will hit on the right formula, reach a critical mass of participation, break out of their team or department, and begin drawing in the rest of the organization. This happened at AOL with AOL Office Wiki, at the CIA with Intellipedia, and with most of the successes in Jakob Nielsen's recent meta study on Enterprise 2.0 successes.

At this point the organization then has to decide whether to get behind and build upon the rapidly growing network effect, or box it and try to replicate what was done. As I said to Michael Krigsman during our conversations -- and because of the likelihood of bottom-up adoption -- the smart strategy now appears to be to find and build upon the early successes stories; namely the internal but local efforts that are rising and have already hit upon the right mix of tools, participants, motivation, and content.

As I looked over our case studies and lessons learned on Enterprise 2.0 efforts that didn't quite go as hoped, there also seems to be two broad categories of failure. The first are the classical reasons any IT project can fail. Unsurprisingly, Enterprise 2.0 projects seem susceptible to most of them. Second are causes that are unique to emergent, grassroots adoption. Across these two areas, I've tried to tease apart all of the data, stories, and cases currently available to arrive at this set of common reasons why Enterprise 2.0 projects sometimes fail.

Read The nine worst social media failures of 2009 by Jennifer Leggio.

Again, I'll re-emphasize, failure isn't always a bad thing, it's often essential. And in the case of enterprise social computing, tolerance of failure is seemingly an excellent way to let a thousand flowers bloom and grow and then see which ones thrive.

14 Reasons Why Enterprise 2.0 Projects Fail

Please note that some of these reasons can still be true of successful enterprise social computing projects if they have other, positive factors that more than offset them. In general however, the more of these that are true, the more likely failure will be.

1. It starts strong in a single department and then never makes it out. An effective community or environment may start to build at a departmental level but its culture, work focus, or perspective may not be appealing to the organization at large. Consequently, there's no broad appeal and while the Enterprise 2.0 effort may even be highly successful locally, it's not one that will spread across the organization. A significant number of Enterprise 2.0 efforts end up in this category. Pro-active community management efforts might be able to mitigate this factor.
2. Selecting the tools first. As I emphasized in my latest survey of the Enterprise 2.0 software market, the needs of the social computing strategy come first, and then a tool should be selected to match. What a tool is capable of and what its core strengths are will have a direct and dramatic impact on what you can achieve. Right now, SharePoint remains the dominant tool by far for Enterprise 2.0 today, largely because it's already on hand in most organizations. A small but significant number of Enterprise 2.0 projects, however, languish because the users have to fight the software to get it to do what they want. Look at any default solution with some skepticism.
3. Selecting the wrong tools and sticking with them. Successful projects make needed course corrections and change what they do based on what they've learned from experience. Agile processes in recent years have encouraging revisiting important decisions until they are the correct ones. Because of the way software acquisition typically works in most organizations (and the length of time it takes), it's often hard to revisit the tool decision in any meaningful way, even if important lessons are learned and better solutions found in the meantime. Consequently, it's wise to try to delay final product decisions and avoid over-committing to individual solutions until your collaborative community is thriving and actively getting value from their Enterprise 2.0 environment.
4. There are no resources allocated to adoption and training. Most users never read the manual, whatever the software is. But this is particularly true of today's supposedly easy to use browser-based applications. However a little evangelism and social media literacy can greatly help with both adoption incentives and good business outcomes. Understanding what tags are and how they help users locate content later on, publishing frequently requested information in blogs, teaching that wiki editing is safe and that it's virtually impossible to harm them are all key learnings that many less-social media literate workers will greatly benefit from and can actively address many upfront barriers to adoption.
5. It's purely an IT initiative. When there is not enough involvement by business stakeholders, any IT project will be at risk. But since Enterprise 2.0 essentially embodies participation by the business, this situation is invariable fatal.
6. The effort excludes IT. I've seen Enterprise 2.0 project delayed for six months and even much longer in some cases whereupon IT is subsequently involved and begins doing infrastructure planning, tool validation, staffing, and playing catch up on the learning curve. It is one of the most common causes of major delay, if not outright failure.
7. Engaging with HR, legal, branding, compliance, etc. too soon. It's extraordinarily easy to create a bureaucratic logjam when you involve all the potential stakeholders of Enterprise 2.0, particularly ones the aforementioned ones. An entire effort can be buried in committee and planning forever, while policies and procedures are formulated. Clamp downs on the project while major, strategic issues are sorted out in great detail are not uncommon. While I'm certainly not advocating going completely rogue, many successful initiatives flew under the organization's radar long enough to be able to achieve focus on what mattered most: better collaboration and knowledge sharing. Only then did they engage, often sequentially, with the various internal groups to make sure governance details were eventually worked out.
8. Pushing Enterprise 2.0 as a generic toolbox instead of the solution to specific problems. One of the big lessons for rapid adoption is that having an unsolved problem or specific situation to address is one of the fastest ways to get directed uptake. That's when users know exactly when and why to use a given approach. When users have to decide on their own when to use all the communication tools at their disposal, systematic uptake is less likely and will take longer. Successful initiatives often have specific situations in mind that they believe an Enterprise 2.0 approach will resolve.
9. Lack of effective executive champions. This is a classic cause of failure for any project. The only real difference here is that it's even more effective when at least one well-regarded executive actively participates not just in the project but socially in the online community itself. That kind of visible championing, in addition to budget or buy-in, is highly effective on the ground once participation is under way.
10. Lack of effective participants: Empty blogs, wikis, or silent social networks. If there's nothing there, then no one will come. Seeding content, hand-picking early participants, and other strategies to build critical mass can ensure there is enough activity taking place and knowledge accumulating that it will draw in a self-sustaining audience.
11. No long term plan or budget for governance, community management, upgrades, or maintenance. Communities are very different creatures from software projects, but both are required to make Enterprise 2.0 failure. This requires a long-term view and understanding of the investment and often unexpected skills (hiring community managers for example) required to keep it healthy and successful.
12. Failure to draw in key influencers as adoption broadens. This has been a notable lesson early on, that the official gatekeepers and organizational leaders have to be engaged and not usurped by a successful and rapidly growing Enterprise 2.0-style community and knowledge base. Parts of an organization that may already be responsible for maintaining certain types of information or being the officially designated experts for certain subject matter may co-opt or request control of what's taking place, often to assimilate and/or reduce perceived duplication. Organizations will have to begin looking at this phenomenon as a spontaneous re-engineering effort and decide how to create an effective reconciliation between the conflicting entities.
13. Building it all as a self-contained, top-down effort. As we saw from the Nielsen research, this is a key lesson. Finding (or encouraging) an Enterprise 2.0 success story is often a better approach than doing it all yourself and avoiding not-invented-here syndrome.
14. Not waiting long enough to let critical mass build. Sometimes it takes a while for an organization to change its habits, to learn the tools, and understand how to get value from them. Some efforts have taken 6 months to a year before serious critical mass began to build. In the interim community management staff can experiment and find the right way to motivate and draw in participants.

There are a lot reasons why any project won't succeed. Enterprise 2.0 is unique, however, in the respect that there is virtually no technology risk but there is much higher risk when it comes to people and organizational issues. Social computing in the enterprise is most successful when there is a healthy community with moderate levels of dysfunction at most. Creating and nurturing a community and keeping it thriving is not something that a project plan alone can achieve or that the traditional stakeholders in software projects are often skilled at. It takes diligence, patience, engagement, emotional intelligence, and understanding of the needs and motivations of participants to be successful for the long term.

I'm also hoping Michael Krigsman, himself a well-known expert in software project failure, will chime in from his own research. In this way we can identify the most common sources of potential challenges in Enterprise 2.0 projects and proactively address them.

What other key reasons that Enterprise 2.0 project might fail. Please add them in Talkback below.