This is post sponsored by the Enterprise CIO Forum and HP.

In my last post, I discussed modernizing applications by virtue of embracing cloud computing. Today, I’m going to take a step back and focus less on specific technologies are more on arguably the most important concept of Enterprise 2.0: collaboration.

Consideration 2: Are you suffering from the “Project” mentality?

Going back to mid-1990s, most large organizations procured software very formally through formal RFP processes. Because of the lack of broadband, you couldn’t easily download applications for internal use. IT was also more effective in serving as the gatekeeper.

Well, things have changed.

In Empowered workers: IT should embrace them, John Dodge writes:

IT the organization isn’t the sole arbiter anymore of who gets the information technology they need to do their jobs. In many cases, IT the organization is being reluctantly dragged into the era of empowerment where workers get information technology on their own.

That is, there has been a fundamental power shift in many progressive organizations–and even those that are swimming against the stream. Employees can and will use tools “under the radar” when IT refuses to provide useful, sanctioned tools. Web-based applications like Yammer are often adopted in organic and bottom-up fashions, whether or not the CIO likes it or not.

Lamentably, many large organizations are still mired in the late 1990s. They refuse to give employees powerful tools to facilitate meaningful collaboration, of which there are many. Their idea of collaboration for project management (PM)? You guessed it. Good old Microsoft Project, a bulky tool that isn’t on anyone’s list of the best collaborative applications.

Alternatives

I could go in a million directions here. Consider GTDAgenda, a web-based collaboration and PM tool. Then there’s BaseCamp, a similar tool that can be deployed sans proper “installations” and server configurations. Translation: they can be used immediately . More than a few employees of large companies have told me that they have utilized tools like these precisely because their own organizations were unwilling or unable to provide them in a timely manner.

Were these employees disobeying their bosses?

Hardly. Their bosses actually approved of it. “Get the job done” trumped “Don’t do it, but blame IT after you miss your deadline.”

Simon Says

No one is advocating anarchy here. Clearly, enterprise risk substantially increases when everyone is doing his or her own thing. By the same token, however, it’s important to realize that substance trumps style. If IT does not meet its end users’ needs, it should be prepared for the consequences. The consumerization of IT means that employees are increasingly tech-savvy, especially younger ones. The organization that ignores this does so at its own peril.

Feedback

What say you?

This is post sponsored by the Enterprise CIO Forum and HP.

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?

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.

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.

Ask and ye shall receive.

I have been giving quite a bit of thought lately to the topic of enterprise risk management. In large part, this stems from the fact that I recently completed a project in which my client’s risk tolerance was off the charts. I mean crazy. In this post, I discuss three types of organizations with respect to risk tolerance:

• The  Zero Risk Organization
• The Oblivious Organization
• The Acceptable Risk Organization

The Zero Risk Organization

Several years ago, I worked on a project for an organization that would not do anything if there was even the smallest risk. To that end, it employed a full-time internal auditor to carefully monitor all IT projects. He would report his findings to the CIO.

So, you may ask. What’s wrong with this?

In the abstract, nothing. But IT projects are never abstract. Actions have consequences. The project consistently suffered as the implementation team attempted to address his concerns, and he had a bunch. Sure, many of them were well-founded, but how do you concurrently assuage an auditor’s concerns and make up time on a delayed project?

You don’t.

Simon Says

If your organization is not ready to take on some level of risk, then don’t start a major systems or IT initiative. Ever. All projects come with some degree of risk. It’s that simple.

The Oblivious Organization

Now, let’s turn to the other end of the spectrum. This type of organization is perhaps best epitomized by my most recent client. The mentality could be described as:

There was no such thing as risk. Period.

Here’s the crazy thing, though. The company routinely addressed IT projects in this manner. According to lifers, every system that the company implemented in the last ten years was managed the same way. Proceed as if nothing is wrong. Ever.

This was a shock to just about every consultant on the project. You see, good consultants have been trained to identify and attempt to minimize risks throughout projects. Sadly, the CIO did not want us “editorializing.” Translation: keep your mouths shut. We don’t like naysayers.

Simon Says

From a consultant’s perspective, you can’t win on projects like these. If you broach a legitimate issue, you’ll be silenced and possibly removed from the project. If you don’t, then you’ll invariably be asked, “Why didn’t you tell us about this?” Organizations like these have a high employee rejection rate; it takes a certain personality type of accept the risk of lawsuits, audits, and generally appearing foolish as you expose yourself and others to excessive levels of risk.

The Acceptable Risk Organization

Ah, I can’t tell you how much I enjoy working with companies and people who understand risk and possess a modicum of perspective. Serious risks are actually taken…seriously. Further, key people understand the time-sensitive nature of many problems. They understand that, as my friend Bob Charette has told me, risk is always a function of information, time, and money.

Simon Says

Of course, no organization has unlimited information, time, and money. Trade-offs need to be made. Fortunately, “acceptable risk organizations” understand this and are likely to make the right calls. Things won’t always go perfectly, but these realists create contingency plans in the event that things go awry.

Feedback

I have a few questions for you.

• What’s your organization’s risk tolerance?
• What causes some organizations to accept so much risk?
• Can people with one risk tolerance be successful at organizations with vastly different risk tolerances?

The point of this post is not to excoriate McGwire for doing wrong. He was hardly the only guy to shoot up in baseball, much less all sports. Rather, I’d like to take a deeper look at his apology as it relates to project management and the corporate world.

McGwire’s apology was no doubt sincere but was equipped with an infuriating disclaimer. He did it “for health purposes.”

Huh?

For a transcript of the interview, click here.

Rant

Why don’t people just fess up when they are caught?  I like to think that we live in a forgiving society. While coming clean is laudable, it’s hard for me to get over McGwire’s disclaimer. The whole thing me of a recent incident in which someone dropped the ball on an IT project and offered a similar excuse-laden apology.

To make a long story short, on the penultimate day of a consulting engagement, the project manager (PM) literally dropped ten custom report requests on my desk that I had requested several times over a three month span. Oh, did I mention that I was in the middle of another crisis at the time with production data?

The PM apologized but quickly added that “he knew that these reports were ad hoc, not ‘enterprise’ reports.”

Huh?

Don’t worry. I didn’t understand the distinction either.

Now, I have been writing reports out of enterprise systems for nearly fifteen years. There are all sorts of reports from all sorts of tools but dropping the ball is dropping the ball. Period. That’s it. Don’t try to bullshit me on this. (Incidentally, most of these were actually relatively easy reports to create but there was no way for the PM to have known this. In any event, to sit on important tasks for more than two months and then expect someone to save the day at the last minute represents a horrible work ethic for anyone, much less a PM who’s supposed to show leadership to the rest of the organization.)

Simon Says

When you screw up in baseball or the corporate world, just call a spade a spade. Equivocating merely increases the amount of damage that you’ve done to your credibility and reputation. I understand the need to save face. Really, I do. However, providing excuses only rubs salt in the wound and minimizes any benefit of the doubt that others will grant you.

Feeback?

What do you think? Do excuses irritate you as much?

If you enjoyed this post, feel free to subscribe to my RSS feed.