IT Project Failures

March 9th, 2010

Six ways CRM projects go wrong

Posted by Michael Krigsman @ 8:05 pm

Categories: CIO issues, CRM, Cultural issues, IT issues

Tags: Project, Project Failure, CRM, Customer Relationship Management (CRM), Enterprise Software, Software, Michael Krigsman

CRM projects have earned a notorious reputation for being difficult and expensive. Despite endless statistics and discussion of the topic, many of these projects come in late or over-budget.

• Related: Three big reasons CRM initiatives fail

For this reason, I was delighted when Laurence Buchanan sent me an unsolicited article he wrote that dives under the surface to explain why CRM projects fail.

Laurence heads up CRM in the UK for Capgemini (cross industry and vendor agnostic) and has been in that role for the last 12 months. Previously, he spent 10 years at SAP and was VP CRM. As you can see from his background, Laurence certainly has the chops to teach us something new about CRM projects and why they don’t always go as planned.

Laurence wrote this guest post and supplied all the images below.

================

The first generation of CRM saw many failed projects. Some analysts reported failure rates as high as 60%.  Since then, as an industry, we have learned much about the causes of CRM failure and while most projects are still tough, success rates have soared.

CRM is tough to get right. I’ve been involved in around 200 projects and I have never seen a project succeed that has not grappled with difficult issues like cultural change, performance and incentives, or integration. Some of the major reasons for project failure, like lacking executive sponsorship, ignoring change management or failing to deal with basics like data quality have been well documented. I don’t aim to repeat what has already been said.

Read the rest of this entry »

March 9th, 2010

IT failure: A shameful story

Posted by Michael Krigsman @ 5:11 pm

Categories: CIO issues, Governance, IT issues

Tags: Project, Information Technology, ERP, Failure, Enterprise Resource Planning (ERP), Strategy, Enterprise Software, Software, Management, Michael Krigsman

Vinnie Mirchandani wrote a blog post that reminded me why studying IT failures is important. Please read this story carefully:

[O]ne of the darkest moments in my career came a few years ago when I was visiting the chief executive of a well-known institution. They were about to start an ERP project but he might as well have been a man headed for the gallows. Head hung low - all he could talk about how much of an overrun he needed to prepare his organization for. And his project had not even started. I felt sick - never felt so un-proud of my chosen profession. I could not give him much hope that his pessimism was unjustified. Even after the experience of hundreds of thousands of ERP and other enterprise projects, they fail at alarmingly high rates.

Is there any other industry where we routinely accept 30-70 percent rates of failure? If you can think of one, please let me know.

[Photo from iStockphoto.]

March 8th, 2010

The IT failures blame game (part 2)

Posted by Michael Krigsman @ 4:55 pm

Categories: CIO issues, Consulting, Cultural issues, Governance, IT issues, Project strategy, Vendor relationships

Tags: Project, Information Technology, Failure, IT Devil, Triangle, Strategy, Management, Michael Krigsman

This post is part two of a series on the role of blame in IT failures. Please read part 1 now.

Placing blame accurately. The IT Devil’s Triangle explains that all major participant groups share responsibility for project success in a balanced way. However, some observers apportion blame for failure unequally among Devil’s Triangle participants. Unbalanced distribution might make sense when analyzing specific projects, but it becomes misleading when applied as a general guiding principle.

As the Devil’s Triangle principle makes clear, one-sided generalizations apportioning blame are rarely accurate. In my experience, having written about 800 blog posts on the subject, causes of success and failure are typically shared among the three parties.

To understand the customer dynamic, let’s turn to Todd Williams, an IT failures turnaround specialist currently writing a detailed book on recovering failed projects. In a post called Blame the Customer, Todd presents a reasoned description about the role of technology customers in contributing to failed IT projects:

I am always amazed how people on failing projects neglect to look at their own issues prior to blaming someone else. Yes, blame is easy and on red projects since no wants to be the source of the issues. The truth is, everyone is at blame, so before bringing in an auditor or recovery manager, tidy up your house first.

To be clear, I am not suggesting that customers deserve more blame than either technology vendors or system integrators. Project success only happens when all three groups work together effectively.

In another of his posts, Todd discusses the role of trust in overcoming negative relationships spawned by Devil’s Triangle tensions and conflicts:

When looking at the aggregation of failed projects, vendors, customers, and integrators share culpability. Commencing a recovery (or a project, for that matter) with anything but an objective view of the genesis of failures, or their corrective actions, is counterproductive. Every project is different and, in the course of recovering a number of them, no single party has come out the winner for contributing to failure. To be sure, as many projects fail for customer ineptness, arrogance or any other problem, as there are that fail for the same reasons in vendors and integrators. Starting any action with blame only breeds mistrust.

Hence, blame serves no purpose.

In my experience studying IT failures, objections to the IT Devil’s Triangle typically come from those using blame as tool to further their own personal interests or political agenda.

These arguments against the Devil’s Triangle usually come from two camps:

Read the rest of this entry »

March 8th, 2010

The IT failures blame game (part 1)

Posted by Michael Krigsman @ 4:48 pm

Categories: CIO issues, Cultural issues, Devil's Triangle, Governance, IT issues

Tags: Game, Information Technology, Project Failure, IT Devil, Triangle, Strategy, Management, Michael Krigsman

This is part one in a series on understanding blame in IT failures. Please also read part two.

Few subjects are as controversial, emotionally charged, and fraught with misunderstanding as establishing blame for failed IT projects. Unfortunately, because of high costs associated with IT failures, some folks use misplaced blame as a competitive weapon to gain negotiating or political advantage.

Of course, no one wants responsibility for causing the large economic losses and associated legal risks that arise from failed IT projects. Therefore, project participants often use blame to obscure the truth of why projects really fail, hoping to redirect responsibility from themselves by shifting fault to others.

Since finger pointing plays a central role in obscuring the true causes of failure, the study of blame is a worthwhile topic for discussion.

The IT Devil’s Triangle. Enterprise implementation projects virtually always involve three parties: customer, technology vendor, and system integration consulting firm. We call this triad the IT Devil’s Triangle, because relationships among these participants simultaneously involve shared goals mixed with conflicts of interests.

• Related: Exploring the Devil’s Triangle

These relationships become dysfunctional when project participants focus on their own goals to the detriment of shared project objectives. From this perspective, we can say that late and over-budget projects result when competition overrides cooperation among project participants:

The Devil’s Triangle explains how economic pressures can drive software vendors and system integrators to act in ways that do not serve customer interests. It also offers insight into the ways some enterprise software customers damage their own projects.

Projects succeed or fail based on how Devil’s Triangle participants manage built-in tensions among themselves. The likelihood of success increases when the three groups align their individual goals and expectations in a spirit of cooperation and mutual benefit. Conversely, implementations fail when greed, inexperience, or arrogance emerge as prominent motivations and one party attempts to gain unreasonable advantage of another.

In his book Why New Systems Fail, project failures expert and author, Phil Simon, explains why the Devil’s Triangle is a powerful tool for parsing relationships on IT projects:

Read the rest of this entry »

March 1st, 2010

The twin evils of IT gridlock and denial

Posted by Michael Krigsman @ 5:17 am

Categories: CIO issues, IT issues, Project management, Project strategy

Tags: Denial, Team, Information Technology, IT Project, Mitch, Team Management, Human Capital Management, Management, Human Resources, Workforce Management

Gridlock and denial are among the most significant and common problems on many IT projects. These phenomena are related to insufficient degrees of consensus among participants on a project team. As I talk with folks working on enterprise software deployments, this topic often seems to resonate strongly as a major obstacle to success.

IT projects are obviously not the only area of human interaction where questions of consensus arise. An article by SugarCRM’s Vice President of Strategic Solutions, Mitch Lieberman, on the “Standing Ovation Problem,” which he pulled from an academic paper of the same title, inspired this post.

Mitch describes the Standing Ovation Problem:

Stated simply, a standing ovation is at the end of a lecture, presentation or performance (stage or athletic) certain members of the audience stand up and clap for a long(er) duration, which leads to other audience members doing the same. While a 10 year old might be able to explain what it is (mine did); why it happens is another issue altogether.

Reading this, it seemed evident the Standing Ovation Problem is connected consensus and “group think,” a topic that is strongly associated with virtually every IT failure.

Without sufficient consensus on key project issues, two bad problems often arise:

• Gridlock: Project progress stops, due to lack of consensus or agreement on the best steps forward. In gridlock situations, the team cannot reach agreement, so project decisions slow down while everyone fights it out.
• Denial: Project progress continues, despite lack of consensus. In denial situations, the team does not address disagreements, agreeing to wait until sometime in the future to resolve open issues. Problems then simmer below the surface only to “unexpectedly” erupt later, usually in more severe form.

Unable to gain team agreement, decision makers often have little choice but to accept project delays in the present or ignore problems by pushing decisions into the future.

In my experience, gridlock and denial among the most pernicious and subtle causes of IT project failures.

Read the rest of this entry »

February 26th, 2010

Six failures from poor application quality

Posted by Michael Krigsman @ 7:32 am

Categories: Availability and reliability, CIO issues, IT issues

Tags: Application Quality, Performance Problem, Software Development, Help Desk, Performance Management, Investment, Software/Web Development, It Operations, Finance, Michael Krigsman

The endless catalog of IT failure rests on a foundation of poor judgment, inadequate communication across business groups and information silos, and conflicting agendas. Most of my blogging discusses what happens when these human failings intersect IT projects.

Although human issues are critical, downtime and other problems also arise from highly technical causes of failure. Interestingly, there is often a human dimension even when problems are rooted in technology.

To explore this topic, I asked Dr. Bill Curtis, SVP & Chief Scientist of CAST Software, to write a guest post linking common causes of failure to business outcomes.

Bill is one of the world’s foremost authorities on software development process and improvement. He is best known for leading development of the Capability Maturity Model (CMM), a global standard for evaluating the capability of software development organizations. You may not recognize his name, but almost certainly, you’ve interacted with applications developed using processes he pioneered.

———

Most organizations wait until an embarrassing disaster strikes before even considering the link between application quality and business benefit. Although these same companies can quantify the costs of failure, they still struggle to build a business case justifying proactive investment in application quality, which can prevent these embarrassments.

To help stimulate a discussion about risk and reward in preventing failure, this post presents the top six ways that poor application quality affects business.

Read the rest of this entry »

February 24th, 2010

Curse of the IT prima donna

Posted by Michael Krigsman @ 8:26 am

Categories: CIO issues, Cultural issues, IT issues, Project management

Tags: Team, Information Technology, Team Management, Human Capital Management, Management, Human Resources, Workforce Management, Michael Krigsman

IT failures don’t happen magically out of thin air. No, failure is a team sport that usually involves unspoken complicity among both management and the ordinary folks working on a project. In other words, there’s plenty of blame to go around in most failures.

Although we often focus on management as major contributor to failed projects, sometimes disruptive or agenda-ridden team members are primarily to blame. As an example, read this Dilbert cartoon:

A benign and reasonable executive applies budget savings from one completed project to a second that is still in-progress. The person managing the completed initiative throws a hissy fit, is unwilling to share her budget, and even resists helping the troubled project.

THE PROJECT FAILURES ANALYSIS

We all know project prima donnas — folks whose apparent skill is matched only by their poor attitude and arrogance. These self-serving people are a plague we tolerate only out of necessity.

Here are three tips for dealing with prima donnas on your team:

Read the rest of this entry »

February 22nd, 2010

Social networking: Influence, followers, and 'nexus leaders'

Posted by Michael Krigsman @ 7:40 am

Categories: CIO issues, CRM, Enterprise 2.0

Tags: Influence, Network, Twitter Inc., Leader, Tweetlevel, Social Networking, Online Communications, Marketing, Advertising & Promotion, Michael Krigsman

Many social networking services, such as Twitter and Facebook, present so-called “connection” or “follow” relationships as public statistics, hoping to motivate (or manipulate) higher usage among participants.

Social media users in the enterprise often consider these connection and follow metrics helpful to determine the relative importance (or influence) of social networking participants. For example, a CIO using Twitter to raise the external profile of his organization may naturally reach out to users with the highest follower count.

The large number of tools that measure influence on Twitter points to a general fascination in this topic. However, a growing body of thought suggests that follower count alone is not a meaningful measure of influence or importance.

Tweetlevel, developed by Jonny Bentwood of Edelman PR, is one of the most sophisticated Twitter measurement tools. It considers a range of factors that go far beyond mere follow counts. In addition to an overall score, Tweetlevel reports on user’s influence, popularity, engagement, and trust.

This image shows the formula Tweetlevel uses to determine overall scores:

Bentwood, who is an analyst relations professional, applied Tweetlevel scores to rank 500 industry analysts on Twitter, based on both influence and engagement scores. From Bentwood’s perspective, obviously, an analyst’s level of engagement with other Twitter users is a highly significant variable.

Read the rest of this entry »

February 16th, 2010

IT failure? Blame your CEO.

Posted by Michael Krigsman @ 8:18 am

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

Tags: CIO, Priest, Information Technology, Business, CEO, Strategy, Management, Michael Krigsman

There is no simple formula for achieving success on business transformation projects such as large IT initiatives. One primary reason these projects are complex is because they cross organizational boundaries and departments.

Most discussions about IT failure highlight project management tasks and budget control as key determinants of project outcomes. In a departure from traditional thinking, however, two recent articles emphasize the CEO’s role in determining the outcome of IT initiatives.

Information Week’s Bob Evans raised this issue in a piece about Mark Hurd, CEO of Hewlett-Packard:

But I want to focus on a startling correlation [Hurd] made about the role that customer-side CEOs play in situations where a company’s IT is bloated, backward, expensive, and ineffective:

“Because I’ll tell you, I don’t know how many CEOs are in the audience here, but when you show me bad IT—and I meet a lot of CEOs, and do a lot of talks in front of CEOs—and I get a lot of CIOs who tell me how bad their IT is. My first reaction—to be very frank—is it’s probably a bad CEO, as opposed to bad IT.”

Along the same lines, SAP consultant, Caroline Olsen, wrote an impassioned (and somewhat bitter sounding) plea for CEOs to take their own projects more seriously:

Read the rest of this entry »

February 15th, 2010

Social CRM and enterprise business

Posted by Michael Krigsman @ 7:15 am

Categories: CIO issues, CRM, Cultural issues, Video interview

Tags: Enterprise 2.0, CRM, Social CRM, Customer Relationship Management (CRM), Enterprise Software, Software, Michael Krigsman

Last week, I attended a two-day seminar on Social CRM, sponsored and led by industry guru Paul Greenberg, who also writes for ZDNet. The event, held just outside Washington DC, brought together many top Social CRM thought leaders to interact and mingle with 14 different software vendors.

The seminar coincided with a major snowstorm and blizzard, stranding most participants in the hotel for an unexpected day of airline cancellations, business discussions, and musing on the state of Social CRM.

Social CRM is part of a constellation of technologies and business strategies arising from the intersection of Internet-based consumer technologies with enterprise business goals and requirements. Related terminology and concepts include Enterprise 2.0 and social business.

In a seminal blog post on the subject, Paul Greenberg defines Social CRM this way:

CRM is a philosophy & a business strategy, supported by a technology platform, business rules, workflow, processes & social characteristics, designed to engage the customer in a collaborative conversation in order to provide mutually beneficial value in a trusted & transparent business environment. It’s the company’s response to the customer’s ownership of the conversation.

As a school of thought, Social CRM recognizes that current technologies enable customers spontaneously to form large, ad hoc interest groups at remarkable, sometimes even viral, speed. The reality of large, self-aware customer power blocs forces companies and organizations to rethink important aspects of their customer relationship strategies.

We are still in the early stages of social business thinking and proliferation. For this reason, certain grandstanding bloggers, analysts, and self-appointed enterprise pundits occasionally speak out vociferously and negatively about these trends.

Please recognize such negativity as little more than transparent chest thumping from those who seek personal attention by espousing extreme and contrary positions.

Do not be taken in by misguided, self-serving, and shortsighted chest thumpers.

Read the rest of this entry »