14 Reasons Why Enterprise 2.0 Projects Fail

14 Reasons Why Enterprise 2.0 Projects Fail

Summary: I’ve been having some very interesting conversations lately about Enterprise 2.0 failures with ZDNet colleague Michael Krigsman. He is doing research for his work on project failures in this area and is trying to understand the reasons why some Enterprise 2.0 initiatives don’t succeed. In preparing for our talk together, I ended up doing quite a bit of my own research and the results, at least for me, surfaced some fascinating stories and insights that are worth examining examining here in detail.

TOPICS: Enterprise 2.0

Creating and nurturing a community is not something at which traditional stakeholders in software projects are often skilled. I've been having some very interesting conversations lately about Enterprise 2.0 failures with ZDNet colleague Michael Krigsman. He is doing research for his work on project failures in this area and is trying to understand the reasons why some Enterprise 2.0 initiatives don't succeed. In preparing for our talk together, I ended up doing quite a bit of my own research and the results, at least for me, surfaced some fascinating stories and insights that are worth examining examining here in detail.

It's a classic adage that we usually learn more from our failures than from our successes. Success itself has a palliative effect that makes one less introspective and over-confident of one's methods. It obscures the feedback loops needed to really understand what worked and what didn't. When you succeed at something, clearly what you did was effective, but you can never quite be as sure what it was as when something doesn't work out. I've find this line of reasoning with Enterprise 2.0 failures to be fascinating because of how very different it's often turning out to be from traditional IT projects.

For one, IT doesn't seem to be in the driver's seat nearly as much with Enterprise 2.0. In fact, the initiative is frequently coming from the business side. Two, as the latest case studies emerge and are analyzed, it is grassroots efforts that often end up being the most successful, bubbling up and then across the organization, only then to be formally adopted later. And three, many so-called Enterprise 2.0 projects are local, unblessed, informal uses of social computing software which -- by their very nature -- are less compliant with enterprise technology standards, legal/HR guidelines, and corporate policy. So, at least on its face, this seems to mean Enterprise 2.0 projects are more likely to fail due to seeming larger than usual lack of alignment and organizational backing.

Enterprise 2.0 Success Pattern: When Bottom-up Meets Top-Down

Intriguingly, that this is a bad thing is quite debatable in the case of Enterprise 2.0. In an ideal world, you'd like to see projects that aren't successful fail quickly and not consume a huge investment of time and money before you discover that they aren't going to produce value. The mantra here is "fail fast and often" and then look for the ones that don't. Just as interesting, the projects that break the rules, can often break the right rules; the ones that were going to hold back the more structured and official efforts anyway. The point here is that many Enterprise 2.0 tools are often used widely in organizations without tacit approval.

Venture Model + Rogue IT = Enterprise 2.0 Success?

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.

Topic: Enterprise 2.0

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.


Log in or register to join the discussion
  • Really?

    Seems to me you could replace "Enterprise 2.0" with nearly any major IT initiative and this would be a sound piece. So what does it specifically say about Enterprise 2.0 failures?

    Where are the more specific issues around failure to provide mechanisms for people to 'find' each other, or integrating directly with where people already 'are'?

    Try again.
    • Shift of emphasis

      Projects of every type fail due to issues that arise when people collaborate. Agendas, information silos, politics and so on are part of every sphere of collaboration.

      From that standpoint, there's nothing new under the sun here. At the same time, the specific mechanisms in how these problems manifest does change.

      I think Dion did an admirable job, and has set the bar high, in identifying how those issues get expressed in the E20 context.

    • Some of these are certainly E2.0 specific failures

      Hi Paula,

      I think if you'll read #1, #8, #10, #12, and #14 they are aspects of 2.0 tools and pull-based systems that generally aren't true of top-down major IT initiatives.

      And the other more general causes are important to appreciate as well and shouldn't be left out, particularly since they often have a unique twist with E2.0.


      Dion Hinchcliffe
      • Really? Part Deux

        1. Department Bound...KM, Data Warehousing...
        8. Generic vs. specific. I'd contend that it's both. If you do the latter you'll fail as well.
        10. Lack of Effective Participants: Flawed design -- if they have to come to you...you're not DOING 2.0
        12. Draw Influencers: Ditto 10
        14. Not Waiting Long Enough: Ditto 10

        Are you sure you understand E2.0?
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

    Very good article Dion. I wrote something similar (with another angle on implementing Intranet 2.0) and posted it to scribd. They key seems to be Executive sponsorship with buy in from all levels. Further a defined process that everyone is bought into. Lastly, have something of mission critical value in the system that every stakeholder needs in order to do his/her job.
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

    To be honest, I think these are pretty broad and apply to
    most IT projects. Aside from the generic factors, I would
    challenge the idea that there is a set of common failures
    that we can boil down to.

    I think we also have to acknowledge another factor, which
    is a lack of long-term commitment from consultants and
    vendors who push E2.0. To really succeed and be
    impactful can take 3-5 years. How many of us can say that
    we have the patience to stick with projects for that long to
    see them through?

    I enjoyed your workshop at E2.0 Boston. Good stuff. But
    on the whole, I think we all need to write less and do more
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

    A lack of awareness of what Enterprise 2.0 is and what it can do for the organisation - education is key
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

    An awareness of what Enterprise 2.0 is and what it can do for business - education and localising its benefits are key and very often missing.
    • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

      @schmediachick <br><br>Although I agree with you here, EP 2.0 has a lot of key aspects <img border="0" src="http://www.cnet.com/i/mb/emoticons/happy.gif" alt="happy">

      <a href="http://www.sinemafilmizle.com" title="Film izle">Film izle</a>
      <a href="http://www.sinemafilmizle.com/eyvah-eyvah-2-izle-sinema-film-izle.html" title="Eyvah Eyvah 2 izle">Eyvah Eyvah 2 izle</a>
      <a href="http://www.sinemafilmizle.com/recep-ivedik-3-izle-full.html" title="Recep ivedik 3 izle">Recep ivedik 3 izle</a>
      <a href="http://www.sinemafilmizle.com/yahsi-bati-film-izle.html" title="Yahsi BATI izle">Yahsi BATI izle</a>
      <a href="http://www.sinemafilmizle.com/avatar-izle-turkce-dublaj.html" title="Avatar izle">Avatar izle</a>
  • 15. Inventing problems.

    15. Inventing problems.

    Sometimes when you have a hammer, everything looks like a nail, and sometimes when things look cool you want to use them even if they do little to help you.

    Determine first that you really need one of these fancy "**** 2.0" projects before starting one.

    Remember: ZDNet is all about this kind of stuff, so yes, they are heavily biased for it, often at the expense of everything else. The past year or two they have especially been treating everything like nails because they have a "web 2.0" hammer.
  • Top reasons ....

    - Incompetent managers/leads
    - Unreasonable schedules
    - Unrealistic dynamic requirements

    But that is not limited to E2.0. It is basically the problem of ANY project.
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail


    A very nice, succinct article. Many of your points gel with those given in AIIM's E2.0 Specialist course (which I'm just rounding off).
    In your introduction you state "Creating and nurturing a community is not something at which traditional stakeholders in software projects are often skilled." The lack of this compentency is, I think, a core problem. The point is exactly that implementation of e2.0 needs the social skills to create and sustain community. That requires that the core team include people who know how to foster this, and make the link between the technology, community, and the business goals involved."
    • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

      @Russ_h <br><br>Hi Dion, I've just re-read this article and agree with the 8 core patterns - have things changed since 2006? <a href="http://www.arabaoyunlarimiz.gen.tr/spor-oyunlari/">spor oyunlari</a> <a href="http://www.arabaoyunlarimiz.gen.tr/yapboz-oyunlari/">yapboz oyunlari</a>
  • Why we rouge developers exist.

    Here is the real stupid simple reason that projects fail. The managers make their decisions after hours while drunk on booze purchased by a smooth talking contractor. The contractor then sells the agency/company useless expensive project management software and then builds a team of contract employees who burn up the development money arguing what color and font topic headers should be. Later some rouge like me does the job.
  • Why you have rouge developers!

    Here is the real stupid simple reason that projects fail. The managers make their decisions after hours while drunk on booze purchased by a smooth talking contractor. The contractor then sells the agency/company useless expensive project management software and then builds a team of contract employees who burn up the development money arguing what color and font topic headers should be. Later some rouge like me does the job.
  • Perhaps Enterprise 2.0 Is Not An App

    Possible take away.

    Centralized Enterprise 2.0 implementations break the
    fundamental rules of having E2 success.

    1. They are centralized
    2. They are pre-selected
    3. They lack flexibility

    Potential Solution:

    Common data interchange standards that allow teams to
    use whatever app they want / need. Just make sure data
    flows where it should and when it should.

    We will come to find that applications will be as
    important and as disposable as pens.
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

    "Pushing Enterprise 2.0 as a generic toolbox instead of
    the solution to specific problems." - agree completely.
  • 8 Tips for a Successful Enterprise 2.0 Pilot

    Dion, I thought your 14 reasons were bang on. I'm going to provide them to our potential customers who are running pilots. And, as a contrast, I put together 8 tips for a _successful_ enterprise 2.0 pilot: http://bit.ly/8E2PilotTips
  • Where to start?

    I'm suffering primarily from #5 (purely an IT initiative), with significant amounts of #9 (no champion). If we were attempting to do something 'social' with SharePoint, then I'd also have #10 (no effective participants) and #11 (no long term plan), but at this point I'm sticking with the non-social collaborative uses (if there is such a thing).

    One of the company's two sites is project oriented, all salaried employees, most of whom have engineering or tech backgrounds, and also hosts corporate HQ. My site is manufacturing oriented, with few 'super users, 'tech heads', or 'geeks'. While the other site seems to be having success with SP, I have no idea how to get it off the ground here. I'm beginning to suspect it's a solution with no problem, at least as far as this site goes. Or maybe I'm just not familiar enough with it to know where to apply it.

    I have no 'social networking' experience, and neither I nor any of my on-site co-workers have worked with any collaboration tools before. My few attempts at social tools (mostly blogging, LinkedIn, and Twitter) show me I have nothing to say and can't find anyone I consider worth reading / following. I've send a couple of e-mails describing SP capabilities to my 150 users but received absolutely no reply. I suspect most of them wouldn't know a blog or wiki if they stepped in it, and I don't know how to get value from them. I've run my concerns past my departmental superiors (all at the other site) but I've received no response. Maybe they can't believe I'm serious?

    How can I tell if there's a need for SP? How can better solicit / involve my users?
  • RE: 14 Reasons Why Enterprise 2.0 Projects Fail

    I think the main reason is poor integration. The so-called
    social networking function of our information management
    systems should be the artifact, not the aspect. We need a
    shared project model the encapsulates a great deal more
    semantic information about what we're talking about, to
    whom it's addressed, what it's regarding, how it connects
    to everything else, etc., so that we're freed from having too
    much concern for what we say where.

    Suppose we had a URI for every concept, word, idea,
    dream, etc. As we write, software is automatically parsing
    our sentences and mapping the tokens into these URIs.
    When we've finished we can check the mapping to ensure
    we're saying what we meant. In this way anything we write
    anywhere on the web, even email, could be protected
    merely by protecting the URIs it referenced.