Debunking Enterprise 2.0 failure

As part of a series of guest posts, I asked Enterprise 2.0 thinker, Paula Thornton, to contribute a blog challenging assumptions about IT failure. Her post jumps into a discussion with ZDNet blogger, Dion Hinchcliffe, on the subject of failure in the Enterprise 2.0 world.

As someone actively involved in the Enterprise 2.0 community, a post by ZDNet's Dion Hinchcliffe, called 14 Reasons Why Enterprise 2.0 Projects Fail caught my attention. While I have great respect for Dion, his piece offers overly general advice that will not actually help practitioners avoid failure.

As a commenter on his post clearly states, Dion's advice is not specific to Enterprise 2.0 initiatives:

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.

Sincere efforts to observe and evaluate what's happening with Enterprise 2.0, and why, are valuable. But they face a critical challenge, noted by Christopher Alexander, way back in 1964:

Today functional problems are becoming less simple all the time. But designers rarely confess their inability to solve them. Instead, when a designer does not understand a problem clearly enough to find the order it really calls for, he falls back on some arbitrarily chosen formal order. The problem, because of its complexity, remains unsolved. [emphasis added]

Does Dion's post contribute to solving the problem, or does it fall back on the symptoms of failure? If not unique to Enterprise 2.0, are these symptoms part of a larger problem that isn't being solved? If smoke, where's the fire?

SMOKE SIGNALS

Additional commenters suggest clues we can follow; one offered:

Creating and nurturing a community is not something at which traditional stakeholders in software projects are often skilled.

Another expressed frustration in a rant, explained in the context of his or her reality:

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.

The first comment highlights social considerations and shortcomings. While the second one may seem to focus on technology, it too is a testament to social considerations and shortcomings: decisions made without concern for the individuals impacted.

WORK IS SOCIAL; TECHNOLOGY HAS BEEN OPERATIONAL

Andrew McAfee recently reasserted his definition of Enterprise 2.0, saying "it's not not about the technology." Yet, his definition seems more social than not: "enables people to rendezvous, connect or collaborate... mechanisms to let the patterns and structure inherent in people's interactions become visible over time."

Work is inherently social. But technology solutions for over three decades have not reflected the social reality of work. The problems are contextual, starting with the history of the craft.

Originally software was operational. Computing was not only black box, it was back room – the ‘interface' was reams of green-bar reports, pored over for reference. Technology provided data to support the work, but not solutions for the work itself. Solutions were mechanisms to capture data for processing. People facilitated the existence of the solution, not the reverse.

The advent of the PC changed that – but not quite. For decades the two worlds remained separate. When the Internet arrived, separate business models addressed this ‘third form' of solutions: the eBusiness era. After the dot.flop, came 2.0. Still, the operating model of the machine-that-cranks-out-solutions chugged along, business as usual, fundamentally unchanged from its early beginnings aside from differences in décor.

Redecorating the operating model will not work. Oliver Marks offered a glimpse of Enterprise 2.0 meets operating model 0.0:

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.

TECHNOLOGY HAS NO FORM

Technology enables and enhances the creation of form, but it is not the form itself. To create form requires design. Christopher Alexander wrote:

[E]very design problem begins with an effort to achieve fitness between two entities: the form in question and its context. The form is the solution to the problem; the context defines the problem. ...when we speak of design, the real object of the discussion is not the form alone, but the ensemble comprising the form and its context.

Enterprise solutions still optimize the black box of operations, not the social context. Can software engineers design for social contexts? Do structural engineers design the interiors of buildings for use?

In deference to Mr. McAfee, the technology is relevant and necessary, but is not sufficient. As Sameer Patel recently noted in a guest post on this blog:

Enterprise 2.0 is not a category of software. Rather it's a state that the enterprise achieves by leveraging social computing concepts and technologies, to accelerate business performance.

Where humans are involved, all computing is social. Sameer adds:

[I]f you haven't considered and responded to the psychological drivers for each user type, a vibrant socially networked business ecosystem won't emerge.

DDA: DESIGN DEFICIT ATTENTION

Forrester and Gartner seem to avoid issues of technologically myopic perspectives and skillsets in IT. Their rationale? Clients aren't looking for such realities. These issues aren't on CIOs Top-10 list. No one is looking for research suggesting their business models have to fundamentally change.

Enterprise 2.0 isn't a project. It's a different way of approaching solutions - it's a mindset from which uniquely identifiable solutions ensue. It changes the means to accomplish work -- the ability to adapt the tools (technology) to the work and the work to the tools. Enterprise 2.0 technologies are not solutions - they're seeds from which solutions can bloom.

I concur with comments challenging Kumabaya cheerleading in relation to Enterprise 2.0: business seeks concrete value in real solutions. But, in fact, a primary focus of Enterprise 2.0 is facilitating ‘getting things done'.  Find the intersection where ‘getting things done' crosses with the triage for issues and corrections. That's where Enterprise 2.0 begins.

Enterprise 2.0's true potential is to facilitate a paradigm shift that fundamentally changes operating models and leverages the existing reality of work. Dion was on the right trail when he spoke of situational software in 2006.

PEOPLE INNOVATE

From one of my first posts on the subject of Enterprise 2.0:

Innovation is a human ability, not a technical one. Technologies can be deemed innovative, but do not innovate.

The unique contribution of Enterprise 2.0 is to embrace and celebrate human ability. Where this does not happen, failures will continue, Enterprise 2.0 or otherwise.

New behaviors cannot survive where old beliefs govern reality. While statements like this are often used to explain Enterprise 2.0 adoption failures, adoption is necessary where something is added. Enterprise 2.0 is not added to work, it is integral to the work. Fusing work and technology requires design.

Dion describes the failure of Enterprise 2.0 as if it is an appendage and says nothing about design as a means of bringing alternate form to the business. Enterprise 2.0 is a way of doing business, embracing the social nature of work, enhanced by technology. It's not an appendage.

[Thank you to Paula Thornton for writing this guest post. Image from iStockphoto.]