14 Reasons Why Enterprise 2.0 Projects Fail versus 4 Rules of Thumb


Well known for his thoughtful analysis (and pretty diagrams) about the two dot oh domain, Dion Hinchcliffe has proposed 14 reasons why Enterprise 2.0 projects fail:

  1. It starts strong in a single department and then never makes it out;
  2. Selecting the tools first;
  3. Selecting the wrong tools and sticking with them;
  4. There are no resources allocated to adoption and training;
  5. It’s purely an IT initiative;
  6. The effort excludes IT;
  7. Engaging with HR, legal, branding, compliance, etc. too soon;
  8. Pushing Enterprise 2.0 as a generic toolbox instead of the solution to specific problems;
  9. Lack of effective executive champions;
  10. Lack of effective participants: Empty blogs, wikis, or silent social networks;
  11. No long term plan or budget for governance, community management, upgrades, or maintenance;
  12. Failure to draw in key influencers as adoption broadens;
  13. Building it all as a self-contained, top-down effort; and
  14. Not waiting long enough to let critical mass build.

I’ve read through this list a few times now, trying to tease out some new or special factor that is specific to Enterprise 2.0 projects, but I just can’t see it. While these issues might be considered uncommon in certain types of IT projects, they are very common in projects that affect the areas of individual work practices that people have discretion over. We have seen these problems for years – but now the label has changed from “knowledge management” or “collaboration” to “Enterprise 2.0”.

Unfortunately many companies have a bad track record in how they have introduced groupware and collaboration tools in the past – social computing technology alone is unlikely to change that (and hence the Enterprise 2.0 technology and culture debate, although its more than just culture too).

I looked at Social Software back in 2005 for a NSW KM Forum presentation and commented then on the difference between old groupware and collaboration solutions with social software (see slide 6). I think it is important to consider what has changed:

  • The technologies of Enterprise 2.0 exhibit different characteristics from those we had in the past; and
  • In addition, there is growing population of workers who are familiar with these technologies based on their experiences of using the Web.

If we understand this, then we have a chance to avoid past mistakes. In my view there are four key rules of thumb for avoiding Enterprise 2.0 project failure:

  • Use real social computing platforms – because they are more cost effective, offer flexibility, have ‘social’ built-in, and are user-driven;
  • Take an abundance approach to the technology – the traditional model of IT is a scarcity mindset that tries to avoid wastage (failure is a wastage), but an abundance approach will allow you to grow organically and support experimentation.
  • Put the ‘users’ in the driving seat – this really is the point of Enterprise 2.0 and if you have already followed the first two rules of thumb, you should have the tools that let you do this.
  • Tap into your pool of early adopters – getting momentum quickly is always important, but you can use the fact that some people in your organisation may already be ‘Enterprise 2.0 ready’.

Mix these up with Dion’s list and we might start to get somewhere with understanding why Enterprise 2.0 projects might fail.

5 thoughts on “14 Reasons Why Enterprise 2.0 Projects Fail versus 4 Rules of Thumb

  1. Hey James. Excellent additions. What you’ve suggested here is key to what many our members are reporting as early successes.

  2. I particularly like point – Tap into your pool of early adopters. Finding these e2.0 champions is critical to getting quick wins & showing the rest of the Organisation “how-to”.

Comments are closed.