I recently discussed the changing role of IT, among other subjects on bnet.

• Preview 1 – Why Systems Fail
• Preview 2 – Keeping IT Out of the Way
• Preview 3 – Small Business & IT
• Preview 4 – Who’s Responsible for Data?

Click here to listen to the whole thing.

Without question, my least favorite word in the English language is usually “no.” I’d tell James Lipton as much if asked on the sometimes pretentious show Inside The Actors’ Studio. Now, there’s a reason that I qualify that statement with “usually.” In this post, I’ll tell you why not all “no’s” are created equal.

Appropriate No’s

Sometimes, no is the only legitimate response to a question. Consider the following:

• It’s alright to steal music, right?
• Are you going to miss Rush on this tour? (Hells no!)
• Will you shoot par today?
• Did you sleep past 5 am today?

These are examples of “appropriate no’s.” In each case, “no” is the only answer.

But alas, dear reader, there are other kinds of no’s.

Contemplative No’s

Let’s say that I propose a solution to a problem on a consulting gig that seems to make sense–at least to me. The decision maker listens to me and considers the idea. After careful thought, though, she decides against it and tells me why my idea won’t fly. She thanks me for the effort and appreciates my enthusiasm.

Contemplative no’s don’t bother me much. After all, I’m a consultant with no real authority. It’s their world; I’m just playing rent. They know what’s best. My advice is always theirs to take or leave.

Reflexive No’s

Again, let’s say that I’m trying to solve a problem. Maybe I’m trying to do something productive or try to make one of my partners, publishers, or clients money. Here are a few specific examples:

• While working with one of my publishers, I have routinely proposed what I considered to be good ideas to promote our book. These include greater use of social media, book signings, other events, and book reviews.
• When confronting an issue on a new system implementation, I’d figure out a “work-around” that would in no uncertain terms  solve the problem.
• Often I’ve dealt with wholly inefficient business processes and suggested reasonable alternatives to expedite things.

In each case, the decision maker didn’t bother to fully consider my ideas, often barely listening to my suggestions. The response was almost always something along the lines of “that’s not how we do things around here.” I call these “reflexive no’s” and I’ve come across them many times in my career.

And these bother me the most because those who give me “the reflexive no” just don’t try. They don’t care. They’re apathetic. They don’t want to learn or experiment. These people are stuck in their comfort zones and, as my friend Scott Berkun has written many times, this is exactly how mediocrity persists. That mentality stifles innovation and, ultimately, success.

Feedback

Am I just stubborn, cranky, and cantankerous? Does the reflexive no bother you as much as it does me?

…describes the adoption or acceptance of a new product or innovation, according to the demographic and psychological characteristics of defined adopter groups. The process of adoption over time is typically illustrated as a classical normal distribution or “bell curve.” The model indicates that the first group of people to use a new product is called “innovators,” followed by “early adopters.” Next come the early and late majority, and the last group to eventually adopt a product are called “laggards.”

While enterprise technologies have certainly changed in my fifteen years of working with them, one question continues to intrigue me:

Which type of organization is most likely to be on the left side of TALC?

To simplify matters, I’ll place all organizations into three categories:

• The Struggling Organization
• The Self-Sufficient Organization
• The Adventurous Organization

Note that economic conditions mean that all bets are off. Many successful organizations these days lack the funds for many desirable or even necessary technological improvements.

The Struggling Organization

Over the course of my career, I’ve had many discussions with people about the challenges that their organizations face implementing new systems and why so many projects failed to hit their marks. While by no means a definitive list, consider the following:

• the difficulty of gathering comprehensive system requirements during the discovery phase
• the dynamic nature of requirements
• the inevitable scope creep and resultant problems during IT projects

Issues like these have plagued both organizations for years. What’s more, they continue to manifest themselves during many (if not most) major IT projects. As a result, organizations that have historically struggled with enterprise systems will rarely—if ever—be on the left of TALC. If anything, they are the very definition of laggards.

The Self-Sufficient Organization

Often I’ll assist organizations begrudgingly upgrading systems. In these cases, the motivation is clearly the stick, not the carrot. For these organizations, previous implementation issues and future enhancements to their apps just don’t matter now (as well as in the short- and mid-terms). These types of organizations are going live in a few weeks and the focus is very much on what needs to happen to continue paying employees, running financial reports, and the like. Only well after the dust settles will “future enhancements” be broached.

In terms of TALC, organizations “getting by” are usually reluctant to take the lead on a new but largely untested technology. You’ll most likely find them in the early to late majority of TALC.

The Adventurous Organization

Then there are organizations that want to be on the leading edge–or perhaps need to be, based on some business reason. They have the following:

• sufficient financial resources
• sufficient human resources
• a “risk-tolerant” culture
• a compelling business need

These organizations are more likely to implement a largely untested technology and be on the left side of TALC. As an added incentive, at times, software vendors are willing to work with “beta clients” by providing free or heavily discounted resources. In exchange, the vendor will be able to promote the product’s implementation as a successful case study.

Conclusion

Organizations that have had problems implementing and maintaining their systems tend not to be early adopters. In other words, financial, cultural, and political reasons place the vast majority of organizations squarely in the middle of the curve. When walking is a challenge, it’s hard to imagine running.

Feedback

What do you think? Are there are other reasons that organizations often take a “wait and see” approach?

Photo from Wikipedia.

Here’s an excerpt:

Data Quality Pro: Bloor Research uncovered some interesting findings in their industry survey recently. They found that the failure rate was extremely high. What do you feel is preventing these companies learning from their mistakes?

Phil Simon: In a word, experience. Many of my clients have never been through a major new system implementation before. Most have never replaced their legacy back office systems with one integrated solution, at least with current staff members and levels. Such a project is obviously much more time-consuming than a minor upgrade of a stand-alone application that isn’t really connected to anything else.

To read the entire interview, click here.

Here’s an excerpt:

McKnight: Why did you title the book “Why New Systems Fail” when I think it really tells you how to succeed?
Simon: Thank you for saying that. I agree with you; I believe that the book is largely about making projects succeed. However, foolish is the person who refuses to recognize the abysmal success rate on IT projects and system implementations specifically.

I believe that the book’s title is short and descriptive. I tried to write a book that ultimately provides both general and specific advice for avoiding failure. Particularly in a recession, many organizations are going to get one bite at the apple. It’s important that they get projects right the first time.

To read the entire interview, click here.

The reasons for, and statistics on, IT project failures are well known and cited. However, because so many organizations attempt to hide their dirty laundry, rarely do we see an insider’s account of the precise points at which a project derailed. In this Executive Report, a case study is utilized to examine these issues at one organization, along with data quality and data governance.

Click here to access a case study that I recently wrote for the Cutter Consortium.

Disclosure: You’ll have to provide some information to Cutter in order to download the document.

Major props to Lowell Goodman of Corbomite Productions. He understood my vision for the video and worked closely with me to ensure that I was thrilled with the final product.

Navigating the Many Social Networking Sites

In Attention as a Currency and Noise, Chris Brogan describes the importance of attention and priorities in the context of limited time.

Simon Says

I can see why Brogan is, like me, a bit skeptical about Google Buzz. I also agree with him that Google Wave is so much more than just another IM tool. You can save serious time collaborating and minimizing the amount of email back-and-forth.

Square One

In Microsoft Starts Over in Phone Software, Ashlee Vance of The New York Times writes about how Microsoft has recognized the need to blow up the current version of its mobile operating system. Vance writes:

The revamped software represents a rarity for Microsoft — it scrapped previous versions of its software to build something from scratch. Microsoft spent the last 18 months trying to add gloss and sophistication to a product that had been ridiculed as clunky and too wedded to the company’s PC roots.

Simon Says

Give Microsoft Credit. They know when it’s time to call it a day. Turning your back on a product with so much history (and dollars committed) is much easier said than done. From what I understand, however, the Redmond-based giant couldn’t patch its way out of this one. The decision to go in a different direction is probably the correct one if Microsoft is going to compete in the white-hot mobile market.

The IT/Business Chasm

In his post IT failure? Blame your CEO, Michael Krigsman examines the role of the CEO in IT project failures. Normally, CIOs are the ones held accountable for IT projects gone wild. In a post of a similar vein entitled Charm School: It’s Not Just for IT Anymore, my friend Jill Dyché makes some related points.

Simon Says

Michael’s completely on point. IT is no different than other areas of the business. In his post, Michael writes about the history of IT and the “high priests” who used to develop software. We’re not in the mainframe days anymore, though, and haven’t been for quite some time. It’s time that traditional barriers come down.

Jill’s premise is that IT can’t always be the scapegoat and, as usual, she’s right. If I had a nickel for every time that “business” users couldn’t articulate their requirements during the middle of a project, I’d have at least two bucks. I’d hope that more technical functional folks can meet more business-savvy IT folks in the middle, as the diagram in Jill’s excellent post suggests.

The Greatest Tennis Match Ever Played

OK, this one has nothing to do with technology but I like to pretend to be multidimensional. In Strokes of Genius, L. Jon Wertheim recounts the story of arguably the greatest tennis match of all time: the 2008 Wimbledon final between Rafael Nadal and Roger Federer.

Simon Says

This is easily the best tennis book I’ve ever read and one of my favorites in the last five years. Expertly told and weaved with fascinating anecdotes, Wertheim somehow brings drama to a book whose outcome is already known. Among the best sports’ books out there.

Consider the following questions:

• How do deal with difficult people who pose obstacles to your ability to deliver?
• How do influence someone to act on your priorities even when you don’t have the organizational authority?
• How do you find time to network when you’re overwhelmed with day-to-day work?

Public speaker and project management expert Andy Kaufman shares The Dirty Little Secret of Business. You won’t learn this secret in school, yet it is critical to your success. The secret is simple—it’s all about relationships. Andy describes the key relationships you must develop to advance your projects and career. Discover how understanding different personality types will improve your ability to build rapport, influence people, and control situations. Learn what networking is—and isn’t—and how to increase the effectiveness of your networks with less effort. Particularly in today’s challenging economy when you are being asked to deliver more—and perhaps are even worried about your job—it’s critical that you invest in the power of relationships.

In this podcast Andy refers to Dr. Robert Cialdini’s book Influence: The Psychology of Persuasion.

Some of Andy’s other podcasts can be accessed here.

To listen to the podcast, click here or visit iTunes.

To this end, I recently spoke with with Craig Stephens, Epicor’s VP of Services. In this brief podcast, Craig answers questions such as:

• Can you briefly describe the Shared Benefit program?
• What was the impetus for the program?
• While the program is fairly new, have any of your clients enrolled in the program as of yet? If so, then what have been the results?
• The causes for IT project failures have been well documented, as have the statistics. How do you think the program addresses these issues?
• Have other software vendors introduced similar programs to their customer bases? Why/Why not?
• Is the program available for clients upgrading from one version to another?
• A vendor or system integrator can only do so much on ERP projects, as you know. What safeguards exist for Epicor to prevent a client from not pulling its weight?

To listen to the podcast, click here.