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 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 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 »

January 29th, 2010

'Pain chains' and the IT Devil's Triangle

Posted by Michael Krigsman @ 7:39 am

Categories: CIO issues, Cultural issues, Devil's Triangle, IT issues, Politics, Vendor relationships

Tags: Software, Information Technology, Failure, Triangle, Devil, Sales Strategy, Tools & Techniques, Strategy, Sales, Management

The IT Devil’s Triangle binds together enterprise customers, technology vendors, and system integrators in an unholy trinity that leads directly to failed projects. These failures are fraught with “pain chains,” a term used by Altimeter Group partner and enterprise strategy analyst, Ray Wang, to describe clusters of difficulty that cause angst between IT customers and their line of business counterparts.

The pain chains concept recognizes that the organizational impact of IT failure is multi-dimensional. Similarly, the Devil’s Triangle states that broad, rather than narrow, conflicting agendas among the trinity of customers, vendors, and integrators cause failure.

• Related: Exploring the Devil’s Triangle

The shared themes of interdependence, shared responsibility, and impact characterize both pain chains and the Devil’s Triangle. Therefore, I view large, serious IT failures as a constellation of dysfunctional activities that come about from overlapping, conflicting, and distorted relationships.

In some cases, inexperienced customers bring higher cost and waste upon themselves through sheer mismanagement of their own affairs. Other times, unscrupulous external consultants or software vendors take advantage of the customer’s lack of experience.

Either way, in the aftermath of failure it’s tempting and easy to unfairly shift blame onto one party or another; however, such finger pointing often ignores shared and inter-dependent causes of failure.

Here are three examples that illustrate no-win situations spawned by the Devil’s Triangle:

1. Software vendor’s sales person promises something the software actually can’t do.

Potential solution: Directly ask the software vendor for specific examples of organizations where it has successfully deployed the features in question. If you’re buying software based on certain key features, perform plenty of due diligence on that particular functionality. Unfortunately, it’s sometimes a practical impossibility to learn the truth about specific points of reliability until after you have bought the product.

2. System integrator makes technical scoping errors that remain undiscovered until mid-project.

Read the rest of this entry »

December 28th, 2009

SOA adoption: The human face of governance

Posted by Michael Krigsman @ 6:08 am

Categories: CIO issues, Cultural issues, Governance, IT issues, Interview, Podcast, Project strategy, SaaS, PaaS, and SOA

Tags: Project, Information Technology, Business, SOA, KPI, Technology, Service, Organization, Michael, Dion

Human and organizational factors such as politics, information silos, and change management generally underlie IT success and failure.

During a recent conversation, IT analyst and fellow ZDNet blogger, Dana Gardner, affirmed the extent to which this view applies to service-oriented architecture (SOA) projects.

I asked Dana to elaborate on the importance of organizational dynamics with respect to SOA governance and adoption:

In the many discussions we’ve had with analysts, users and suppliers over the advancement of SOA and governance, we always came back to the human element as a weak or missing link. Successful adoption and efficiency of SOA hinges on acceptance, trust, collaboration and news ways for people to work together. SOA also depends on people and groups that had not in the past worked closely to begin doing so.

When I heard more about Asuret and Pragmatic Enterprise 2.0 [my professional involvements], I saw a unique way to bring the human element of SOA into focus. The process of gathering perceptions across teams and any affected people — with trend lines over time for those — really strikes me as essential to understand how and why SOA is working — or not.

I think that SOA efforts will gain significant tools for how to gauge and assuage the progress of SOA adoption, and the best means of governance over long periods of time once SOA activities gain traction.

Dana also highlighted the gap between technical and human governance issues:

SOA governance goes a great job at tracking artifacts and defining and automating rules and policies for artifacts. The role of IT infrastructure can be managed via SOA governance, and the composition and business process alignment of services are also well served by governance. But how people really feel about how the processes are development, implemented and refined is a bit of a block hole when SOA governance is employed. Without a strong view of the perceptions and their change patterns, SOA and governance are obtuse rather then precise instruments.

Following our discussion, Dana brought together a group of top SOA analysts to examine these issues in depth.

This post reprints, in its entirety, Dana’s article on that analyst session. You can listen to the podcast by clicking the player at top of this post.

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

Listen to the podcast. Find it on iTunes/iPod and Podcast.com. Read a full transcript or  download a copy. Charter Sponsor: Active Endpoints. Also sponsored by TIBCO Software.

Welcome to the latest BriefingsDirect Analyst Insights Edition, Vol. 47. Our topic this week on BriefingsDirect Analyst Insights Edition centers on how to define, track and influence how people actually adapt to and adopt technology.

Any new information technology might be the best thing since sliced bread, but if people don’t understand the value or how to access it properly — or if adoption is spotty, or held up by sub-groups, agendas, or politics — then the value proposition is left in the dust. Perceptions count … a lot.

A crucial element for avoiding and overcoming social and user dissonance with technology adoption is to know what you are up against, in detail. Yet, data and inferences on how people really feel about technology is often missing, incomplete, or inaccurate.

Read the rest of this entry »

December 17th, 2009

User adoption: Killer app for SOA and Enterprise 2.0

Posted by Michael Krigsman @ 12:53 pm

Categories: CIO issues, Cultural issues, Enterprise 2.0, Failure 2.0, Governance, IT issues, SaaS, PaaS, and SOA

Tags: Killer Application, Adoption, SOA, Enterprise 2.0, Enterprise Implementation, Dana, Service-Oriented Architecture (SOA), Web Services, Middleware, Enterprise Software

Although geeky eggheads may become enamored by cool technology, real users care about solving practical, day-to-day business problems. We call that adoption.

Stated differently, satisfied users adopt; those who do not experience sufficient value walk away.

Adoption matters a great deal to both service-oriented architecture (SOA) and Enterprise 2.0 projects. Unlike traditional enterprise software implementations, success in these areas is determined by much more than project management metrics.

• Related: The Human Condition Causes Metric Problems for SOA, Enterprise 2.0
• Related: Applying metrics to enterprise services, or simply getting people to work together
• Related: The psychology of project management via Pragmatic Enterprise 2.0 and SOA

Organizations generally evaluate traditional enterprise software deployments based on time, cost, and achieving planned project goals. An enterprise implementation is usually deemed successful when it meets targets related to these three parameters.

In contrast, most practitioners consider user adoption to be a key measure of SOA and Enterprise 2.0 success. These initiatives only achieve success when users find them sufficiently compelling to spend the time and effort needed to engage.

SOA analyst, Dana Gardner, explains the difficulty in adoption, especially with new technologies. Dana describes challenges associated with measuring the “soft” drivers behind user adoption:

Read the rest of this entry »

December 2nd, 2009

Complexity vs. goodness in IT failure

Posted by Michael Krigsman @ 7:03 am

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

Tags: Accounting, Information Technology, Team Management, Strategy, Operational Accounting, Financial Services, Management, Finance, Michael Krigsman

Stories about failed IT projects often describe convoluted and confusing situations that are difficult to sort out and understand. This confusion and lack of clarity arises from two primary causes: unclear strategic goals or inability to bring together the moving parts that comprise project execution.

It’s surprising that many teams start projects without a clear understanding of the end game and goals they are trying to achieve. A family-friendly blog such as this won’t be mean-spirited and say these folks have their head up you know where.

Successful strategy brings clarity (and relevance) of purpose, while solid project execution means managing people, teams, and stakeholder groups each with its own unique definition of success. For example, IT may seek high project throughput while the accounting department demands more software features. These goals are in conflict.

This simple diagram illustrates the point mapped to a scale of complexity and goodness:

On one level these points are simplistic and obvious. However, there’s a large gap between our ability to understand these simple concepts and then apply them to real world situations. That’s why so many projects fail.

[Inspired by The Simplicity Cycle by Don Ward. For more of this logic, also see Choices = Headaches by Joel Spolsky. Thanks to Dermot Casey on Twitter for pointing me to the Ward book. Diagram by Michael Krigsman.]