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

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

September 21st, 2009

Six types of IT project failure

Posted by Michael Krigsman @ 5:39 am

Categories: IT issues, Project portfolio management, Project strategy, Risk

Tags: Information Technology, Project Failure, Failure, Blogging, Strategy, Internet, Management, Michael Krigsman

Projects fail for many different reasons, so I took notice when reading a blog post that describes six specific categories of failure. I thought the list worth sharing because it’s a clever way to view the problem.

This list comes hot off the press from the Preventing Project Failure blog (gotta love the title) written by Michiko Diby, Principal at project resolution firm Sealight:

• Intent Failure – Occurs when the project doesn’t bring enough added value or capability to beat down the obstacles inherent throughout the process. This suggests the original intent of the project was flawed from the beginning.
• Sponsor Failure – Occurs when the person heading up the project is not actively engaged and/or does not have the authority to make decisions critical to project success.
• Design and Definition/Scope Failure – Occurs when the scope is not clearly defined, so the project team is unclear on deliverables.
• Communications Failure – Occurs when communications are infrequent or honest discussion of project problems and issues are avoided.

Read the rest of this entry »

September 17th, 2009

7 fundamentals of IT project success

Posted by Michael Krigsman @ 6:56 am

Categories: Governance, IT issues, Project management, Project portfolio management, Project strategy

Tags: Project, Information Technology, Failure, Project Management, Tools & Techniques, Strategy, It Operations, It service Management, Management, Michael Krigsman

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:

Read the rest of this entry »

September 15th, 2009

'How I tweeted my way out of spinal surgery'

Posted by Michael Krigsman @ 9:00 am

Categories: CIO issues, CRM, Collective intelligence, End-user impact, Enterprise 2.0, Financial impact, IT issues, Politics, Project failures

Tags: Patient, Hospital, Twitter Inc., Health Care, Surgery, Sarah Cortes, Packer Hospital, Transparency, Healthcare, E-mail

The post describes a failure that is significant in light of the ongoing national debate surrounding health care reform and economics. Beyond health care, the role of social networking makes this failure a valuable case study for the enterprise.

Technology consultant and blogger, Sarah Cortes, went by ambulance to Robert Packer Hospital, a facility located in rural Pennsylvania, after she suffered a serious spinal fracture. The story takes an unusual turn because Cortes says Twitter helped her escape from the clutches of hospital staff whom, she claims, tried to intimidate and coerce her into accepting unnecessary spinal surgery.

On her blog, Cortes writes that Packer, “tried numerous maneuvers over 48 hours to hold me there against my will.” She continues [bullet formatting added]:

[The] tactics included:

• Threats that my insurance would not pay any expenses if I did not accept their treatment. My bill was already in the many thousands of dollars, they informed me.
• Intimidation that if I did not stop resisting their treatment I could be paralyzed
• Impeding my communication with Boston doctors by needlessly limiting my phone access. Thank God for Twitter and iphones.

Cortes believes Packer wanted to perform the surgery to help boost its accreditation statistics. From Cortes’ blog:

Read the rest of this entry »

September 9th, 2009

6 dirty tricks from enterprise vendors

Posted by Michael Krigsman @ 8:04 am

Categories: CIO issues, IT issues, Vendor relationships

Tags: Customer, Enterprise Software, Software, Michael Krigsman

Enterprise software vendors sometimes play unpleasant games to sell their products. InfoWorld describes these tricks in a story called, Dirty Vendor Tricks, written by veteran journalist Dan Tynan, who has covered many stories of IT failure.

• Related: Ugly enterprise software sales tactics

Here’s Dan’s list of six tricks enterprise vendors use against customers, but the descriptions are mine:

1. The magic demo. Using presentation slides and canned demonstrations, the vendor claims to solve the customer’s most challenging problems. It’s all good, except when there is no real product to back up the promises.
2. Underbid, then overcharge. A beautiful trick often played elegantly by consulting companies and system integrators. These folks neglect to inform the customer that the initial software purchase price does not include much higher associated costs for equipment and implementation services.
3. The customer headlock. One of the cleverest tricks in the book, this one uses high switching costs to lock-in customers. The time, cost, and hassle of swapping enterprise systems mean vendors have their customers by the… well, you know what.

Read the rest of this entry »