Three posts about 'failure' in the 'Enterprise 2.0' space in the last few days from Sameer Patel ('Five ways to avoid Enterprise 2.0 failure' guest blogging on Michael Krigmans' 'IT Failure blog here on ZD Net), Dion Hinchcliffe (14 Reasons Why Enterprise 2.0 Projects Fail) and now Dennis Howlett (Enterprise 2.0: what a crock).
Dennis asks for an explanation of the problem Enterprise 2.0 is trying to solve. I'll attempt to answer that question in the context of business collaboration. Identifying business or IT failures is relatively simple: to draw an analogy with a car crash, arrive at the scene of the incident and comment on the damage caused by the impact.
Lists of common failures perceived from observation of these accident scenes can inform the bigger strategic planning picture, but these 'accidents' typically occur after the project is being rolled out and occur relatively late in the execution cycle.
I have a great depth of knowledge around Enterprise 2.0 case histories, both from personal experience managing a collaborative team and from research into other projects. As I've stated previously, successful projects don't need publicity - indeed successful collaboration by definition manipulates strategically and tactically important internal information in companies that is carefully shielded from the rest of the world. Sharing this component of competitive advantage with competitors is of no advantage.
Like any business decision, the problems 'Enterprise 2.0' is trying to solve should result in greater efficiency and profits, which justifies the investment of time and money. This is no different than thinking through an enterprise resource planning system for a business, its partners and customers.
The goal is not to speak mumbo jumbo buzz word language while blowing money on a user commune for freestyle project management by random participants, despite some of the more theoretical Enterprise 2.0 commentator's cargo cultish ideas. The world of Twitter, the myriad 'Software as a Service' offerings from small vendors and so on are empty calories in and of themselves.
Much as vendors of all sizes would love you to believe their Enterprise 2.0 software solutions are the one true way, the reality is the same as any other project planning and management think-through: what business problems are we trying to solve and what processes should we change in order to be more efficient? What tools should we then install to achieve our objectives?
Putting the cart before the horse - discussing the tools, particularly the more immature ones such as Twitter, the butt of many a late night TV comedians' jokes about self indulgent ego tripping celebs whining about their food etc - is a sure fire way to lose the respect of people who are used to planning out sophisticated solutions to business problems.
Andrew McAfee's academic framework he laid out for 'Enterprise 2.0' in 2006 is an operational model which has been subsequently expanded upon by various people including Dion Hinchcliffe.
The problems Enterprise 2.0 are trying to solve are further up the food chain however. Software that enables search, links, authoring, tagging, User recommendations and content feed subscription models are all operational. The 'being-in-the-flow' state - being able to navigate through work flows more quickly - presumes you know where you're actually going.
Before we get to an operational state we have to have a clear rationale for what it is we're trying to achieve. A lack of this, no matter how sophisticated and intuitive the tools, still equals chaos.
Morten Hansen's book 'Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results' examines how companywide collaboration is vital for successful strategy execution resulting in competitive advantage, yet the sought-after synergies are rarely, if ever, realized. Morten demonstrates most cross-unit collaborative efforts end up wasting time, money, and resources.
The reality is that the 'Enterprise 2.0 ' software industry enables collaborating parties to roll out next generation information silos replete with the ability to link, tag, recommend, analyze and so on, but without a well defined strategic and tactical roadmap you're just going to head off into business oblivion quicker.
Picking over the various failure states of a vehicle which has got lost and ended up in a wreck may offer some insight, but it will be more around accident scene investigation than strategic analysis.
Where the enterprise software foundations of companies - the ERP, HR and structured data electronically stored information (ESI) systems are the infrastructure, Enterprise 2.0 is essentially the superstructure, to use a sailing ship analogy.
The superstructure is the part of a ship above the main deck, where sailors climb up and down the rigging and do the busy work of propelling the ship along. The people directing the destination of the ship at the wheel had better have mapped out their route or there will have been a lot of hoisting the mainsail and tying of nautical knots for nought.
They might even find themselves marooned on an island of cargo culters who've built themselves their idea of an airplane - that won't get them to their destination either....