Category: Governance
November 16th, 2009
Resistance to change: The real Enterprise 2.0 barrier

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:
November 9th, 2009
Enterprise unplugged: Riffing on failure and performance
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.
November 6th, 2009
18 truths: The long fail of complexity

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.
November 1st, 2009
Amplifying 'weak signals' for IT success

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:
October 26th, 2009
Learning from the weak signals of failure

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.]
October 4th, 2009
Scholarly interest in IT failure and waste
The non-technical academic world has become interested in ethical issues surrounding IT failure and wasted resources. Previously, academics that focused on this set of problems generally came from an IT or project management background.
I’m thrilled the non-technical academic community is examining IT failure. Considering both public- and private-sector IT projects, the scope and magnitude of failure is huge.
On Monday, October 5, 2009, I’m giving a talk on this topic for the Center for Global Business Law & Ethics at Suffolk University’s Sawyer Business School in Boston. Professor Lydia Segal, who coordinated this program, is a top authority on cutting public and private sector waste. She therefore has a natural interest in this subject:
Ethical considerations demand that we turn our attention to areas in business where mismanagement may cause serious waste. Given the importance of IT to both business and society, there is opportunity for researchers to explore the roots of failure and to formulate directions for improvement.
I’ve embedded the presentation below. Please let me know what you think.
September 17th, 2009
7 fundamentals of IT project success
Many folks think large projects usually fail for technical reasons–software that doesn’t work as advertised, bugs, and so on. In reality, that’s not the case.
In my experience, the most serious project issues come down to misplaced expectations among participants. Fundamentally, problems in human communication lie at the root of most failures.

These expectation and communication mismatches are difficult to detect systematically, because they aren’t quantitative or technical in nature. Failures persist despite fancy project management methodologies, precisely because traditional approaches do not isolate and address hidden problems.
These seven points of project success touch on conflicting agendas, multiple perspectives, and a broad range of business-oriented conditions that drive projects to succeed or fail:
September 7th, 2009
The taboo of failure

Business transformation initiatives that fail to accomplish key objectives generally suffer from two problems:
- The failed projects do not achieve whatever plans the organization anticipated. This is obvious.
- However, these projects also waste time, money, resources, drain morale, and generally contribute negatively to the organization and its people. Recriminations and lack of consensus come about when an organization does not know how to fail gracefully.
Since failure is a taboo subject of discussion in modern business, it’s no surprise that graceful endings are decidedly uncommon. Since this taboo is a function of human interaction in collaborative environments (ie: business and government), the problem is widespread.
Addressing a London audience in July 2008, then Treasury Secretary, Henry Paulson, spoke directly about this issue. Although his comments refer to financial markets, they are completely applicable to the IT failures we see everywhere. The New York Times quotes Paulson:
September 7th, 2009
Exploring the Devil's Triangle

The Devil’s Triangle describes a basic set of dysfunctional relationships that push many projects toward failure. Although I’ve written about many facets of this important topic previously, today’s post summarizes the issue succinctly.
Three parties participate in virtually every major software deployment: the customer, system integrator or consultant, and the software vendor. Since each of these groups has its own definition of success, conflicts of interest rather than efficient and coordinated effort afflict many projects.
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.
Devil’s Triangle relationships are a short sighted and self-interested way of life for too many participants in the enterprise technology landscape.
August 20th, 2009
Video: Five reasons to kill IT projects
ZDNet’s sister site, Tech Republic, created a great video describing the right reasons to terminate failing IT projects. It’s based on my post of the same name and narrated by Jason Hiner, Tech Republic’s Editor-in-Chief.
- Related blog post: Five reasons to kill IT projects
The video offers a hard-hitting, insider’s view of IT failures. To view it now, click the image below.
Michael Krigsman is CEO of Asuret, Inc., a software and consulting company dedicated to reducing software implementation failures. Click here to discuss this post with him on Twitter. See his full profile and disclosure of his industry affiliations.
Subscribe to IT Project Failures via Email alerts or RSS.
SponsoredWhite Papers, Webcasts, and Downloads
- Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now
- VMware Infrastructure: A Guide to Bottom-Line Benefits VMware Frustrated by the costs of maintain ever larger data centers?or building ... Download Now
- Three Steps You Need to Know to Stop Data Loss Varonis Sensitive data exposed to misuse or loss... it is the stuff of nightmares ... Download Now
Recent Entries
- Update on the Enterprise Irregulars
- The ’social enterprise’ comes of age
- Social computing in the enterprise, part two
- Social computing and the enterprise, part one
- Salesforce Chatter: Something to talk about
Blogs From Our Sponsors
Most Popular Posts
- 18 truths: The long fail of complexity
- Resistance to change: The real Enterprise 2.0 barrier
- Dreamforce: Quick first impressions
- Enterprise unplugged: Riffing on failure and performance
- Five definitions toward the maturing of Enterprise 2.0
- Salesforce Chatter: Something to talk about
Top Rated
- 18 truths: The long fail of complexity+17 votes
- Learning from the weak signals of failure+6 votes
- Five definitions toward the maturing of Enterprise 2.0+6 votes
- The 'social enterprise' comes of age+2 votes
- Salesforce Chatter: Something to talk about+2 votes
- Resistance to change: The real Enterprise 2.0 barrier+2 votes
- Enterprise unplugged: Riffing on failure and performance+2 votes
- Social computing and the enterprise, part one+1 vote
Premier Vendor Content Whitepapers, webcasts & resources from our Power Center Sponsors
- The best support in the Linux business
-
If Linux is going to power your mission-critical applications, you'd better have the best support known to business. Novell was rated the top provider of Linux technical support.

- Learn more >>
- Keep Up With The Latest In Document Management with The DocuMentor.
-
Doc delivers the scoop on today's enterprise content management, printer maintenance, and all other issues related to document management. It's the DocuMentor Blog.
- Learn more >>
- Reduce risk. Reduce complexity. Increase reliability.
-
A simplified IT environment isn't just less complex. It's also more reliable. Standardize on a single Linux platform with SUSE Linux Enterprise from Novell, and get the world's most interoperable Linux

- Learn more >>
- Reduce risk. Reduce complexity. Increase reliability.
-
A simplified IT environment isn't just less complex. It's also more reliable. Standardize on a single Linux platform with SUSE Linux Enterprise from Novell, and get the world's most interoperable Linux
- Learn more >>
Archives
ZDNet Blogs
- All About Microsoft
- The Apple Core
- Between the Lines
- BriefingsDirect
- Collaboration 2.0
- Dev Connection
- Digital Cameras & Camcorders
- Ed Bott's Microsoft Report
- Emerging Tech
- Enterprise Web 2.0
- Forrester Research
- Googling Google
- GreenTech Pastures
- Hardware 2.0
- Home Theater
- iGeneration
- Irregular Enterprise
- IT Project Failures
- Laptops & Desktops
- Lawgarithms
- Linux and Open Source
- Managing L'unix
- The Mobile Gadgeteer
- On Sustainability
- Rational Rants
- The Semantic Web
- Service Oriented
- Smartphones and Cell Phones
- Social Business
- Social CRM: The Conversation
- Software & Services Safari
- Software as Services
- Storage Bits
- Team Think
- Tech Broiler
- Technology and the Global Supply Chain
- Tom Foremski: IMHO
- The ToyBox
- Virtually Speaking
- The Web Life
- ZDNet Education
- ZDNet Government
- ZDNet Healthcare
- Zero Day
White Papers, Webcasts, and Downloads
- Building the Virtualized Enterprise with VMware Iinfrastructure VMware VMware virtualization software has been adopted by over 120,000 enterprise ... Download Now
- Virtualization: Architectural Considerations And Other Evaluation Criteria VMware Of the many approaches to x86 systems virtualization available in the ... Download Now
- Five Steps to Determine When to Virtualize YourServers VMware Server virtualization isn't just for big companies. Entry-level ... Download Now










