Debunking Enterprise 2.0 failure

Debunking Enterprise 2.0 failure

Summary: Guest blogger, Paula Thornton, questions basic assumptions of Enterprise 2.0 and what that means for failure in the social business world.

SHARE:
TOPICS: Enterprise 2.0
12

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.

Paula Thornton seeks to understand human behavior and designing interactions for human expectations as the means to achieve strategic differentiation. This is the focus of our discipline. It is not just nice to have‚ and is not, like documentation once was, an afterthought. It is the means by which to start a strategic discussion and the means by which to drive a tactical initiative. All design should be evidence-based. Follow Paula on Twitter as @rotkapchen.

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.]

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.

Talkback

12 comments
Log in or register to join the discussion
  • Lots of words, but what was really said?

    Umm - wow, lots of words, but not much said. Apparently there's a head in the sky here.

    I'm not sure you're really accomplishing anything by complaining about the definition of "Enterprise 2.0" when it sounds like you yourself don't seem to have a concrete definition.

    "New behaviors cannot survive where old beliefs govern reality."

    Umm - reality continues regardless of our beliefs. Nothing actually governs reality. Except God :).

    Old beliefs may or may not be right. I think that technologists are often stuck convincing themselves that newer is always better and that old ways can never be right.

    Sadly, that is not true. More than once I've seen plenty of productivity killed when a new hammer is used on an old screw. What was really needed was a screwdriver, but no, the hammer was brand new, it had to be the right thing!

    Always use the best tool for the job. Always. Doesn't matter if the tool is old or new - if it's the right tool, use it.
    CobraA1
    • Abstractions

      Those of use stuck in the mire of concrete IT-driven thinking sometimes forget that concepts and strategy have their place.

      Abstractions may not accomplish "work" such as you desire, but guiding vision is essential to any form of success.

      If the message is unclear, perhaps try reading it again (and yet again, if necessary). Thanks for commenting and sharing your thoughts.
      mkrigsman@...
      • It's nice poetry.

        Sometimes - you just need to take a fresh look at what is being abstracted and cut out the unnecessary words . . .

        Basically, what she said in so many words: "Forget practical tech. I want stuff to be more social."

        . . . and then she went into a myrid of metaphors and poetry on she thinks "Enterprise 2.0" really is.

        The next sections essentially amount to "Be aware of stuff and people outside your project." Or, to put it another way: "Take a look at the bigger picture." I don't think she really needed to go into hand waving about "forms" and metaphors like "they?re seeds from which solutions can bloom" to say that.

        If I want some fine poetry written or my church ceiling painted, I'll call her. If I want my next project to do what I want without a lot of fuss - I think I'll call somebody else.
        CobraA1
    • Abstractions Indeed

      Thanks Michael for jumping in. Indeed, the whole point of the post is that the failure is in that this requires more abstract thinking -- the antithesis of what's typically being applied.

      But it's also not one or the other. It's both. It's integrative thinking. See Roger Martin's model in his book "The Opposable Mind".
      Rotkapchen
  • RE: Debunking Enterprise 2.0 failure

    Basically for me it didn't come across as abstraction or a guiding vision, but a smoke screen.
    Real business uses what ever tools are necessary to get the job done. There is nothing really new about Enterprise 2.0 except some hype.

    New ways of thinking and solving problems are always in play, calling something "Enterprise 2.0" is arbitrary at best.

    If social networking and cloud computing end up tools that are used to support this "vision" so be it but most of the things I have been reading suggest that these things will end up niche techs for specific functions.

    As far a saying that the abstraction itself is somehow Enterprise 2.0 is like saying the Roman Empire's way of doing business was Enterprise 0.1. O.K. but nothing new to see here.
    mr1972
    • Following The Links?

      I'd have to guess you gave this a cursory once-over and did not follow any of the supporting links.

      This is a complex problem space.

      I love this statement by Roger Martin that fits here:

      "How many times has a supervisor scolded you for making a problem more complicated than it needs to be? You protest that you're not trying to complicate anything; you just want the problem to be as complicated as it really is" The Opposable Mind, pp 45, 46

      You can't just 'respond' to this topic. You have to immerse yourself in understanding it. This isn't cookbook. There are no checklists: http://www.fastforwardblog.com/2009/05/27/enterprise-20-isnt-a-checklist/

      There are no prescriptions...which is why you see none here.
      Rotkapchen
      • Cookbooks? Checklists? Prescriptions?

        Cookbooks? Checklists? Prescriptions? Can nobody speak plainly anymore?

        There is no single solution that solves every problem.
        CobraA1
        • Plainly?

          Plain is relative. What's plain to one is meaningless to another. As well, any term can connote different meanings, some of which might not be relevant. The use of analogies is useful in the realm of shared understanding.

          Indeed, "there is no single solution that solves every problem". And yet, why is it that so many insist on using technologies out of the box assuming that they will do just that?
          Rotkapchen
  • RE: Debunking Enterprise 2.0 failure

    As well, CobraA1, shares with us his 'thoughts' as to the validity of what I've said -- and yet he does so without testing it first in some way. He does exactly what this piece is trying to suggest: That the real issues are being dismissed because they're too squishy.

    This realm of operating IS squishy. Indeed, that's why it is suggested that while minds like CobraA1 might have been relevant in paradigms past, they are contrary to the mindsets needed to succeed in this paradigm. Such minds still have a place as participants, but they cannot be the framers of these solutions. They are ill prepared to wrap their heads around it.
    Rotkapchen
  • Cobra A1: Personified

    Oddly, CobraA1 has a language pattern that closely matches Dennis Howlett:

    1. Quick to dismiss the subject at hand, by a sleight of hand, rather than seek for further understanding.

    2. Does not in any way 'test' the thought being offered -- to determine if there are ANY conditions for which it might be valid. [I did that with Dion's but there was insufficient room in a single article to detail my discoveries.] Thus, is not trying to add to the conversation in any way, but is doing everything to 'stop' the conversation. The conversation itself helps to 'test' thought.

    3. Does not suggest or offer any experiences of their own to invalidate what is being said. Thus, establishes no grounding of interest or relevance to their own thought.

    4. Raises great points that are relevant for discussion, but undermines that discussion by trying to end it, as noted before. Results in a one-sided, lecture (common of people who fear real interaction -- also not the best resources for designing solutions which rely on interaction).

    5. I'm all about irreverence, but I demand of myself respect for others. I respect and indeed agree that there is value to what naysayers offer (clearly many suggested that they agreed that Dennis had relevant point to be made in his recent rant about Enterprise 2.0 http://www.fastforwardblog.com/2009/08/31/6-crockalicious-posts/. Naysayers help define the edges of the problem space. If only they could see the value of staying engaged rather than working to end the conversation.
    Rotkapchen
  • Operational vs. Social or "The Industrial Age and it?s Progeny"

    It seems that a fundamental concept for Paula is that work is social in nature, and technology is operational and thus the misfit or conflict.

    As we're philosophizing, let me be so bold as to say that pre-industrial revolution, work was probably felt as social. That not only communities of people were required to accomplish tasks, but that the tasks themselves also served to create or support community feelings: for example farming, or building. In fact, even today, if you look at communities that still practice a pre-industrial age lifestyle such as the strict Mennonites, that is still true.

    The Industrial Age changed that focus to be solely about activities that not only create profit but to maximize profit. In fact, the "ages" that have followed (info age, knowledge age, and the "blah blah" ages) have further emphasized that point of view to such an extent that "value" is attributed to only things that can directly relate to maximizing revenue and profit. Thus the intense focus on operations, and those disciplines (accounting, technology, etc.) that seek to monitor, control, or evaluate operations. The concept of "Social," is not even orthogonal to operations, it's in a different dimension -- it contains no inherent monetary value in and of itself.

    That's why so much effort is being made these days to "operationalize" and monetize things of a social nature.

    Let's face it, things that are "social" in nature or focused on social / community aspects are from Venus, and things and approaches whose orientation is operational are from Mars.
    elizab
    • Agree/Disagree?

      Elizab: Interesting that your closing statement would be the ultimate defense of what I'm postulating here.

      From the way you've described 'social', it would appear that you're applying it in a way that is far more 'limited' than is intended here.

      Humans are social beings. To truly optimize the potential that humans can contribute to business requires that it embrace our inherently social natures. That means making sure that all points in which human exchange occurs is optimized for that exchange.

      In reality, we've focused more on the digital technologies to enable the exchanges (e.g. eliminating 'noise' in a phone signal) than in the real value of the exchanges. For example, what good is a clear phone signal when none of the automated phone options provide answers your question or can get you to a human being to solve your problem? What good is a fast page response when a web site cannot connect you to the answer you're looking for?

      The bottom line is, no digital technology can ever totally replace the need for human interaction -- no system can be designed to accommodate all scenarios. And the rate at which unique scenarios are expected as a means of doing business is accelerating faster than the ability to adequately respond. Human intervention again is required.

      Try as you might, there is no such thing as 'operationalizing' social. I'm not suggesting it's not valid as a pursuit. I'm suggesting it's a matter of both; one feeding the other for continuous improvement. Continuous improvement is not possible if a solution is not architected for adaptation.
      Rotkapchen