Feeling good when you stop ... beating your head against a wall, that is.

For businesses to stop trying to make bad ideas work, they have to learn how to make good ideas work.

5/14/2012

Next-generation IT has big shoes to fill

What's best about beating your head against a brick wall is how good you feel when you stop.

As discussed here last week and the week before, businesses beat their heads against brick walls all the time, the walls being ideas they keep on trying, over and over again. They never feel good because they never stop, no matter how often the ideas don't work.

We've already discussed a number of reasons this happens. There's one more we haven't talked about yet, and it's a big one: More often than not, in the world of business, changing your mind about an idea isn't safe.

I realize this revelation is less than shocking. Quite the opposite -- it's part of most managers' day-to-day lives, an inevitable consequence of the we-have-to-hold-people-accountable philosophy that paralyzes an organization's ability to make tough decisions.

Given that companies should want every manager and executive to cheerfully abandon ideas that aren't working, it's worth asking how they change the situation, so that putting a bullet in an idea that isn't working out is a career-enhancing move rather than a career-limiting one.

It's an easily stated goal, which is quite different from it being an easily achieved one.

Sometimes you bring in a consultant to help you execute better - call it organizational effectiveness. And sometimes you bring us in to help you look at the ideas you're pursuing. Call that strategic planning.

Either way, if you're going to bring one in, shouldn't it be someone whose ideas are on the table, who has been sharing them with you every week, and who you know won't come in knowing the answers before asking the questions ... someone like Bob Lewis?

And if you want someone like Bob Lewis, why not get Bob Lewis? Contact him here.

The solution (or, at least, a solution) starts with the recognition that we've been asking the wrong question. What we ought to be asking is how businesses should go about exploring promising-sounding concepts. If we understand that, we'll understand how they will go about terminating the ones that don't pan out, as a standard and well-understood step in the practice.

But we're getting ahead of ourselves -- that's the last step, not the first, which is:

Analysis: Of course. The starting point for any concept is to do enough analysis to be sure it's worth pursuing. Volumes have been written on this topic. For our purposes, what matters most is making sure you have a list of the key assumptions on which the idea depends. Once you have the list, replace as many as possible with research. For the rest, figure out how you'll test them to determine whether they're valid or not.

And if you aren't sure you've identified them all, conduct a "pre-mortem" analysis -- an excellent way to explore this topic.

Pilot/Prototype/Proof of Concept: Analysis matters, so don't allow the impatient to intimidate the rest of the organization with premature accusations of "analysis paralysis." On the other hand, endless analysis is an easy trap to fall into. There comes a time when performing a few experiments makes more sense than continuing to theorize. That's when pilot projects, prototypes, and proofs of concept come into play.

And you do want to do at least one, and probably several of these. What you don't want to do is what organizations usually do, which is to conduct a "proof of concept" on the easiest test case they can identify, and, when it succeeds, decide the concept has been proven.

Remember that list of key assumptions? While it makes excellent sense for your first pilot to be built around the easiest test case you can identify, that doesn't mean its success proves the concept. You need to iterate your test cases, making sure each successive one tests additional assumptions from your list, until you've either validated or modified all of them.

Review: It isn't enough to look at the results of a test project to decide whether it's succeeded or failed. Because in the end, what matters isn't its success or failure -- it's what you've learned by conducting it.

Every test should have a completion date -- their duration shouldn't be indefinite. And when they're done, everyone involved in the test should be involved in answering the question, "What do we now know about the subject that we didn't know before?"

By the time the organization has finished and reviewed enough test projects to have tested all of the assumptions and assessed all of the results, everyone involved should be convinced ... by the data ... of whether the idea is sound, and of what competent execution looks like.

Which still doesn't answer the question of what to do about ideas that are already institutionalized, even though they don't seem to work.

The answer isn't to finally figure out, once and for all, that it's the idea and not the execution. If that was going to happen, it would have already happened.

Here's what can happen: Someone (you, for example) can identify a competing idea, and test that. If it works better that what the business has been doing, the business can adopt it without worrying about why the older idea wasn't working.

Or about who has to be held accountable for it.

Visit our e-store to buy books by Bob Lewis

New!

Second Edition of the "IT leadership bible," with twice the content of the original

Special Offer

Permalink: http://www.weblog.keepthejointrunning.com/?p=4677

What else do you do, to give a promising new idea a fair shot without betting the farm on it?

Do you know anyone or any discussion groups that should be talking about this?

Bob Lewis is president of IT Catalysts, Inc. ( www.itcatalysts.com ) an independent consultancy specializing in helping businesses improve their ability to achieve designed, planned business change … which can only happen with effective IT organizations that are strategically integrated into the enterprise. Contact him at rdlewis@itcatalysts.com.

Don't leave me sitting here in a vacuum! If you think I'm full of beans, let me know. Leave a Comment (just click on the Comments button at the bottom of either the homepage or any archived column) to share your thoughts with the whole KJR community.

Or, drop me a line -- the address is Letters@ISSurvivor.com.I sometimes use Comments or reader letters in my columns. The rules:

Comments are public, because they're ... well, they're right at the bottom of every column in the archives.
If you send me a letter, let me know if and how I can use it (as is, sanitized, or don't be ridiculous - you'll be found out and run out of town). Once you give me permission to use it, the permission is eternal.
Also let me know if you'd prefer to remain completely anonymous, or whether I may give you credit by name.

If you like this article, why not let a friend enjoy it, too? It's fine with me, and in fact I'd be flattered. All I ask is that you send the whole thing, including this notice. But don't be shy ... if you think they'd like it, don't you think they should see it? But only those people - you wouldn't want me to get a reputation as a spammer, would you?