In a major update to its product set, Salesforce.com introduced an enterprise-level social networking platform, called Chatter, which was inspired by Twitter and Facebook. I think the announcement is exciting, but the picture is not entirely perfect.

Here are some first impressions, based on conversations with Salesforce executives, independent analysts, and bloggers. I plan to follow up with the company’s customers to gain a more complete view of this platform.

On the surface, Chatter seems rather unexciting. After all, enterprise social computing products aren’t new; for example, an enterprise Twitter-style application called ESME, which was created by developers connected with SAP, has been around for over a year.

Chatter sports some interesting features, such as the ability of Force.com applications to send status messages into the Twitter-like stream. (For an excellent breakdown of Chatter’s features, take a look at Dion Hinchcliffe’s ZDNet post on this topic.) However, the import of this announcement has nothing to do with features; it arises from Salesforce’s level of visibility and its commitment to social computing.

When a company of Salesforce’s size and stature seriously gets behind a particular technology or market, it brings credibility and a halo to everyone in that ecosystem. In this case, Salesforce appears to be making a substantive, long-term commitment of resources and marketing capital to the social computing and Enterprise 2.0 domains.

Of course, an announcement does not carry the weight of shipping real product to customer, so the jury of reality has yet to reach a verdict. With that in mind, I asked Brett Queener, Senior Vice President of products, to describe the company’s level of commitment to Chatter. His comments are unequivocal:

Chatter changes the game by creating a perfect marriage between cloud computing and social computing. We are hugely committed to chatter and what we previewed at Dreamforce is only a small glimpse of what we plan to deliver over the years.

Chatter will receive the same level of focus, investment, and commitment as all of our other clouds - i.e. sales cloud, service cloud, and custom cloud. Importantly, Chatter is an entirely new layer of our underlying platform architecture, which all of our customers, partners, and developers can leverage to build their own social applications. They too can now have all of their users, content, and applications join the conversation.

Although Salesforce is hardly the first company to attempt draw direct connections between social networking and enterprise computing, the strategic weight they bring to this space is meaningful.

THE PROJECT FAILURES ANALYSIS

Salesforce is certainly not the first company to consider how social networking intersects with the enterprise. However, the company’s size and commitment will help CIOs gain comfort with the entire notion of a “social enterprise.”

Bob Warfield, CEO of social CRM vendor Helpstream, agrees with this assessment:

There are some great things about the Chatter announcement. If nothing else, it cements Social as must-have and not just nice-to-experiment-with. It’s very cool that it will be part of the platform, so that other things built on the platform can be tied into it. If Sharepoint can have a $7B ecosystem associated with it, I don’t know why Salesforce can’t have a Social Ecosystem too.

On the other hand, we should be cautious about becoming overly excited about a new product that hasn’t even shipped. As we all know, vision is easier than execution. Bob Warfield offers a skeptical perspective:

It’s a reasonably well executed demo. There’s nothing breakthrough. There’s even a lot of doubt about whether it is on par with state of the art for Social. Most everyone I talked to said, “Definitely not, at least 18 months behind.”

I didn’t forget to say “reasonably well executed product,” the word “demo” was there advisedly.  There’s no announced shipping date, just Calendar 2010. When it’s put that way, you can usually assume the worst–December 2010?  Q4 anyway? And when you start with a baseline that is not state of the art, does that mean it isn’t shipping now because they’re going to add a bunch to it, or does that mean it’ll be the same product and hence even further behind the curve?

Ray Wang, analyst and partner at the Altimeter Group, adds additional context for the announcement:

Chatter validates the Enterprise 2.0 market but will test Salesforce.com’s ability to keep up with offerings from pure play vendors such as Jive and Lithium. Even established collaboration vendors IBM/Lotus and Microsoft have potentially competitive products in the pipeline. These vendors are investing more resources, and in some cases have more experience in this market, than Salesforce.com. However, we can expect Salesforce.com’s credibility among enterprise buyers to give Chatter a good boost as a collaboration cloud.

My take. Only time will reveal Salesforce.com’s true commitment to Chatter as a platform. I do think this is an important move, but ultimately Salesforce will invest based on customer interest and demand. Parker Harris, Salesforce.com’s co-founder, made this clear during a conversation with several bloggers, including myself. (Fellow ZDNet blogger, Dennis Howlett, videotaped a particularly interesting part of that conversation.)

Regardless of where Salesforce decides to take Chatter, the announcement demonstrates that social computing space is reaching a tipping point, which I think is great.

For a further discussion about Chatter, see this video conversation between Forrester analyst, Natalie Petouhoff, Dion Hinchcliffe, and me:

A few observations:

• Salesforce.com is indeed a force to be reckoned with. One of the largest software vendors in the world, with an annualized run rate of $1.3 billion in revenue, no one can deny the inroads that cloud computing has made in the enterprise. 19,000 people registered for this conference, an obvious indicator that something serious is going on.
• The company has developed a vibrant ecosystem. Wandering through the expo hall to see the vendors and partners showing their wares, I was struck by diversity. Notably, I spoke with a system integrator implementing large (over 1000 seats) Salesforce projects. At that scale, there’s real complexity, especially around business process redesign and integration with existing systems. I intend to explore this topic further.
• CEO Marc Benioff emphasized “trust” as key theme. In a slide showing aspect of the Saleforce’s infrastructure, trust was right at the center. Here’s a photo:

The trust issue is big and there’s no surprise Benioff positioned it front and center of his first slide on product strategy. Trust, confidence, and reliability are among the key matters of concern to large enterprise buyers.

This post comes while the keynote is in-progress. More soon…

[Photo by Michael Krigsman.]

Large organizations continue to embrace Enterprise 2.0 as a viable addition to the corporate business process toolbox. As evidence, look no farther than the rapid growth of The 2.0 Adoption Council, which was founded this past June and currently boasts more than 100 member organizations, each of which has more than 10,000 employees.

Despite clear interest from the enterprise, discussion persists around obstacles to large-scale adoption of Enterprise 2.0 approaches, tools, and methods.

ZDNet’s Joe McKendrick summarized key obstacles in blog post at Fast Forward:

Resistance to change	52%
Difficulty in measuring ROI	42%
Integrating with existing technologies	41%
Security concerns	32%
Budget	25%
Product knowledge	23%
Tools not enterprise ready	22%

It should not surprise us that the top issue is resistance to change. Readers of this blog know that business projects of every kind suffer from issues related to poor communication, conflicting agendas across information silos, and related organizational causes of failure.

A recent study from The 2.0 Adoption Council also describes resistance to change as the significant barrier. This compelling slide clearly summarizes that message:

In a fascinating blog post, independent analyst, Gil Yehuda, describes reluctance to share information inside German organizations:

The union leaders are not so keen on having E2.0 tools since it can result in eroding their power and give more power to the workers that the union represents. Managers in small companies can also form owner-councils. This can help them negotiate with the workers’ councils — and may also be threatened by the shift in power too. In other words — there are decision makers on both sides that are threatened by E2.0.

In a related post, Gil states that German adoption of Enterprise 2.0 is high, despite this resistance. He quotes ZDNet blogger (and my colleague in the Pragmatic Enterprise 2.0 initiative), Dion Hinchcliffe, as saying: “Germany is the #2 marketplace for E2.0.”

I asked Dion to clarify this assertion:

Germany is one of the top countries actively engaging in Enterprise 2.0 and appears to be 2nd after the U.S. based on some early data points such as informal sampling of top social software vendors.”

MIT professor Andrew McAfee, who coined the phrase Enterprise 2.0, addresses the resistance issue from a different perspective. He discusses organizational resistance to change in a blog post on prediction markets (which offer a method for aggregating intelligence based on wisdom of crowds theories). Andy questions why companies sometimes resist adopting prediction markets:

So what is the real stumbling block? Is it that companies don’t really want the most accurate information about future events to come out and be widely known?

On the surface, the answer seems obvious: “Of course, everyone wants accurate information.”

Digging deeper, we come across an interesting paradox. In theory, most folks applaud information sharing and transparency as worthy goals. In practice, however, some people are reluctant to release information, feeling that doing so may threaten their own personal standing or advantage.

I asked The 2.0 Adoption Council’s founder, Susan Scrupski, to comment on the statistics quoted above. I also requested her thoughts on the notion that fear is the real inhibitor to Enterprise 2.0 adoption:

Fear has an irrational connotation when we discuss it in business terms. Relative to 2.0 adoption, it seems there is a more rational emphasis on Uncertainty and Doubt. Those in power are reluctant to change because they’ve learned to master the devil they know. Those without power (and now discovering new freedom in having a voice) are cautious because it’s not clear what the career ramifications of their assertiveness will yield.

Separately, it’s worth noting a recent meme that questioned the legitimacy of Enterprise 2.0 as a basic value proposition, labeling the whole thing a “crock.” That’s just not a question we need to take seriously at this stage. If you are interested, Andy McAfee describes a half-dozen valuable use cases in a blog post.

THE PROJECT FAILURES ANALYSIS

The 2.0 Adoption Council’s growth makes clear that Enterprise 2.0 has evolved from an amorphous set of activities and goals into a valuable corporate focus point. Despite enthusiasm, however, we must recognize that Enterprise 2.0 adoption is subject to the same issues and obstacles as any other business transformation initiative.

The fundamental challenge to rapid diffusion of Enterprise 2.0 in large companies and the government is fear of change. As with all business activities, the human element remains a basic driver of success and failure. Enterprise 2.0 practitioners, consultants, early adopters, and observers should recognize the reality of these obstacles and plan accordingly.

In general, fighting human nature is an uphill battle that eventually results in failure. Instead, work gently with stakeholders to help them experience first-hand the benefits of Enterprise 2.0. Success is the most powerful form of organizational transformation and evolution.

Listen to the podcast to hear how their conversation ebbed and flowed like a great jazz improvisation.

Nenshad Bardoliwalla is a creative entrepreneur who most recently was CTO for Enterprise Performance Management (EPM) and Governance, Risk, and Compliance (GRC) at SAP. Nenshad is author of the book, Driven to Perform, a 700-page reference on managing performance with systematic metrics. When I have questions about BI, metrics, and related topics, you can guess to whom I turn for advice.

Naomi Bloom is a top consultant, analyst, writer, and thought leader throughout the HRM delivery system (HRMDS) industry. Her specialty is the application of HR technology and innovative service delivery models to achieve breakthroughs in organizational business outcomes. Check out her formal bio–it’s pretty darned impressive.

Pulling these two folks together for an IT failures podcast presents an interesting challenge because their backgrounds and areas of professional focus are so different. However, they share an abiding interest in improving business transformation with technology-related projects. In other words, these guys understand how technology and business interact to produce useful results (or not, as the case may be).

The podcast recording session was informal and fun; really, three friends getting together to chat about the drivers of business success and failure. If that means I hang around with geeky friends, then guilty as charged.

Here are a few excerpts from the podcast, just to give you a flavor of the discussion. These are notes and not meant to be a transcript.

Naomi: Business outcomes and achieving the mission matter most. In today’s world, the vast majority of the work we do to accomplish these goals is technology-enabled. So, if we don’t get the technology part right, then we fail.

To define success, ask people in the business whether a new system helps or hurts the day-to-day effort to accomplish their job. Looking at this way, there’s a lot of failure out there.

Nenshad: The discipline of performance management is meant to align the people in an organization with the outcomes they are trying to achieve. Failure often results when an organization implements technology without first deciding on the outcomes. If you don’t know the target, then it is difficult to design technology that will achieve your goals.

For example, organizations often justify CRM systems to increase efficiency — but you can only wring so much efficiency out of the system. Cutting costs alone does not give you growth or increase effectiveness.

Before implementing any type of system or redesigning processes, first establish the business objectives and then set relevant metrics and goals.

Naomi: Define strategy, goals, and desired outcomes and then figure out the technology. An organization must have the discipline to put the right business rules into the system. if you don’t plan outcomes, the technology doesn’t matter.

Nenshad: Technology is inconsequential compared to people and process issues. Every single business performance outcome — profitability, return on assets, and so on — has both human and financial elements. Therefore, to succeed we must consider both when designing and managing. Understanding this is the new management competency of this era.

Naomi: In the best companies, every employee understands, and can articulate, the company’s operating principles and the rules governing how the company makes decisions. Their own decisions therefore line up with the bigger decisions of the company. Zappos and Nordstrom’s offer great examples of this.

Each person working in successful companies understands how his or her work relates to the financial outcomes of the company. Problems arise when people do not viscerally understand where they fit into the grand scheme. Likewise, disconnects across groups and information silos cause failure.

Nenshad: BI vendors sometimes forget the people angle and develop technology that is not terribly useful. Users want prescriptive answers and advice on running their business and making decisions.

———-

These two insightful people each have a clear, strong voice that is rooted in practical experience. Listening to them riff back and forth is like hearing great jazz musicians. You never know what’s going to come next, but it’s always good and leaves you wanting more.

[Image of Jazz by Henri Matisse from Wikipedia and used under Fair Use.]

Enterprise systems are inherently complex, often involving many business processes, people, and organizations across a company. Given this built-in complexity, it’s no surprise that failures abound; it’s amazing these systems function at all.

We could make these same comments about any complex, mission critical system. For example, look no further than the space program or health care delivery. In both cases, massive complexity is connected to a need to get things right: failure means potential loss of life.

To say that complicated systems are more prone to break down than simpler systems is obvious. But there are also other, more subtle truths regarding failure and complex systems.

A paper copyrighted in 1998, called How Complex Systems Fail and written by an M.D., Dr. Richard Cook, describes 18 truths about the underlying reasons complicated systems break down. On the surface the list appears surprisingly simple, but deeper meaning is also present. Some of the points are obvious while others may surprise you.

THE EIGHTEEN TRUTHS

The first few items explain that catastrophic failure only occurs when multiple components break down simultaneously:

1. Complex systems are intrinsically hazardous systems. The frequency of hazard exposure can sometimes be changed but the processes involved in the system are themselves intrinsically and irreducibly hazardous. It is the presence of these hazards that drives the creation of defenses against hazard that characterize these systems.

2. Complex systems are heavily and successfully defended against failure. The high consequences of failure lead over time to the construction of multiple layers of defense against failure. The effect of these measures is to provide a series of shields that normally divert operations away from accidents.

3. Catastrophe requires multiple failures - single point failures are not enough. Overt catastrophic failure occurs when small, apparently innocuous failures join to create opportunity for a systemic accident. Each of these small failures is necessary to cause catastrophe but only the combination is sufficient to permit failure.

4. Complex systems contain changing mixtures of failures latent within them. The complexity of these systems makes it impossible for them to run without multiple flaws being present. Because these are individually insufficient to cause failure they are regarded as minor factors during operations.

5. Complex systems run in degraded mode. A corollary to the preceding point is that complex systems run as broken systems. The system continues to function because it contains so many redundancies and because people can make it function, despite the presence of many flaws.

Point six is important because it clearly states that the potential for failure is inherent in complex systems. For large-scale enterprise systems, the profound implications mean that system planners must accept the potential for failure and build in safeguards. Sounds obvious, but too often we ignore this reality:

6. Catastrophe is always just around the corner. The potential for catastrophic outcome is a hallmark of complex systems. It is impossible to eliminate the potential for such catastrophic failure; the potential for such failure is always present by the system’s own nature.

Given the inherent potential for failure, the next point describes the difficulty in assigning simple blame when something goes wrong. For analytic convenience (or laziness), we may prefer to distill narrow causes for failure, but that can lead to incorrect conclusions:

7. Post-accident attribution accident to a ‘root cause’ is fundamentally wrong. Because overt failure requires multiple faults, there is no isolated ‘cause’ of an accident. There are multiple contributors to accidents. Each of these is necessary insufficient in itself to create an accident. Only jointly are these causes sufficient to create an accident.

The next group goes beyond the nature of complex systems and discusses the all-important human element in causing failure:

8. Hindsight biases post-accident assessments of human performance. Knowledge of the outcome makes it seem that events leading to the outcome should have appeared more salient to practitioners at the time than was actually the case. Hindsight bias remains the primary obstacle to accident investigation, especially when expert human performance is involved.

9. Human operators have dual roles: as producers & as defenders against failure. The system practitioners operate the system in order to produce its desired product and also work to forestall accidents. This dynamic quality of system operation, the balancing of demands for production against the possibility of incipient failure is unavoidable.

10. All practitioner actions are gambles. After accidents, the overt failure often appears to have been inevitable and the practitioner’s actions as blunders or deliberate willful disregard of certain impending failure. But all practitioner actions are actually gambles, that is, acts that take place in the face of uncertain outcomes. That practitioner actions are gambles appears clear after accidents; in general, post hoc analysis regards these gambles as poor ones. But the converse: that successful outcomes are also the result of gambles; is not widely appreciated.

11. Actions at the sharp end resolve all ambiguity. Organizations are ambiguous, often intentionally, about the relationship between production targets, efficient use of resources, economy and costs of operations, and acceptable risks of low and high consequence accidents. All ambiguity is resolved by actions of practitioners at the sharp end of the system. After an accident, practitioner actions may be regarded as ‘errors’ or ‘violations’ but these evaluations are heavily biased by hindsight and ignore the other driving forces, especially production pressure.

Starting with the nature of complex systems and then discussing the human element, the paper argues that sensitivity to preventing failure must be built in ongoing operations. In my experience, this is true and has substantial implications for the organizational culture of project teams:

12. Human practitioners are the adaptable element of complex systems. Practitioners and first line management actively adapt the system to maximize production and minimize accidents. These adaptations often occur on a moment by moment basis.

13. Human expertise in complex systems is constantly changing. Complex systems require substantial human expertise in their operation and management. Critical issues related to expertise arise from (1) the need to use scarce expertise as a resource for the most difficult or demanding production needs and (2) the need to develop expertise for future use.

14. Change introduces new forms of failure. The low rate of overt accidents in reliable systems may encourage changes, especially the use of new technology, to decrease the number of low consequence but high frequency failures. These changes maybe actually create opportunities for new, low frequency but high consequence failures. Because these new, high consequence accidents occur at a low rate, multiple system changes may occur before an accident, making it hard to see the contribution of technology to the failure.

15. Views of ‘cause’ limit the effectiveness of defenses against future events. Post-accident remedies for “human error” are usually predicated on obstructing activities that can “cause” accidents. These end-of-the-chain measures do little to reduce the likelihood of further accidents.

16. Safety is a characteristic of systems and not of their components. Safety is an emergent property of systems; it does not reside in a person, device or department of an organization or system. Safety cannot be purchased or manufactured; it is not a feature that is separate from the other components of the system. The state of safety in any system is always dynamic; continuous systemic change insures that hazard and its management are constantly changing.

17. People continuously create safety. Failure free operations are the result of activities of people who work to keep the system within the boundaries of tolerable performance. These activities are, for the most part, part of normal operations and superficially straightforward. But because system operations are never trouble free, human practitioner adaptations to changing conditions actually create safety from moment to moment.

The paper concludes with a ray of hope to those have been through the wars:

18. Failure free operations require experience with failure. Recognizing hazard and successfully manipulating system operations to remain inside the tolerable performance boundaries requires intimate contact with failure. More robust system performance is likely to arise in systems where operators can discern the “edge of the envelope”. It also depends on providing calibration about how their actions move system performance towards or away from the edge of the envelope.

THE PROJECT FAILURES ANALYSIS

Rob England, who writes the IT Skeptic blog, brought the paper to my attention. Rob describes its importance on his blog:

It is not often you read something that completely changes the way you look at IT. This paper How Complex Systems Fail rocked me. Reading this made me completely rethink ITSM, especially Root Cause Analysis, Major Incident Reviews, and Change Management.

It dates from 1998!!. Richard Cook is a doctor, an MD. He seemingly knocked this paper off on his own, it is a whole four pages long, and he wrote it with medical systems in mind. But that doesn’t matter: it is deeply profound in its insight into any complex system and it applies head-on to our delivery and support of IT services.

Read this paper. And READ it: none of this 21st Century 10-second-attention-span scanning. READ IT HARD. Blow your service management mind.

My take. This is one of the most insightful and important papers on failure I have read. Although focused on health care delivery, the lessons are equally applicable to large enterprise software systems.

[Photo of the long tail of failure from iStockphoto.]

In addition, the magazine’s Executive Editor, Tony Collins, is one of the top journalists covering IT failures; Tony takes no prisoners but is always fair and impartial. His work has served as an inspiration to me.

SHAMELESS, UNREPENTANT PLUG

Yes, I want you to vote — for my blog! To make it easy, please follow this little guide.

Step 1. Click the voting page

Step 2. Scroll down to number 7, the Project Management category, as shown here:

Step 3. Do the right thing….

In this guest blog post, Miko Matsumura, Vice President and Chief Strategist of Software AG, offers a humorous look at the Enterprise 2.0 movement. In addition to his position at Software AG, Miko is the author of the book, SOA Adoption for Dummies.

Miko’s underlying message is important: to be successful, Enterprise 2.0 activities must remain rooted in the practical realities of real companies, processes, and corporate cultures. I share this perspective. Although the tone and images are funny, I assure you the message is serious.

———–

It’s a cool sunny day in San Francisco. I’m at the Moscone center where there’s some bustle around the Enterprise 2.0 conference. You can tell it’s an Enterprise conference because, unlike the Web 2.0 Conference, there’s no free pass even to the show floor. Also, the full pass is about $2500 bucks.

As I’ve been discussing on Twitter @mikojava and in my blog, here are my top five definitions of Enterprise. Feel free to chime in with your views via Twitter, email or my blog.

One way to define Enterprise is:

en⋅ter⋅prise:
/ˈɛntərˌpraɪz/ [en-ter-prahyz]
-noun

5. Stuff I wouldn’t do unless you paid me.

This definition puts Enterprise squarely in the camp of crime scene janitorial services. It adds a concept of “professional” to the discussion and establishes the Enterprise as the realm of uncomfortable clothing.

I recall reconnecting with Arthur Van Hoff after our adventures in Java and having him laugh at me because I was wearing (in his words) an “IQ Restrictor,” his parlance for a necktie. This definition also puts a dynamic tension between the “Suits” at the Enterprise 2.0 conference and the boho hipsters wearing the Emo Hair.

4. Software that sucks.

This was the definition I evoked in my post “The Human Enterprise.” To be honest, I introduced the idea of “The Human Enterprise” as a direct counter-proposal to “Enterprise 2.0.”

I think the piece that was missing from The Human Enterprise is the extent to which fragmentation plays a role in the essential nature of the Enterprise, which is a theme I’ve been addressing more lately in terms of the effect of sheer size on the Enterprise.

3. A venture requiring industriousness or courage.

This definition deserves some attention because it in some ways captures exactly what’s missing from the current debate around the Enterprise. The extent to which courage has been slowly sapped by the ravages of the Great Recession and “job security” is to some extent disheartening. In particular, efforts to rejuvenate the complex IT System Architecture and to mitigate the effects of Entropy and the “Heat Death of IT” have been met with cries of “SOA is Dead.”

So here’s a call for the restoration of courage in IT, to boldly go. Set phasers on “frappe.”

2. Dead stuff that used to matter.

Rumors of the death of Enterprise Software have been greatly exaggerated (nice post by David Hornik). The thing people find hard to understand about the longevity of most Enterprise IT is that “dead” software actually lives a long time. In fact dead software (nice post by James Governor) runs 90% of the economy.

Another word for “legacy” is IT projects that worked. The word for IT projects that didn’t work is “consolidation.” This should be especially resonant for folks at the Enterprise 2.0 conference, since 99% of the projects spawned by “Enterprise 2.0″ will fall into the latter category. We will have won when there’s “Legacy Enterprise 2.0″ apps out there.

1. An organization whose mission requires significant size, growth and longevity.

I present this as the number one definition in an attempt to extract the most salient feature of the Enterprise to casual observers. The definition is designed to be inclusive of Government organizations. I don’t want to open a can of worms (big government vs. small government), but arguably some “missions” such as the regulation of interstate commerce and providing for the common defense would require a degree of size, scale and longevity.

But what’s more interesting about this definition are the implications:

• At this scale, the organization struggles with whether it’s “too big to fail” or “too big to succeed.”
• The implications of size include fragmentation of organization into tribes.
• The implications of growth include fragmentation of markets into niches.
• The implications of longevity include fragmentation of technology into silos.

These forms of fragmentation are the key challenge of Enterprise, and the points that some E2.0 companies seem to miss. Trying to repackage consumer apps and peddle them to Enterprises misses the unique pain of Enterprise. I’ve spoken and written extensively about the effect of technological and organizational silos, for example in my book SOA Adoption for Dummies. But lately I’ve been thinking about the effects of market fragmentation.

There comes a tipping point in any large commercial sector Enterprise where the market for the flagship product or service becomes saturated. At this juncture, the revenue growth challenge becomes less about attracting and delighting new customers but rather about sucking as much money out of existing customers as possible.

The example I will provide for you is the Apple iPod. At the risk of offending fanboys, the iPod market is saturated. I must own a half dozen iPods. Now I go running with my iPod nano 3g. When my 3g failed, I went to the Apple store to buy a new iPod. The way Apple segmented their products, they had created a low-end model at $59 dollars (the clip) which had no screen; a “medium” range but portable option (the nano) at $150; and then the “platform” model, the iPod Touch at $199.

The nano costs only 50 bucks less than the Touch, but for users who want to run with an iPod, the Touch is too big. Since they overloaded the nano with features I don’t want (accelerometer, video camera, FM radio) they were able to jack up the price.

This kind of behavior exists in many mature markets, including cell phone plans. The cell phone companies have “package designers” who specifically design packages including SMS and email that rack up a maximum number of overcharges and fees. They design packages that exploit the gap between what users think they will use and what they actually use based on data mining in their demographics.

This type of behavior makes the Enterprise essentially the “enemy” of the consumer. Of course, we want successful companies to have profits so they can fuel the next generation of investment. I certainly want Apple to succeed, and I bought their product even though I found it mildly distasteful (it was still the best player for my purpose).

———–

I wrote this post in the hopes that it would stimulate discussion about how people define the “Enterprise” in “Enterprise 2.0.”

[Thank you to Miko Matsumura, Vice President and Chief Strategist of Software AG, for writing this guest post, which is reprinted from his blog. All images supplied by the author.]

I’m assembling the definitive Twitter list of folks who have demonstrated deep insight and commitment into analyzing the causes and prevention of IT failures. The list is called IT Failure Insights and I need your help to get it right.

If you know someone who should be on that list, please send me a message on Twitter.

Before adding anyone to the list I will ask to see blog posts, Twitter messages, papers the person has written, or other examples demonstrating clear connection between their professional life and this topic.

[Photo from iStockphoto]

Every seasoned executive knows that gaining detailed and accurate information about his or her organization’s activities is a challenging and ongoing struggle. Disconnects between operational data and management decision-making lead to inefficiency, waste, and ultimately to extreme failures of the type described in this blog.

Usually, some members of an organization do possess accurate early warning information regarding potential problems. However, as we have seen in situations ranging from Enron to financial industry practices that kicked off the current recession, surfacing that information can be difficult.

I asked top auditing services analyst and former BearingPoint managing director, Francine McKenna, to place this issue in context. Francine told me:

It’s a classic problem rooted in human nature. Information in large, complex, and geographically dispersed organizations tends to become diluted and distorted as it flows up the chain. Even worse, some individuals redesign information flowing through their hands based on personal goals and objectives.

The best organizations recognize this state of affairs and create standardized policies, procedures, and governance monitoring activities to overcome it. Despite these efforts, however, the problem remains a very real challenge.

Detecting and amplifying “weak signals.” Techniques that reveal hidden vulnerabilities are a valuable weapon in the fight against project failure.

My recent post, Learning from the weak signals of failure, discussed the importance of methods that detect and amplify these weak signals:

Many so-called “victims” of failed projects claim they were blindsided by problems that arose suddenly out of nowhere. In reality, the entire notion that failures spontaneously arise without warning is nonsense.

Most troubled projects suffer from poor communication across information silos, which is a variant of the information disconnects discussed above. For example, communication problems are common between management and workers; IT and the lines of business; internal groups and external vendors; and so on. Successful methods for revealing hidden sources of potential failure are therefore particularly valuable when they operate across traditional organizational boundaries and silos.

• Related: Learning from the weak signals of failure

Traditional methods to uncover and amplify weak signals include interviewing project participants, applying business intelligence techniques to data associated with a project, and using portfolio management techniques such as resource analysis.

Recently, several companies have developed new approaches for detecting weak signals. These techniques are applicable to preventing waste and inefficiency associated with business initiatives of all sorts.

Dachis Group. Social business consultancy, Dachis Group, uses a concept called dynamic signals to explain the undercurrent of information flows running through an organization. As this schematic diagram illustrates, Dachis intends for this approach to measure points in a workflow or process, separating important information from background noise:

In an email, Dachis Group principal, Jevon MacDonald, explained that dynamic signal techniques allow one to recognize the “heartbeat” of an organization:

Dynamic signal helps users see their work in the context of other parts of the organization, for example, the activities in which other people or machines are engaged or the progress of a workflow. Automated techniques help separate important information from background noise and allow us to maintain an ongoing “ambient awareness” of activity status across an organization or network.

The Dachis website states that the company:

[H]elps its clients utilize a measurement framework to capture value in social interaction and conversation. We recognize that clients are not at a loss for data, but actionable interpretation.

The concepts appear interesting and promising, but additional detailed information is required before we can understand how Dachis applies this approach to practical business situations.

Asuret. IT failures consultancy, Asuret, uses an approach based on concepts of collective intelligence to reach inside an organization and discover what’s really going on. Asuret applies sentiment-analysis techniques to uncover perception gaps and measure the extent of mismatched expectations among organizational silos and even among individuals.

Although Asuret’s techniques are generalizable to a range of business situations and problems, a core focus is reducing waste associated with troubled IT projects. To accomplish this goal, the company measures projects against a “profile” that describes common reasons IT projects get into difficulty. The profile addresses issues such as business planning, change management, executive sponsorship, stakeholder engagement, and similar fundamental aspects of running a successful project or initiative.

To measure the degree to which vulnerability drivers are present on a project, for example, Asuret asks stakeholders to evaluate simple indicators that describe aspects of the organizational environment. The following illustration shows one of these indicators:

Asuret aggregates these indicators to create a large dataset, from which it derives inferences about the business initiative under consideration. By decomposing this data differently from the way in which it was collected, Asuret reports expectation- and alignment-mismatches across information silos in areas such as IT vs. finance; system integrator vs. internal departments; and so on.

This screen summarizes perception differences between executive management and IT with respect to a particular project’s business case. Quantifying this information allows project stakeholders to use data-driven metrics as a reference for achieving consensus during team discussions:

In addition to identifying gaps among organizational departments and silos, Asuret’s measurement techniques also reveal areas where decision makers should apply training and other support resources, as this illustration shows:

My take. Organizations can improve decision-making and reduce IT failures by applying tools, techniques, and processes that increase information transparency. Quantitative techniques are beneficial by helping create data points against which organizations can prioritize issues, achieve consensus, and therefore make decisions more rapidly.

Discussing these issues, MIT Sloan Management Review says:

Our own research suggest that fewer than 20% of global companies have sufficient capacity to spot, interpret and act on the weak signals of forthcoming threats and opportunities.

And that, folks, is precisely why these techniques are important.

[Disclosures: As CEO of Asuret, I am working with fellow ZDNet blogger, Dion Hinchcliffe to apply these concepts to the Pragamatic Enterprise 2.0 initiative, which Paul Greenberg reviewed on ZDNet. Photo from Wikipedia Commons and colorized by Michael Krigsman.]

In a post today. ZDNet open source blogger, Dana Blankenhorn, says the primary value of open source software is transparency rather than low cost. He then argues that open source software offers at least a partial solution to the problem of IT failures. Let’s examine that view.

Dana argues that open source code transparency aligns the interests of customers and vendors, which can have a positive effect on IT project outcomes:

With code visibility, you and your vendors become partners in trying to make something work. The vendor can’t over-promise, but you can’t over-assume either. This may be one of main hidden reasons for IT failure, the two sides of the transaction not being on the same page.

From an IT failures perspective, this logic consists of two primary components:

1. Shared visibility into open source code reduces hidden assumptions and makes explicit what the vendor is actually selling to the customer.
2. Such transparency can reduce failure by forcing alignment between vendor and customer goals.

Although Dana raises an interesting and important question, I do not share his confidence that implementation projects based on open source software should more successful than those based on commercial software.

In my experience, most failures associated with packaged software arise from expectation mismatches in the business, rather than technical, domain. Custom software development projects are even more complicated, since these situations include creating something that does not yet exist.

This diagram summarizes my view regarding why many IT projects that are late, over-budget, or don’t deliver planned results:

As you can see, the primary problems are organizational in nature; failure is rarely due primarily to code or technology. In addition, we cannot ignore basic differences in the vested interests of vendors and customers. The Devil’s Triangle concept explains the large role of conflicts of interest in driving failed projects.

To uncover the true reasons project fail, I suggest looking at poor judgment, politics, and personal agendas. Yes, it’s ugly, but sometimes the truth is just not pretty. I wish we could rely on open source to help improve project success rates, but I just don’t see it.

Sound off with your view — can open source prevent failed IT projects?

[Image from iStockphoto]