Failure 2.0: Is E2.0 ‘Failure’ Different Than Anything Else?
by Joe McKendrick
As a “seasoned expert” on failure (ha ha), I was quite interested to see Michael Krigsman had launched a new blog over at the ZDNet blogging community on the very topic of IT project failure.
Enterprise 2.0, of course, is not immune to project failures, and Michael takes up some of the issues around E2.0 in recent posts — taking Google, Grand Central, Skype, Ning (and Salesforce.com), Netflix, Google, and Gnomedex to task for some recent high-profile glitches and sudden service terminations.
Michael observes that Enterprise 2.0 cloud-based services will be held to the same standards as other utilities we’ve come to rely on to advance our civilization:
“Large-scale business adoption of Enterprise 2.0 infrastructure applications, such as Skype, will only occur when these new technologies can survive comparison with established utilities. Society has demanded that basic services — water, phone, electricity, roads, and so on — must adhere to certain levels of reliability and availability. Likewise, business users expect their software infrastructure to provide high reliability, especially in mission-critical domains. …Such high-profile failures make consumers and businesses wary of adopting Enterprise 2.0 tools.”
Michael goes on to note that “Enterprise 2.0 describes a philosophy of technological and organizational design; it’s not a spiritual path. Mission critical systems, whether old-style or new, must adhere to basic standards of reliability and availability… If you build systems that real people rely upon, then build them right. If your system doesn’t work reliably, then sorry, you aren’t yet ready for prime time.”
That covers external failure to deliver. But what about internal Enterprise 2.0 project failure? As things unfold, and Enterprise 2.0 sees wider adoption as an enterprise platform, it will be interesting to get Michael’s read on what will constitute success versus failure for E2.0 projects — be it failure to deliver ROI, or lack of enterprise adoption, or something else.
Over at my ZDNet SOA blog, I recently took up the question of what, exactly, constitutes SOA “failure,” and would we even know if a project has failed.
Of course, ROI is seen by many as the gold standard of project success, and FastFoward blogging colleagues Paula Thorton and Rob Paterson recently took up the matter of ROI and E2.0. Rob says corporate culture trumps ROI for any given initiative, while Paula admonishes companies to “stop the madness” around bean counting.
Some of the items that can be considered failures in an SOA setting may be transferable to E2.0, such as continued (or increased) lock-in by a single vendor, and lack of adoption of services by other users in the enterprise. Currently, Enterprise 2.0 is inexpensive to adopt, and any failures to deliver may have minimal impact. This may change as organizations come to depend more on E2.0 methodologies, platforms, and tools, however.
















