Original Source: 14 Reasons Why Enterprise 2.0 Projects Fail
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.
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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.