Recently, a Twitter conversation regarding the success or likelihood of success of so-called 'Enterprise 2.0' projects made me consider some of the fundamental differences between Enterprise 2.0 and more traditional corporate software project implementations, like ERP.
Traditional
The planning, testing, and prototyping steps are typically quite lengthy, frequently involving many months to even years, but once the 'go-live' date is reached, you have almost 100% adoption rates right away.
If you were to chart traditional ERP project timelines and user adoption levels it would look something like this:
Think of major system implementations for Core HRIS or Accounting. The 'adoption' of these systems is not 'optional' for the vast majority of end users, it is normally an 'all-or-nothing' proposition. The old systems are turned-off, and all users almost simultaneously 'adopt' the new system on Day 1.
Enterprise 2.0
Contrast that timeline to a typical Enterprise 2.0 deployment, where the software tools themselves are dramatically simpler, the time spent planning prior to deployment is usually significantly less, but achieving higher levels of user adoption can be much more difficult and take much longer.
These projects may be internal social networks, blogs, micro-sharing, wikis or idea markets, but commonly they are presented as 'alternatives' to traditional ways of communication and collaboration. Companies, at least initially, rarely 'force' adoption, rather they try to 'build' adoption through training, word of mouth, a visible internal champion, or small pilot programs.
Companies don't get rid of the e-mail or voice mail systems just because a new wiki is available.
Consequently, the length of time required to achieve full or the desired levels of user adoption could actually be longer for these on the surface 'simple' applications. Of course 'time' is not the only important factor to consider in any kind of enterprise implementation, but it is certainly an important component.
These large E2.0 projects are probably not going to be any simpler, faster, and less problematic than traditional projects. But, they will present a whole different set of problems for the organization, the kind of problems that many 'traditional' project managers and organizational leaders may not be prepared to address.
What two or three things can E2.0 project leaders do to try and mitigate these issues?