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 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 21st, 2009

Gartner Magic Quadrant lawsuit: Sour grapes or real gripes?

Posted by Michael Krigsman @ 9:48 am

Categories: CIO issues, Project strategy, Research and statistics, Vendor relationships

Tags: Lawsuit, Quadrant, Analyst, Gartner Inc., Michael Krigsman

Industry analyst firm, Gartner, is the target of a lawsuit from software vendor, ZL Technologies, challenging the “legitimacy” of Gartner’s Magic Quadrant rating system. The suit has brought forth an array of divergent opinions.

Background. As one of the top analyst firms, with revenue in excess of a billion dollars, Gartner’s opinions and recommendations carry substantial weight with technology buyers and influencers.

On a special website page devoted to the lawsuit, ZL Technologies claims that Gartner’s Magic Quadrant does not present a fair and accurate portrayal of the software market. The company says:

Gartner’s use of their proprietary “Magic Quadrant” is misleading and favors large vendors with large sales and marketing budgets over smaller innovators such as ZL that have developed higher performing products.

Here is the original legal filing:

Read the rest of this entry »

October 1st, 2009

The 'Seven Laws of Projects'

Posted by Michael Krigsman @ 4:36 am

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

Tags: Project, Team, Team Management, Blogging, Management, Internet, Michael Krigsman

Anyone who reads this blog knows projects can go very wrong. While that’s not news, an unexpected source — American Express OPEN Forum — published a blog post neatly summarizing why:

We have delusions of success. We take on more than we should, routinely exaggerating the benefits and discounting the costs. We over-scope, over-scale, and over-sell. At the same time, we under-estimate, under-resource, and under-plan.

I think that does indeed state the problem simply and with complete accuracy.

The post comes from Matthew E. May, author of In Pursuit of Elegance: Why the Best Ideas Have Something Missing, who describes what he calls the Seven Laws of Projects:

1. A major project is never completed on time, within budget, or with the original team, and it never does exactly what it was supposed to.
2. Projects progress quickly until they become 85% complete. Then they remain 85% complete forever. Think of this as the Home Improvement Law.
3. When things appear to be going well, you’ve overlooked something. When things can’t get worse, they will. (Murphy’s Law says, “If something can go wrong, it will”—this is a corollary).
4. Project teams hate weekly progress reports because they so vividly manifest the lack of progress.
5. A carelessly planned project will take three times longer to complete than expected. A carefully planned project will only take twice as long as expected. Also, ten estimators will estimate the same work in ten different ways. And one estimator will estimate ten different ways at ten different times.
6. The greater the project’s technical complexity, the less you need a technician to manage it.
7. If you have too few people on a project, they can’t solve the problems. If you have too many, they create more problems than they can solve.

These laws have nothing to do with technology or IT, which makes sense because failure rarely does. To understand failed projects we need to look into dimensions of collaboration, relationships, and management.

Why do failed projects persist? Because it’s easier to fix bugs than to be ruthlessly honest with the team, the project and, most especially, with oneself. And that’s the truth… think about it.

[Thanks to Guy Kawasaki for the pointer. Photo from iStockphoto.]

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

CRM success: An IT failures virtual town hall meeting

Posted by Michael Krigsman @ 5:18 pm

Categories: Blog annoucements, CIO issues, CRM, IT issues, Project portfolio management, Project strategy

Tags: Information Technology, ACT!, CRM, Customer-relationship Management Project, Advertising & Promotion, Customer Relationship Management (CRM), Enterprise Software, Marketing, Software, Michael Krigsman

Customer relationship management projects are notoriously difficult to get right. This IT failures town hall meeting examines why CRM projects fail and presents practical tips to help make you successful.

We’ll discuss issues such as:

• What makes CRM projects so difficult
• Sales people and their relationship to CRM
• Crossing the CRM chasm to success
• Social CRM

I will be joined for this event by CRM industry guru, Mike Muhney. Beginning with the co-invention of ACT! Mike has been recognized as a global visionary and powerful speaker on the subject of effective business relationships. He has publicly spoken to over 150,000 people worldwide on improving the way they do business, and he has often been interviewed and written about in numerous global publications on the topics of entrepreneurship, market creation, penetration and leadership, global expansion, and motivational speaking.

In 1986 Mike and a friend co-founded the company Contact Software International and they co-invented ACT! which is credited with creating the category of Contact Management applications. ACT! also has been frequently credited with pioneering today’s CRM (Customer Relationship Management) industry. Released in 1987, ACT! went on to win over 100 awards globally, including numerous PC Magazine Editor’s Choice awards (the “Oscar” of any and all PC Industry Awards), and is still, after 22 years, the predominant Contact Manager with an extremely loyal following, now estimated to number in excess of 10 million users worldwide.

Please attend this interactive discussion and participate in a valuable conversation about success and failure in CRM. There’s no cost but you must register in advance.

Topic: Achieving CRM success: An IT failures virtual town hall meeting

Date and Time: Wednesday, October 7, 2009, 12:00 noon -1:00 PM, Eastern Time. The registration page lists international telephone numbers.

Registration: Click here to register for this online session

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 »