November 18th, 2009

Salesforce Chatter: Something to talk about

Posted by Michael Krigsman @ 5:56 pm

Categories: CIO issues, CRM, Enterprise 2.0, IT issues, Salesforce.com

Tags: Salesforce.com Inc., Social Computing, Chatter, PROJECT FAILURES ANALYSIS Salesforce, Sales Force Management, Social Networking, Sales, Online Communications, Marketing, Advertising & Promotion

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:

Read the rest of this entry »

November 18th, 2009

Dreamforce: Quick first impressions

Posted by Michael Krigsman @ 10:48 am

Categories: CIO issues, CRM, Enterprise 2.0, IT issues, SaaS, PaaS, and SOA, Salesforce.com

Tags: Salesforce.com Inc., Sales Force Management, Sales, Michael Krigsman

Sitting here in the audience at the annual Dreamforce conference of Salesforce.com, a couple of quick impressions come to mind. This post is mid-stream during the first keynote speech, so there will be more later.

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

November 16th, 2009

Resistance to change: The real Enterprise 2.0 barrier

Posted by Michael Krigsman @ 10:29 am

Categories: CIO issues, Cultural issues, Enterprise 2.0, Failure 2.0, Governance, IT issues, Project strategy, Research and statistics

Tags: Barrier, Enterprise 2.0, 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:

Read the rest of this entry »

November 9th, 2009

Enterprise unplugged: Riffing on failure and performance

Posted by Michael Krigsman @ 7:39 pm

Categories: CIO issues, CRM, Cultural issues, Governance, IT issues, Project strategy

Tags: Performance, Outcome, Naomi Bloom, Nenshad Bardoliwalla, Nenshad, Podcasts, Performance Management, Business Intelligence, Financial Accounting, Enterprise Software

My favorite part of blogging is the opportunity to learn from fascinating people who are at the top of their game. I recently chatted about enterprise issues and IT failure with Naomi Bloom and Nenshad Bardoliwalla, two articulate folks whose expertise is matched only by their willingness to share what they know.

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.

Read the rest of this entry »

November 6th, 2009

18 truths: The long fail of complexity

Posted by Michael Krigsman @ 5:55 am

Categories: CIO issues, Cultural issues, Governance, IT issues, Project strategy, Research and statistics

Tags: Accident, Failure, Enterprise System, Richard Cook, Complex System, Human Practitioner, Policies And Procedures, Human Resources, Michael Krigsman

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.

Read the rest of this entry »

November 2nd, 2009

Five definitions toward the maturing of Enterprise 2.0

Posted by Michael Krigsman @ 7:14 pm

Categories: CIO issues, Enterprise 2.0, Enterprise 2.0 Conference, Enterprise2conf, IT issues, SaaS, PaaS, and SOA

Tags: Apple iPod, Fragmentation, Enterprise 2.0, Conference, Miko, Enterprise, Michael Krigsman

The excellent Enterprise 2.0 Conference is currently in full swing in San Francisco. Given the excitement around this conference, now’s a perfect time to re-examine the “enterprise” part of Enterprise 2.0.

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.

Read the rest of this entry »

November 2nd, 2009

Seeking IT failure experts on Twitter

Posted by Michael Krigsman @ 6:22 am

Categories: Blog annoucements, CIO issues, IT issues

Tags: Twitter Inc., Information Technology, Strategy, Management, Michael Krigsman

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]

November 1st, 2009

Amplifying 'weak signals' for IT success

Posted by Michael Krigsman @ 3:29 pm

Categories: CIO issues, Collective intelligence, Cultural issues, Enterprise 2.0, Governance, IT issues, Project strategy, Risk, Tools

Tags: Technique, Information Technology, Organization, Asuret, Productivity, Michael Krigsman

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:

Read the rest of this entry »

October 26th, 2009

Can open source software stop IT failure?

Posted by Michael Krigsman @ 9:19 am

Categories: CIO issues, Devil's Triangle, IT issues, Open Source, Project strategy

Tags: Software, Information Technology, Open-source Software, Failure, Dana, Custom Software Development Project, Devil, Tools & Techniques, Open Source, Strategy

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:

Read the rest of this entry »

October 26th, 2009

Learning from the weak signals of failure

Posted by Michael Krigsman @ 6:13 am

Categories: CIO issues, Collective intelligence, Governance, IT issues

Tags: Project, Dilbert, Chris, Leadership, Blogging, Management, Internet, Michael Krigsman

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.

Still, this experience is sufficiently widespread that it appears in a Dilbert cartoon. Wally asks Dilbert, “How’s your project coming along?” Dilbert replies, “It’s a steaming pile of failure. It’s like fifteen drunken monkeys with a jigsaw puzzle.” When the boss asks, “How’s your project coming along?” Dilbert responds sardonically, “Fine.”

This Dilbert interchange expresses a fundamental truth for understanding failed projects: in most cases, someone associated with the project knew in advance about impending difficulty. For example, an engineering manager might realize early in the project that his team will not be able to achieve certain milestones on time.

Similarly, consider the game of project failure chicken. Management sets an unrealistic product ship date, which the Engineering and Design groups, for example, each know is impossible to meet. Since neither group wants to appear weak, they both tell management the schedule is workable, each hoping the other will admit defeat first. In project failure chicken, neither group wants to yield to the other, leading to the worst possible outcome for management.

In these examples, accurate knowledge about the true state of the project is present inside the organization, yet remains hidden from management because it is diffuse and unfocused.

If denial is the handmaiden of failure, then acknowledgment can be a strong harbinger of success. But what, precisely, should we acknowledge?

• Related: Denial: The secret IT killer

Respected CIO leadership expert, Chris Curran, addresses this question in a blog post about the concept of finding weak signals:

[M]aybe we are ignoring some fundamental, but less obvious signs that our projects are not positioned for success. These signs, or weak signals, require different mindsets and toolsets to gather, track and act upon.

Chris’ comments responded to an article in the MIT Sloan Management Review titled, How to Make Sense of Weak Signals, which offers this definition of weak signals:

A seemingly random or disconnected piece of information that at first appears to be background noise but can be recognized as part of a significant pattern by viewing it through a different frame or connecting it with other pieces of information.

The article goes on to summarize the key challenge:

There is a major difference between taking in signals and realizing what they mean. Managers as well as organizations tend to see the world in a certain way and confuse their mental maps with he territory. Weak signals that don’t fit are often ignored, distorted or dismissed, leaving the company exposed.

An upcoming blog post will explore this issue further and describe the efforts of several firms to address the problem.

[Photo from Wikipedia Commons.]